As I replied in another comment, even C++ still compiles faster in non-template heavy code.
I can iterate faster in UWP, C++/CX projects than what it takes to compile my dummy Gtk-rs project from scratch.
The factors that affect it I guess are the incremental compiler and linker, binary libraries (which cargo doesn't support) and whatever the Pango bindings are doing during their compilation.
Re:The internals of testing in Rust in 2018
by flurrything on Sunday August 05, 2018 @10:11AM
(#17691388)
> even C++ still compiles faster in non-template heavy code.
But Rust is a template heavy language, and when it comes to compile time of template heave code, Rust is an order of magnitude faster than Clang in my experience (having worked a lot in and with Boost).
Re:The internals of testing in Rust in 2018
by fnord123 on Tuesday July 24, 2018 @05:30AM
(#17599354)
I think cargo supporting binaries and sharing build dependencies between projects (cf maven's .m2 directory) will mitigate a /lot/ of Rust's build time issues.
Re:The internals of testing in Rust in 2018
by steveklabnik on Tuesday July 24, 2018 @09:32AM
(#17600802)
That only helps on the first build, really.
Re:The internals of testing in Rust in 2018
by fnord123 on Tuesday July 24, 2018 @09:57AM
(#17601014)
It brings the cost of trying an idea out down considerably. I've had a few times where I think "i know, I'll just try this idea out" and then I make a new project, add a few deps in Cargo.toml, hack some code, and then build. Oops, the first build takes half an hour. Then I think I should try new ideas out in Go or python. Alas.
Re:The internals of testing in Rust in 2018
by steveklabnik on Tuesday July 24, 2018 @02:01PM
(#17603491)
That’s fair!
Re:The internals of testing in Rust in 2018
by fnord123 on Sunday July 29, 2018 @04:05AM
(#17637059)
Also CI builds...
I have worked in many C++ codebases and compile-time was a problem _everywhere_, very probably the #1 problem. If you want to replace C++ you need to fix the most important problem. No it's not "safety".
D, on the other hand, was always designed for fast compilation (If I recall correctly), and so it compiles quickly. It's important to us, but not as important as other things. You can't be the best at every task, so you have to prioritize. For example, take two implementations of D: DMD and LDC. As I understand it, DMD uses its own codegen, so it compiles quickly, but produces slower binaries. LDC, based on LLVM, compiles more slowly, but produces faster binaries, for the exact same code. My understanding is that LDC is still faster to compile than rustc, but these are the kinds of tradeoffs you have to make.