magic-wormhole.rs VS .NET Runtime

Rust: https://github.com/magic-wormhole/magic-wormhole.rs (official)

I saw some time back that a productionalized attempt came out: https://github.com/magic-wormhole/magic-wormhole.rs

The one I mentioned was much more primitive, meant as a demo (you can look at the branches for different approaches): https://github.com/estebank/rusticwormhole

> Downloading 3GB of dependencies is not a thing that happens in the Rust ecosystem. Reality is orders of magnitude smaller than that.

Assuming they're talking about the built size of dependencies that are left lying around after cargo builds a binary, they're really not exaggerating by much. I have no difficulty of believing that there are Rust projects that leave 3GB+ of dependency bloat on your file system after you build them.

To take the last Rust project I built, magic-wormhole.rs [1], the source code I downloaded from Github was 1.6 MB. After running `cargo build --release`, the build directory is now 618 MB and there's another 179 MB in ~/.cargo, for a total of 800 MB used.

All this to build a little command line program that sends and receives files over the network over a simple protocol (build size 14 MB). God forbid I build something actually complicated written in Rust, like a text editor.

[1] https://github.com/magic-wormhole/magic-wormhole.rs

This is cool but it really should be using TCP. (You can do holepunching with TCP, check out https://github.com/magic-wormhole/magic-wormhole.rs/blob/master/src/transit.rs)

I'm contributing for some magic-wormhole issues, the book of rust-clippy , and exercism rust track ... Thank Almighty Allah.

I'm working on some issues in magic-wormhole.rs and still looking around for other projects.

It's an interesting hole that the test cases don't cover any of Microsoft Office, Windows Explorer, PowerShell's various cmdlets, or the several major .NET ZIP archive libraries. It would seem that the author just does not use Microsoft Windows.

There's a whole extra level of archive file format tooling gotchas that one misses out on when one assumes "UNIX" for everything, and does not account for "FAT", "NTFS", "HPFS", and even "OpenVMS".

Or ZIP64. (-:

* https://github.com/dotnet/runtime/blob/main/src/libraries/Sy...

* https://github.com/mihula/ProDotNetZip/blob/main/src/Zip/Zip...

The book of the Runtime: https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/README.md

This is funny, but unfortunately .NET went all in on the AI coding assistant kool-aid.

https://github.com/dotnet/runtime/pull/115762

https://github.com/dotnet/runtime/pull/115743

https://github.com/dotnet/runtime/pull/115733

https://github.com/dotnet/runtime/pull/115732

No need to exaggerate. They also got PRs which were ok and got merged https://github.com/dotnet/runtime/pull/116987 so it's not "only hallucinations".

This is a good example[1] at 64k LOC removal. We removed built-in support for C# + WinRT interop on Windows and instead required users to use a source-generation tool (which is still the case today). This was a breaking change. We realized we had one chance to do this and took it.

[1] https://github.com/dotnet/runtime/pull/36715/files

Dotnet is getting a fully interpreted mode in 10 or 11 so I wonder if they'll switch to that for things like this

https://github.com/dotnet/runtime/issues/112748