Re:Two years of Rust
by MaulingMonkey on Wednesday May 17, 2017 @03:08PM
(#14361779)
If my github api-fu is correct that's what, 40kloc for the rust side of things? Doesn't seem unreasonable times (vs C++) for a full rebuild on that machine - which I'd generally want to do for anything but the most trivial C++ toolchain bump too (in fact, I'm usually forced to) making a comparison against incremental builds very apples-to-oranges IMO. What's your C++ LOC/full rebuild like?
I'm used to ~100kloc of C++ taking half an hour per config+platform on a 4-6 core, 16GB+, SSD machine. Less hygenic than your codebase sounds like, but with some beefy PCHs. Toolchain updates are usually a full day affair in this context, although that's not entirely from just the compiler bump.
Of course, incremental vs full rebuilds are no contest. Rust is at least working on incremental builds now that they have MIR AFAIK. And binary cargo support would be really nice as well. As would be compiling in general.
It takes me about half an hour to update rustfmt, racer and rustsym, every time a new Rust release comes out. On a dual core with 8 GB and HDD.
On the same computer, any of my VC++ 2015/2017 builds, configured to take advantage of incremental compilation and linking, using forward classes and PIMPL idioms, with all third party dependencies already available as binary dependencies, takes around 5 minutes.
Lack of incremental compilation and cargo not being able to deal with binaries dependencies has putted me off, after all if I want slow builds I can have them already in C++ when I go template meta-programming craziness, which are not that slow when using the experimental work Microsoft is doing with C++ modules.
Also since our use of C++ is constrained to libraries used from Java/.NET/Android/iOS, the build times are usually relatively fast.
Hard to sell Rust to anyone on the team, if that means their workflow would become slower, in spite of the safety improvements over C++.