| ▲ | palata 4 hours ago | ||||||||||||||||
> Two major hurdles were the initial binary size increase due to bringing in the Rust standard library [...]. They don't say what they did about it, do they? Did they just accept it? | |||||||||||||||||
| ▲ | sluongng 3 hours ago | parent | next [-] | ||||||||||||||||
I suspect they just use no_std whenever its applicable https://github.com/facebook/buck2/commit/4a1ccdd36e0de0b69ee... https://github.com/facebook/buck2/commit/bee72b29bc9b67b59ba... Turn out if you have strong control over the compiler and linker instrumentations, there are a lot of ways to optimize binary size | |||||||||||||||||
| ▲ | pornel 3 hours ago | parent | prev | next [-] | ||||||||||||||||
Probably yes. It's ~300KB per binary, and it's a one-time cost. It can be avoided entirely by disabling the standard library, but that's inconvenient, and usually done only when writing for embedded devices. Usually the problem isn't the size directly, but duplication of Rust dependencies in mixed C++/Rust codebases. If you end up with a sandwich of build systems (when you have library dependencies like C++ => Rust => C++ => Rust), each Rust/Cargo build bundles its copy of libstd and crates. Then you need to either ensure that the linker can clean that up, or use something like Bazel instead of Cargo to make it see both Rust and C++ deps as part of a single dependency tree. | |||||||||||||||||
| |||||||||||||||||
| ▲ | jsheard 3 hours ago | parent | prev | next [-] | ||||||||||||||||
Who knows what they did, but there are things which can be done: https://github.com/johnthagen/min-sized-rust | |||||||||||||||||
| ▲ | menaerus 4 hours ago | parent | prev [-] | ||||||||||||||||
The whole article a bit watery which is why I read it as a PR rather than technical presentation | |||||||||||||||||