magic-wormhole.rs VS syncbuf

> 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.

I was trying to do something similar a little while back and ended up writing the Synclist type in Syncbuf. This has the tradeoff that the elements are spread across non-contiguous chunks, so it can't be sliced. But it has the advantage of being able to contain any type, memory usage is monotonic, and "reallocation" is much cheaper since nothing is copied.

Since you asked, my little project in this area has been Syncbuf: https://github.com/bplevin36/syncbuf. It has 2 lock-free concurrent buffer types that are low-overhead by being append-only.

I was writing a toy virtual machine when I realized that in order to make it multi-threaded, it would be very helpful to maintain a global symbol table that allowed adding new symbols without invalidating references to old ones. No such thing appeared to exist yet, so I wrote it: https://github.com/bplevin36/syncbuf