Hacker News Reader

Comment by enriquto | Hacker News Reader

> where every library has a bespoke build process doesn't work across OSes

cargo sounds pretty much like a new bespoke build process that doesn't even work across different languages on the same OS

View on HN

Yes. It turns out this works much better than the situation previously. The bespoke-per language model turns out to have fewer drawbacks than the bespoke-per-library-and-OS model. Note: fewer drawbacks, not none. I would not have predicted this a priori, for what it's worth, and I was very critical of and first one of these I became familiar with (rvm), but it turns out to work well in practice.

I still think cross-language efforts (like bazel and I'm sure there are others, maybe nix?) seem generally better, but I suspect there is some fairly good reason they are less widely used.

The problem with bazel and nix is that they are totalizing build systems. They want everything to bend to their worldview, and ask for an all-in commitment. Cargo etc require somewhat less of a commitment.

Right, but it seems like it would probably make more sense to pick a totalizing system, if you know you'll have a polyglot environment, which seems pretty inevitable for any business (as opposed to just like a side project). But I think there are probably good reasons this isn't the most common way to do things, and I just don't know them.

The reason is that defaults are powerful. Languages tend to have an owner in a position to declare a default for a language. No one is in a position to declare a default for polygot environments.

This also explains why the only places where these polyglot systems seem to be really common is at giant companies, where they have the power to enforce that stuff is interoperable. If your employer tells you to do extra work to make sure that your package can be used by others in the company, you're going to do it, but if you're working on some personal open source project and have the luxury of deciding what to prioritize, most people are generally not going to be spending time on figuring out polyglot build systems and will just use whatever's easiest, which will generally be whatever the language's default is.

That seems like a good way to think of it.

Many businesses do pick totalizing systems -- many medium-size or above corporations use bazel, and a few use nix. There's also some tooling to convert Cargo.toml to bazel and nix build files, though I don't know how well that works.

I think the problem is that bazel and nix are just not that easy to get started with. If you're using them you're likely to have a team (or at least one person) working full-time on them, since bending everything to a singular worldview involves a lot of work.

Good to know!

Reply on news.ycombinator.com