4 ms·

Cargo is one of the best package managers and build tools I've used. They seemed to really look across all of the problems in the ecosystem and try to bring in

Cargo is one of the best package managers and build tools I've used. They seemed to really look across all of the problems in the ecosystem and try to bring in the best features while leaving it open to extension. I have yet to see another one that checks all the same boxes.

saurik 4y ago
Cargo is built in a way that makes it very difficult to avoid and yet it fails to understand basic cross compilation cases correctly which make it (ironically) infuriating for people working on embedded use cases as well as for people attempting to do production binary deployments. Meanwhile, the tool just fundamentally refuses to support reproducible builds in such scenarios even though Rust is fully capable of it (I finally had to write a wrapper for the Rust compiler to munge a the arguments passed by Cargo to remove their semantic mistakes). I feel like the problem is that it isn't just a package manager... it insists on simultaneously being not only "a" but "the" build tooling, which is trading way too much flexibility for a very small amount of convenience. And like, OK: maybe this is useful for people who are just getting started, but I would firmly argue that this kind of tooling should consider the needs of the expert and not make severe tradeoffs for the needs of the beginner unless it is trivially and obviously optional and there can be growth through changes in tooling (where maybe people "graduate" from Cargo to a more extensible tool... but since it is also the package manager, that's brutal). The issues for the tool are then riddled with bugs that have been open for years (I think some of the ones that I've been blocking on might already be at 5 years, which is shocking to me as I don't even think of it being very old) that even often have multiple reasonable pull requests filed but where no progress ever gets made on fixing the problems because, even though it is often trivially shown that there is no way to use the tools correctly currently in the general case, they insist that the behavior of a working tool might break some theoretical user relying on the current inconsistent set of behaviors. The result of all of this is that there are a ton of workarounds for Cargo that projects have started to have to embed almost as boilerplate into their projects, including a popular one that is going around right now (required for Linux->Linux cross) involving setting an environment variable that explicitly tells the user not to set it ever in the name of the variable but like... Cargo doesn't be have any other way of making this stuff work correctly. It is honestly infuriating and ridiculous and there are good reason why you keep seeing stuff like Google avoiding it entirely as part of their Bazel integration.
- trilobyte 4y ago
  On the reproducibility problem, there are several tools for working on the reproducibility at the byte-level. That's a strength of cargo that people can work on those problems and make it part of the ecosystem.
- steveklabnik 4y ago
  I both agree and disagree with a lot of the things that you're saying, but rather than get into all of that, one tiny thing: > setting an environment variable that explicitly tells the user not to set it ever in the name of the variable but like... Cargo doesn't be have any other way of making this stuff work correctly. This has nothing to do with Cargo, if you're talking about RUSTC_BOOTSTRAP. This is because the kernel would like to use a stable compiler, but unstable features. This isn't a supported build configuration; the environment variable is an escape hatch for the bootstrap process, and isn't intended for nothing more. It would be, imho, unreasonable to expect Cargo to support something that is explicitly not intended to be supported.
Ragnarork 4y ago
My (admittedly) limited experience with Cargo had me beeing forced to write a build.rs file, which, while neat for edge/complex cases, seems a little overkill for basic stuff like linking to a simple C library. I'm also not fond of making the package manager also kinda the build system, but that's just my preference to keep it flexible.
- virtualritz 4y ago
  I think you have your definitions upside down. Linking to a library from another language is rather considered an 'edge/complex case' in most circumstances outside of systems programming and the lib having a C API. And that case is literally three lines of Rust in build.rs if you use e.g. bindgen. While Rust is a systems programming language the primary use cases, judging from the ecosystem of crates, are actually /not/ drivers or desktop apps. The latter are an 'edge/complex case' that just happens to be also nicely covered. And not doing that (i.e. operating solely inside the language ecosystem) is what most users of such ecosystem would reserve the term 'basic' for. To understand where I'm coming from: would you consider 'linking' to a Python or Erlang libray from C++ 'basic' or an 'edged/complex case'?
  - Ragnarork 4y ago
    I can agree that it's not the most common case, but it's also out of necessity because there's multiple rust crates, for certain C & C++ libraries that are fundamental in some domains, that either: * do not exist yet * struggle to provide full bindings * do not keep up * have stopped being updated One of the most glaring example for me is Assimp, which still does not have its Rust counterpart (and unsurprisingly, because Assimp has a weird interface to begin with). I didn't stumble upon bindgen, but from what I gather it's for library developers, not consumers, right? > the primary use cases, judging from the ecosystem of crates, are actually /not/ drivers or desktop apps Well, in that case (but not aiming specifically at you) why do I see so much claims that "Rust is the new C++"? > would you consider 'linking' to a Python or Erlang libray from C++ 'basic' or an 'edged/complex case'? I would consider it complex, but this is wildly different IMHO than Rust with C or C++ (but mostly C to keep it sane), which, while more "complex" than pure Rust, still falls within the reasonable expectations. The fact that there are so many crates wrapping around C (and C++ to some extent) libraries means that for the most part, that "complexity" has been offset by crates developers, but many Rust use-cases still seem to require a lot of C/C++ code to even exist (even if abstracted away by glue crates).

saurik 4y ago

Cargo is built in a way that makes it very difficult to avoid and yet it fails to understand basic cross compilation cases correctly which make it (ironically) infuriating for people working on embedded use cases as well as for people attempting to do production binary deployments. Meanwhile, the tool just fundamentally refuses to support reproducible builds in such scenarios even though Rust is fully capable of it (I finally had to write a wrapper for the Rust compiler to munge a the arguments passed by Cargo to remove their semantic mistakes). I feel like the problem is that it isn't just a package manager... it insists on simultaneously being not only "a" but "the" build tooling, which is trading way too much flexibility for a very small amount of convenience. And like, OK: maybe this is useful for people who are just getting started, but I would firmly argue that this kind of tooling should consider the needs of the expert and not make severe tradeoffs for the needs of the beginner unless it is trivially and obviously optional and there can be growth through changes in tooling (where maybe people "graduate" from Cargo to a more extensible tool... but since it is also the package manager, that's brutal). The issues for the tool are then riddled with bugs that have been open for years (I think some of the ones that I've been blocking on might already be at 5 years, which is shocking to me as I don't even think of it being very old) that even often have multiple reasonable pull requests filed but where no progress ever gets made on fixing the problems because, even though it is often trivially shown that there is no way to use the tools correctly currently in the general case, they insist that the behavior of a working tool might break some theoretical user relying on the current inconsistent set of behaviors. The result of all of this is that there are a ton of workarounds for Cargo that projects have started to have to embed almost as boilerplate into their projects, including a popular one that is going around right now (required for Linux->Linux cross) involving setting an environment variable that explicitly tells the user not to set it ever in the name of the variable but like... Cargo doesn't be have any other way of making this stuff work correctly. It is honestly infuriating and ridiculous and there are good reason why you keep seeing stuff like Google avoiding it entirely as part of their Bazel integration.

trilobyte 4y ago
On the reproducibility problem, there are several tools for working on the reproducibility at the byte-level. That's a strength of cargo that people can work on those problems and make it part of the ecosystem.
steveklabnik 4y ago
I both agree and disagree with a lot of the things that you're saying, but rather than get into all of that, one tiny thing: > setting an environment variable that explicitly tells the user not to set it ever in the name of the variable but like... Cargo doesn't be have any other way of making this stuff work correctly. This has nothing to do with Cargo, if you're talking about RUSTC_BOOTSTRAP. This is because the kernel would like to use a stable compiler, but unstable features. This isn't a supported build configuration; the environment variable is an escape hatch for the bootstrap process, and isn't intended for nothing more. It would be, imho, unreasonable to expect Cargo to support something that is explicitly not intended to be supported.

Ragnarork 4y ago

My (admittedly) limited experience with Cargo had me beeing forced to write a build.rs file, which, while neat for edge/complex cases, seems a little overkill for basic stuff like linking to a simple C library. I'm also not fond of making the package manager also kinda the build system, but that's just my preference to keep it flexible.

virtualritz 4y ago
I think you have your definitions upside down. Linking to a library from another language is rather considered an 'edge/complex case' in most circumstances outside of systems programming and the lib having a C API. And that case is literally three lines of Rust in build.rs if you use e.g. bindgen. While Rust is a systems programming language the primary use cases, judging from the ecosystem of crates, are actually /not/ drivers or desktop apps. The latter are an 'edge/complex case' that just happens to be also nicely covered. And not doing that (i.e. operating solely inside the language ecosystem) is what most users of such ecosystem would reserve the term 'basic' for. To understand where I'm coming from: would you consider 'linking' to a Python or Erlang libray from C++ 'basic' or an 'edged/complex case'?
- Ragnarork 4y ago
  I can agree that it's not the most common case, but it's also out of necessity because there's multiple rust crates, for certain C & C++ libraries that are fundamental in some domains, that either: * do not exist yet * struggle to provide full bindings * do not keep up * have stopped being updated One of the most glaring example for me is Assimp, which still does not have its Rust counterpart (and unsurprisingly, because Assimp has a weird interface to begin with). I didn't stumble upon bindgen, but from what I gather it's for library developers, not consumers, right? > the primary use cases, judging from the ecosystem of crates, are actually /not/ drivers or desktop apps Well, in that case (but not aiming specifically at you) why do I see so much claims that "Rust is the new C++"? > would you consider 'linking' to a Python or Erlang libray from C++ 'basic' or an 'edged/complex case'? I would consider it complex, but this is wildly different IMHO than Rust with C or C++ (but mostly C to keep it sane), which, while more "complex" than pure Rust, still falls within the reasonable expectations. The fact that there are so many crates wrapping around C (and C++ to some extent) libraries means that for the most part, that "complexity" has been offset by crates developers, but many Rust use-cases still seem to require a lot of C/C++ code to even exist (even if abstracted away by glue crates).