Because of Rust’s stability guarantees, anything that goes in stdlib is essentially frozen, to the point that it’s difficult to impossible to evolve it or make API-impacting fixes. That is the primary reason why stdlib contains those things that require compiler support, and (hopefully) not much more.
10 Likes
Thank you for stating it so well.
For that reason, It feels a bit backwards to adopt into the standard library software features that are known to be somewhat outdated or not frozen. By its nature, many things web are defined by a living standard which with the stability promises we would associate with the standard library. Of course some subset is unchanging but solving the problem space partially in std may be worse than not solving it all.
Even with good maintenance, there's a problem of inability to fix or improve interfaces other than by deprecating, but keeping the old one forever, and adding layers of new ones. Googling "deprecated" site:https://golang.org/pkg/ shows quite a few fields, functions, structs, and even entire packages that std authors wanted to change or remove, but can't.
For std, deprecation and replacement is costly. The old version has to be maintained forever. I suspect this also causes pressure to not improve things.
4 Likes
I agree with that, and I think that's the hurdle to getting into std: you need to be really sure that the API you have now is the API you want forever. For some things that's reasonable (e.g., Vec), for other things a frozen API is very undesirable.
I think part of the problem is what it means for something to "die". "Going to std to die" is melodramatic. These things aren't "dying" in the traditional sense of software dying (i.e. unmaintained and no longer used) (at least I think this is what most people would expect software "dying" to mean). They are taking on a huge stability burden, which is a totally fair point and is something I think we all agree on. But I wish the phrase "going to std to die" would die because I don't think it properly communicates what happens in std, and it leads to drama like this thread has seen.
On the other hand, “go to std to die” is the exact pattern seen in python. Python’s success is at least partially due to its “batteries included” methodology, but many of its standard modules didn’t get any support because external solutions just turned out to be better. Of course, in a dynamic language you’re more limited in what kind of changes you can make that keep the kind of stability promises that the stdlib has to keep, but this is where the mentality comes from.
Personally, I think the solution is to ship more of the “standard crates” with Rust distributions and have a kind of “versioned, modular standard libraries”. If we ship e.g. serde:^1 with the standard library distribution, we’ll continue to have to so, but we can also decide to also ship serde:^2. It’s a complicated problem though, and the first solution is education that the old mentality of “no dependencies” isn’t needed, and we can still do so while avoiding “the npm problem”.
5 Likes
I was a PHP programmer a long time ago. During that time, we were facing the transition from the old MySQL lib to MySQLi / PDO.
The transition was fairly smoothly, without any resistance from team members. Why? Because PHP will keep throwing warnings if we don’t get rid of it and it’s annoying.
Another example is Android SDK, it has many deprecated APIs, and so far people are doing a fairly good job stop using those APIs (I guess thats because IDE is also doing a good job at annoying programmer with yellow lines).
You see: we got both good examples and bad examples, so, maybe there is something more to look at?
Look, I’m not saying big stdlib is a must, it’s a nice thing to have for programmers, sure, but downside is still here. So I’m good either way. My concern here is about integration, “standard crates” can be a great idea IF it can provide good/better integration.
BTW, if “die” means stabilize, then I kind like it. Sorry for misunderstanding.
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.