Yes, and it makes sense for Go to have a stdlib like this, but does it make sense for Rust? You wouldn’t use Rust unless you were aiming for low level optimizations all the time, making one size fits all standard libraries less appropriate.
There is no need to make Rust like Go, Go is already a great Go.
This has nothing to do with the properties of Go/Rust as languages, but all about organizational structure. Go is supported by Google who can put necessary resources to include a bunch of high-level batteries in the stdlib and keep it coherent. Rust community does not have such resources and even if there are some big players joining the community, they don't own Rust and won't be able allocate resources for continuous support without a proper org structure that allows this to be sustainable and efficient.
Philosophical reasoning like "Rust should have small stdlib" is horseshit. Ideal language has every function perfectly designed in the stdlib (kinda like PHP in 2003, lol). But to get closer to that dream you need some sustainable organization that maintains and expands that stdlib, wishes to do so and has resources to do that continuously.
If it's just random 5 people doing maintenance and hacking at their spare time, that's not enough for an expanding library of diverse code. That could be enough only for keeping very core features working/improving like const generics and borrow checker.
> Ideal language has every function perfectly designed in the stdlib
That way of thinking only makes sense if nothing ever changes. You even bring PHP as a good example here of how this fails fast. The world has changed greatly since 2003. The Python standard library carries three XML implementations and an outdated HTML parser irrelevant for the modern world. These libraries were state of the art when they were written, but it's the world around it that changed.
Now one can make the argument: why was it not modernized and updated? The simple answer is that people started building code against this and now depend on it working this way. The only way would be to completely rewrite them with new APIs, remove stuff no longer needed but then you're effectively back to just using crates.io and the likes. Except it's worse now because the standard library is a monolith and does not compose.
On the other hand, code using those libraries still works, whereas code trying today's favorite parser will not work after community moves on and stops maintaining it.
I agree you don't want everything in the stdlib, but havinga stdlib way to achieve something is pretty valuable, even if it's not the best way and never was.
Why would code dependent on third party libraries break? It’s not like crates.io is going to stop hosting them when they become unmaintained. Barring security vulnerabilities, a library that does a well encapsulated task like parsing json might work just fine without updates for ten or more years.
In cases where libraries don’t keep up with changes in standards or whatever, yeah, you’re going to have to find another library. This is a part of our job that is pretty much unavoidable no matter the language. We should learn lessons like sticking dependencies you’re not certain about behind an interface to minimize the cost of switching if possible.
> Barring security vulnerabilities, a library that does a well encapsulated task like parsing json might work just fine without updates for ten or more years.
JSON library updates are a constant tedious chore for many in the Java world. Jackson and Gson have both had several we've needed to make over the years. Now, _most_ of these are due to non-default features where you allow it to deserialize arbitrary types that we don't use. But clients big enough to insist on a BOM and internal security teams both just see "Jackson version x.y.z has a RCE on it, you need to update", even if it's literally impossible to trigger without changing the application code to enable insecure features.
You’re right, a json parser may have been a poor choice. Perhaps something like a UUID generator, or a parser for some more well-established and stable text format would be a better example.
On the other hand, something like a json parser needing to change all the time to support the ecosystem is another good reason to keep it out of the stdlib, IMO. There are limited hands to work on Rust itself, and I’d rather they spend their time making improvements to the core of the language, stabilizing features, and so on. As a user of rust, I’m willing to pay the cost of finding a good json library if it means I don’t need to update rust versions just to deal with some issue in JSON parsing.
Very true! I think the philosophy of letting external crates handle it and seeing how stable they are before considering inclusion in the stdlib is a good one here. Maybe in a few years we see that the uuid crate never needs updates and is super stable, so someone opens an RFC to pull it into std.
The thing is it’s easy to be wrong if you’re trying to predict up front what is going to wind up being stable and low maintenance and what isn’t, so the precautionary nature of what gets into the stdlib I think reflects that.
Lol, I do remember how an upgrade of a JSON serializer (JSON.NET in that case) broke an application. So, there was a .NET service publishing events to a queue with a bunch of consumers - a bunch of Golang service and (our) Scala service. One day our service starts crashing cause it can't parse the payload. We asked developers of the upstream service if they had change anything and they said "no, and by the way, other consumers are doing fine".
Turns out, they upgraded JSON.NET and it started to name fields in different case. Golang parser didn't really care about snake_case, camelCase or PascalCase but whatever parser we were using in Scala at the time actually did.
There is no need to make Rust like Go, Go is already a great Go.