Rust’s big issue here is the anemic standard library. I think overall the strategy makes some amount of sense; since there’s so much crazy alchemy like depending on nightly, no_std, etc in Rust, including stuff in std has more downside in Rust than in a language that’s more stable like Go.

But it’s annoying to have to deal with 3 different time libraries and 3 different error creation libraries and 2 regex libraries somehow in my dependency tree. Plus many packages named stuff like “anyhow” or “nom” or other nonsense words where you need to google for a while to figure out what a package is supposed to do. Makes auditing more difficult than if your library is named structured-errors or parser-combinator.

I don’t like go programming language but I do like go tooling & go ecosystem. I wish there was a Rust with Go Principles. Swift is kinda in the right ballpark, packages are typically named stuff that makes sense and Swift is closer to Rust perf and Rust safety than Go perf and Go safety. But Swift is a tiny ecosystem outside of stuff that depends on the Apple proprietary universe, and the actual APIs in packages can be very magical/clever. ¯\_(ツ)_/¯

▲

bigstrat2003 4 days ago | parent | next [-]

The very sparse std is one of the few genuine mistakes I think Rust has made. I know the arguments for it, but I don't find them persuasive. A batteries included standard library, in my view, is just plain better and every modern language should have one.

▲

forrestthewoods 4 days ago | parent | next [-]

Oh man I feel the opposite. Rust is an example where a sparse stdlib is clearly superior and better and more successful.

I mostly write C++ whose committee is incompetent and sniffs glue. And I deal a lot with Khronos committed who design pure garbage. “Design by Committee” is a pejorative for a reason.

▲

ModernMech 3 days ago | parent | prev [-]

But what batteries to include? I'm sure your list of batteries is probably very different from mine, reflecting the difference in the work we both do. A lot of times when I hear a language has "batteries included", it's a bunch of features for web devs and nothing I would consider a "battery" for my projects.

▲

gingerBill 3 days ago | parent [-]

What do you consider your set of "Batteries Include"?

▲

ModernMech 3 days ago | parent [-]

Basically the stuff in here: https://www.ros.org

▲

gingerBill 3 days ago | parent [-]

I've been looking through the repository list and that is not "batteries included", that's "everything, the kitchen sink, and the city".

Unless I am reading this (https://index.ros.org/?search_repos=true) wrong.

	▲	ModernMech 2 days ago \| parent [-]
		That's pretty much my point -- my batteries aren't your batteries. If you're building houses, kitchen sinks are your parts. I'm high up on the abstraction stack so I need SLAM, and Kalman filters, advanced logging, mesh pub/sub networking in my stdlib. Here's another example of one of my "batteries" that is perhaps a little more concise: https://www.mathworks.com/products/image-processing.html Something like OpenCV in the language stdlib is my idea of "batteries included". Like I said: what you consider batteries are not what people in my line of work consider batteries; Odin advertises "batteries included" but looking through the list I wouldn't use any of that in my day to day. That's why Rust has a small stdlib of just the essentials, because doing so keeps things general, and everyone gets to choose their own idea of batteries.

▲

rich_sasha 4 days ago | parent | prev | next [-]

I agree, though also I note Python has an extensive standard library and isn't much better in terms of package sprawl.

	▲	jitl 4 days ago \| parent [-]
		Yeah, Python is a cautionary tale here, and I think one that informed the Rust stance. Python is much older than Go, and has had more packages move from 3rd party into the stdlib to become a "battery", and then atrophy over the years while people move back to 3rd party alternatives with more features that are actually receiving maintenance. Eventually some of those modules were removed from core. Perhaps the Go model only works when you have a very dedicated core group (for Go, mostly Google employees) around to continuously build and maintain the Cathedral of the standard library + toolchain together. Golang feels very much like UNIX (eg FreeBSD) for this reason, and Rust/Python more like Linux.

▲

curt15 3 days ago | parent | prev [-]

Just as the Rust community has largely converged on tokio as the standard async runtime, is there any reason why there couldn't exist a community-developed "batteries-included" standard library other than writing a standard library being a tedious and thankless task?