Hacker News new | ask | show | jobs
by saghm 3336 days ago
That's fair, although "building the world every single time" seems like a bit of an exaggeration, since cargo only recompiles dependencies if they're updated (or you specifically clean your build). The project I work on has relatively few dependencies, so the benefits of not having to specifically define different targets and spend time and effort supporting different toolchain- and platform-specific minutiae feels like it would be a big win for us.
1 comments

It is not an exaggeration, because Cargo doesn't support avoiding recompilation of the same dependencies across multiple projects.

So if project A and B both depend on the same version of lib X, without any change on build flags, lib X will be compiled twice.

In C++ using binary libraries, only liking will occur.

Even if compiling from source is required, build systems like Clearmake allow for sharing object files across projects.

I do expect that Cargo might eventually support such scenarios as well, otherwise it won't be appealing to some of us.

Right, but you only have to do that once per project, unless you make a habit of clearing your dependencies quite often. Personally, I'd rather spend two minutes compiling my dependencies once every month or so than have to maintain a complex build system for a project in order to support different toolchains and platforms. I guess if your project is relatively small or constrained to certain toolchains/platforms, it wouldn't be as much of an issue, but at least for the project I work on, maintaining the build system is definitely a non-trivial amount of effort.
You are forgetting crates don't exist in isolation, rather they have a dependency graph, many times with overlapping nodes.

Those two minutes are actually around ten minutes to compile something like rustfmt, just because binary dependencies aren't supported.

My average C++ projects, mixed with Java or .NET code are the ones actually taking two minutes, on the same system.

Truth be told they would take much longer when compiling everything from scratch, but we never do, because we already have the binary libraries.

So it is a bit hard to sell Rust when the toolchain is slower than C++, which I am pretty confident it will certainly improve in any case.