Hacker News new | ask | show | jobs
by pjmlp 3336 days ago
I am still waiting for Cargo to be able to do what we do in our C++ builds, specially in what concerns build time.

Lack of support for binary libraries, specially among projects is a big deal breaker.

Watching the same dependencies being compiled multiple times isn't fun.

Yes, downloading the libraries, placing them in some directory and configuring paths might take some time.

But afterwards, C++ builds are quite fast as they just link to the provided libraries, instead of building the world every single time.

1 comments

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