3 ms·
The long compile times are actually one of Rust's problems I could live with. Having to depend on so many third party libs is a much bigger issue for long term
by _ma_rit_231 5y ago
The long compile times are actually one of Rust's problems I could live with.
Having to depend on so many third party libs is a much bigger issue for long term maintainability and security. Also the time choosing the libs is not neglectible. At work we currently developing a mid size project (CLI and HTTP API) with Go and the standard lib is simply amazing.
- OtomotO 5y agoThe difference between unmaintained code in a stdlib and unmaintained code in a third party lib is artificial. I want the stdlib to be as lean as possible. Also, as you just read, crates are compilation modules, hence generally this means more crates, lead to faster compile times.
- pjmlp 5y agoUntil cargo supports binary dependencies this is only true for incremental builds. Microsoft has to ship binary libraries with build scripts to work around it, https://github.com/microsoft/windows-rs/tree/master/.windows https://github.com/microsoft/windows-rs/tree/master/.windows
- brabel 5y agoLong compile times and having lots of small crates in your dependency tree, surprisingly, are related in that, as the author mentions in the article, splitting libraries into separate crates makes the compilation of each individual crate much faster because crates you depend on are compiled in parallel, and don't ever need to be re-compiled after the first compilation (so hot builds become much faster) while the current crate being compiled becomes naturally much smaller, hence faster to compile, when you pull chunks of it into other crates.