Hacker News Reader

Comment by jvanderbot | Hacker News Reader

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.

View on HN

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

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.

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.

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.

> And, what, because it's named `std` it'll be magically better?

Who said that? It won't be better, but it'll be always here, stable, conservative and won't depend on something outside std. And it won't be stored on an uncurated supply attack vector like crates.io.

If you want to reach a Common Lisp level of stability, there's no 101 ways to go about it.

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

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

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.

Why would you want to automatically resolve the latest semver compatible version from git if you care about security? That's worse than cargo.io where tags are stable, whereas git allows tags to be edited.

> 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're saying the same thing twice here: yes it's easier to use cargo with crates.io. It follows immediately that it's harder to use without crates.io. That doesn't make your argument stronger.

Here's an article on how to use cargo without crates: https://thomask.sdf.org/blog/2023/11/14/rust-without-crates-...

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

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

Reply on news.ycombinator.com