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