Re:Ask HN: Why do you use Rust, when D is available?
by adamnemecek on Friday June 12, 2020 @11:39AM
(#23500317)
Rust is much better at caching the intermediate results of compilation. First time compilation might take some time, recompilation will be faster though.
[ Parent
| on HN ]
Re:Ask HN: Why do you use Rust, when D is available?
by sivizius on Friday June 12, 2020 @01:29PM
(#23501560)
Most of the time, I let my IDE check the code with rls, rust-analyzer or cargo check which invokes the rust-compiler without doing the costly code generation part with LLVM, so it is usually fast enough checking huge projects while writing or at least when saving.
Re:Ask HN: Why do you use Rust, when D is available?
by vmchale on Friday June 12, 2020 @01:50PM
(#23501766)
cargo doesn't do a terribly good job of caching dependencies.
Might be better than whatever C++ does though.
Re:Ask HN: Why do you use Rust, when D is available?
by pjmlp on Saturday June 13, 2020 @11:39AM
(#23510184)
Currently C++ is still a better experience, because using binary dependencies is quite common, so you don't compile the whole world, rather just your own application.
Then most organizations have staging areas where you can share binaries across the company.
And the two package managers that have been growing community support, conan and vcpkg, support caching and distribution of binary dependencies.
No doubt cargo will eventually get something similar, it just isn't there today.
Re:Ask HN: Why do you use Rust, when D is available?
by adamnemecek on Saturday June 13, 2020 @02:20PM
(#23511441)
You can do this with a build script.
Re:Ask HN: Why do you use Rust, when D is available?
by pjmlp on Saturday June 13, 2020 @02:29PM
(#23511497)
So goodbye declarative builds.
Re:Ask HN: Why do you use Rust, when D is available?
by adamnemecek on Saturday June 13, 2020 @07:22PM
(#23513716)
I thought I cared about declarativeness, turns out I don't.
Re:Ask HN: Why do you use Rust, when D is available?
by pjmlp on Sunday June 14, 2020 @03:51AM
(#23515864)
Experience has taught me to always care about it, except when working on throw away hobby projects with teams of one, turns out not using it doesn't scale across organisations and makes for very unhappy DevOps teams.