3 ms·

So having one easy to use build system (and actual package manager) is worse than having countless arcane build systems?

cmrdporcupine 3y ago
What kind of strawman game are you trying to play? Those are not my words. Cargo is... ok. It has rough edges, but mostly works. Various things frustrate me, though there's usually work arounds. Workspace support is still a bit half-assed -- I mean, take a look at this terminally open but rather critical issue: https://github.com/rust-lang/cargo/issues/3946 https://github.com/rust-lang/cargo/issues/3946 ; our $work source tree is littered with brittle hardcoded relative paths because of this basic missing feature. Crates.io is ... not ok. It's a wild west full of hobby and abandoned projects with undisciplined massive dependency trees, has people camping out on names, and lacks even the most basic checks and balances (properly moderated submission process, expiry) and features (org namespaces) that Maven had back in like 2007. Because of this, incredible discipline is required on large projects with large sets of third party deps or you will end up with multiple versions of things linked into your binary, or with abandoned projects in your dep tree, or just dep bloat generally. And this ties back to cargo, too. It was only with last week's 1.74.0 release that we finally got the ability to do authenticated repositories? Again, something that Maven supported from day 1. It's a bad culture that was, I think, imported from the node/npm world. If I were starting a serious corporate project from scratch in 2023, I'd seriously consider a model with checked-in, vendored, moderated dependencies that doesn't use crates.io (or a mirror) at all.
saurik 3y ago
In practice, there are only like, three-ish build systems in C++, and they all work better than cargo. There are a handful of issues cargo could get around to fixing that would help dramatically, but they always seem like they would rather spend hours arguing in the comments to bikeshed a patch rather than deign to type even a single line of code themselves, so they burn out all of their contributors and end up with critical fixes stalled for literal years while projects pile on ridiculous workarounds that no one ever documents anywhere :/.

cmrdporcupine 3y ago

What kind of strawman game are you trying to play? Those are not my words. Cargo is... ok. It has rough edges, but mostly works. Various things frustrate me, though there's usually work arounds. Workspace support is still a bit half-assed -- I mean, take a look at this terminally open but rather critical issue: https://github.com/rust-lang/cargo/issues/3946 https://github.com/rust-lang/cargo/issues/3946 ; our $work source tree is littered with brittle hardcoded relative paths because of this basic missing feature. Crates.io is ... not ok. It's a wild west full of hobby and abandoned projects with undisciplined massive dependency trees, has people camping out on names, and lacks even the most basic checks and balances (properly moderated submission process, expiry) and features (org namespaces) that Maven had back in like 2007. Because of this, incredible discipline is required on large projects with large sets of third party deps or you will end up with multiple versions of things linked into your binary, or with abandoned projects in your dep tree, or just dep bloat generally. And this ties back to cargo, too. It was only with last week's 1.74.0 release that we finally got the ability to do authenticated repositories? Again, something that Maven supported from day 1. It's a bad culture that was, I think, imported from the node/npm world. If I were starting a serious corporate project from scratch in 2023, I'd seriously consider a model with checked-in, vendored, moderated dependencies that doesn't use crates.io (or a mirror) at all.

saurik 3y ago

In practice, there are only like, three-ish build systems in C++, and they all work better than cargo. There are a handful of issues cargo could get around to fixing that would help dramatically, but they always seem like they would rather spend hours arguing in the comments to bikeshed a patch rather than deign to type even a single line of code themselves, so they burn out all of their contributors and end up with critical fixes stalled for literal years while projects pile on ridiculous workarounds that no one ever documents anywhere :/.