4 ms·

So, the feature of "Here's a set of easily pulled libraries" is an anti-feature because it makes it easy to pull supporting libraries? I suspect this is actuall

So, the feature of "Here's a set of easily pulled libraries" is an anti-feature because it makes it easy to pull supporting libraries? I suspect this is actually about developers and not Rust or JS. Developers choose what dependencies to pull. If nobody pulled a dependency it would wither and die. There are a lot of dependencies for most libraries because most developers prefer to use dependencies to build something. But I digress. If we're talking build system, nobody is forcing you to use Crates.io with cargo, they just make it easy to. You can use path-based dependencies just like CMake/VCPkg,Conan, or you can DIY the library. Even with crates.io, nobody is forcing you to not use version pinning if you want to avoid churn, but they just make it easy to get latest. It's easy to build software on existing software in Rust. If you don't like the existing software or the rate it changes don't blame Cargo. Just do it the way you like it.

chrisco255 2y ago
[flagged]
- palata 2y ago
  > They also prefer languages with buffer overflow and use-after-free errors. Bad faith? My first sentence clearly says that I like the language, not the dependency situation.
- johnnyjeans 2y ago
  he literally said he likes rust as a programming language, so no. also it's not "optional" when it's the de-facto standard in the language. you lock yourself out of the broader tooling ecosystem. no language server, no libraries (because they all use cargo), etc. oftentimes you run into ergonomic problems with a language's module system because it's been hacked together in service of the enormous combo build/dependency management system rather than vice versa. you're running so far against the grain you might as well not use the language. this kind of passive-aggressive snark whenever someone leverages this very valid criticism is ridiculous
a-french-anon 2y ago
> because it makes it easy to pull supporting libraries? No, because it's used as an excuse for a lack of large(r) standard library. It's the equivalent of "the bazaar/free market will solve it!". You basically end up with a R5RS level of fragmentation and cruft outside your pristine small language; something that the Scheme community decided is not fun and prompted the idea of R6RS/R7RS-large. Yeah, it's hard to make a good, large and useful stdlib, but punting it to the outside world isn't a proper long-term solution either. It's really a combination of factors.
- materielle 2y ago
  Standard library omissions aren’t there just because. For almost any functionality missing in the standard library, you could point to 2-3 popular crates that solve the problem in mutually exclusive ways, for different use cases. Higher level languages like Go or Python can create “good enough” standard libraries, that are correct for 99% of users. Rust is really no different than C or C++ in this regard. Sure, C++ has a bigger standard library. But half of it is “oh don’t use that because it has foot guns for this use case, everyone uses this other external library anyways”. The one big exception here is probably async. The language needs a better way for library writers to code against a generic runtime implementation without forcing a specific runtime onto the consumer.
  - BoingBoomTschak 2y ago
    You're just elaborating on my use of the word "hard". Yes it is, and C++ is a good example of what not to do. Also, "good" is a spectrum, which means something a bit less shiny but standard is worth existing. What R7RS-large is doing by standardizing stuff that was already discussed at length through SRFI seems like a good way. From an external PoV, Clojure seem to be doing okay too.
- pie_flavor 2y ago
  And, what, because it's named `std` it'll be magically better? Languages with giant stdlibs routinely have modules rot away because code maintenance doesn't get any easier, like Python. There are plenty of crates on crates.io made by the Rust project developers, I trust the RustCrypto guys pretty much the same amount, and merging the two teams together wouldn't solve any problems.
WhyNotHugo 2y ago
> If we're talking build system, nobody is forcing you to use Crates.io with cargo, they just make it easy to. Using cargo with distributed dependencies (e.g.: using git repositories) has several missing features, like resolving the latest semver-compatible version, etc. No only is it _easier_ to use cargo with crates.io, it's harder to use with anything else because of missing or incomplete features. > You can use path-based dependencies just like CMake/VCPkg,Conan, or you can DIY the library. Have you tried to do this? Cargo is a "many things in one" kind of tool, compiling a Rust library (e.g.: dependency) without it is a pain. If cargo had instead been multiple programs that each on one thing, it might be easier to opt out of it for regular projects.
- jvanderbot 2y ago
  Compared to ... cmake? vckpg? conan? I have never had a good experience with those. However, using mydep.path = <path> in cargo has never been an issue. And I hate to say it, path-based deps are much easier in C++ / C than other "make the build system do a coherent checkout" options like those mentioned above. So we're at worst parity for this use case, IMHO and subject to my own subjectivity, of course
  - TeMPOraL 2y ago
    Speaking of Conan. Something I don't see anyone talking about is, with such systems you have not one but at least two dependencies to audit per any library you want to include. One is the library itself, but the other one is the recipe for the package manager. At least with Conan, the recipes are usually written by third parties that are not affiliated with the dependency they're packaging. Now, Conan recipes are usually full-blown Python scripts that not only decide where to pull the target sources from themselves, they also tend to ship patches, which they apply to the target source code before building. That is, even if package source is specified directly and fixed on specific release, you still can't assume you're actually building the exact source of that release, because the recipe itself modifies the code of the release it pulled. IMHO, trying to do OSS clearance on dependencies pulled via Conan makes very little sense if you don't also treat each Conan recipe as a separate library. But no one does.
- 2y ago
johnnyjeans 2y ago
yes a large component of it is about developers. if developers were perfect beings, we wouldn't need rust in the first place.
- nindalf 2y ago
  Rust may not be what you want to write, but it's what you want your coworkers to write.

chrisco255 2y ago

[flagged]

palata 2y ago
> They also prefer languages with buffer overflow and use-after-free errors. Bad faith? My first sentence clearly says that I like the language, not the dependency situation.
johnnyjeans 2y ago
he literally said he likes rust as a programming language, so no. also it's not "optional" when it's the de-facto standard in the language. you lock yourself out of the broader tooling ecosystem. no language server, no libraries (because they all use cargo), etc. oftentimes you run into ergonomic problems with a language's module system because it's been hacked together in service of the enormous combo build/dependency management system rather than vice versa. you're running so far against the grain you might as well not use the language. this kind of passive-aggressive snark whenever someone leverages this very valid criticism is ridiculous

a-french-anon 2y ago

> because it makes it easy to pull supporting libraries? No, because it's used as an excuse for a lack of large(r) standard library. It's the equivalent of "the bazaar/free market will solve it!". You basically end up with a R5RS level of fragmentation and cruft outside your pristine small language; something that the Scheme community decided is not fun and prompted the idea of R6RS/R7RS-large. Yeah, it's hard to make a good, large and useful stdlib, but punting it to the outside world isn't a proper long-term solution either. It's really a combination of factors.

materielle 2y ago
Standard library omissions aren’t there just because. For almost any functionality missing in the standard library, you could point to 2-3 popular crates that solve the problem in mutually exclusive ways, for different use cases. Higher level languages like Go or Python can create “good enough” standard libraries, that are correct for 99% of users. Rust is really no different than C or C++ in this regard. Sure, C++ has a bigger standard library. But half of it is “oh don’t use that because it has foot guns for this use case, everyone uses this other external library anyways”. The one big exception here is probably async. The language needs a better way for library writers to code against a generic runtime implementation without forcing a specific runtime onto the consumer.
- BoingBoomTschak 2y ago
  You're just elaborating on my use of the word "hard". Yes it is, and C++ is a good example of what not to do. Also, "good" is a spectrum, which means something a bit less shiny but standard is worth existing. What R7RS-large is doing by standardizing stuff that was already discussed at length through SRFI seems like a good way. From an external PoV, Clojure seem to be doing okay too.
pie_flavor 2y ago
And, what, because it's named `std` it'll be magically better? Languages with giant stdlibs routinely have modules rot away because code maintenance doesn't get any easier, like Python. There are plenty of crates on crates.io made by the Rust project developers, I trust the RustCrypto guys pretty much the same amount, and merging the two teams together wouldn't solve any problems.

WhyNotHugo 2y ago

> If we're talking build system, nobody is forcing you to use Crates.io with cargo, they just make it easy to. Using cargo with distributed dependencies (e.g.: using git repositories) has several missing features, like resolving the latest semver-compatible version, etc. No only is it _easier_ to use cargo with crates.io, it's harder to use with anything else because of missing or incomplete features. > You can use path-based dependencies just like CMake/VCPkg,Conan, or you can DIY the library. Have you tried to do this? Cargo is a "many things in one" kind of tool, compiling a Rust library (e.g.: dependency) without it is a pain. If cargo had instead been multiple programs that each on one thing, it might be easier to opt out of it for regular projects.

jvanderbot 2y ago
Compared to ... cmake? vckpg? conan? I have never had a good experience with those. However, using mydep.path = <path> in cargo has never been an issue. And I hate to say it, path-based deps are much easier in C++ / C than other "make the build system do a coherent checkout" options like those mentioned above. So we're at worst parity for this use case, IMHO and subject to my own subjectivity, of course
- TeMPOraL 2y ago
  Speaking of Conan. Something I don't see anyone talking about is, with such systems you have not one but at least two dependencies to audit per any library you want to include. One is the library itself, but the other one is the recipe for the package manager. At least with Conan, the recipes are usually written by third parties that are not affiliated with the dependency they're packaging. Now, Conan recipes are usually full-blown Python scripts that not only decide where to pull the target sources from themselves, they also tend to ship patches, which they apply to the target source code before building. That is, even if package source is specified directly and fixed on specific release, you still can't assume you're actually building the exact source of that release, because the recipe itself modifies the code of the release it pulled. IMHO, trying to do OSS clearance on dependencies pulled via Conan makes very little sense if you don't also treat each Conan recipe as a separate library. But no one does.
2y ago

johnnyjeans 2y ago

yes a large component of it is about developers. if developers were perfect beings, we wouldn't need rust in the first place.

nindalf 2y ago
Rust may not be what you want to write, but it's what you want your coworkers to write.