Announcing Rust 1.96
blog.rust-lang.org
blog.rust-lang.org
That's confusing and not forward thinking, what if a design improvement is found in some years and a new iteration is wanted? Will it end up as a std::range::legacy::legacier?
The other day there was some talking about Go's stdlib around here, and I truly believe they got it much better thought out. std::range should stay where it is, and the new one be introduced as std::range/v2 or std::range::v2 or whatever syntax was deemed adequate.
Solving the problem of how to iterate the stdlib in a maintainable and consistent way would also help to take away the reservations against adding actual batteries to the stdlib. The old adage against adding APIs because "once a new API enters the stdlib, it has to stay like that forever" has meant that Rust never takes a stance to pick a set of opinionated choices for the majority of the community who just want an "official" language-vetted way to get stuff done.
But bringing my post to a more general stance, I'm of the opinion that Rust is fixated a bit too much on the goal of having a minimal core and leaving the ecosystem to find its own ways forward. Maybe it wouldn't hurt that much if the language, with its current age, started opening up to providing more of the stuff that's currently deemed "inappropriate" for the stdlib. Didn't we have enough time to let the bazaar do its thing and come up with some locally optimal API designs yet? While having a consistent way to version APIs (such as the mentioned Go's /v2) solves the issue of "being stuck forever".
I guess all this to say that extremes are never healthy. The Rust Way is a good one for letting the community discover and experiment, but not even compromising on an async engine is (as always, IMHO) taking it a bit too far.
Interfaces also do not magically become good or useful. There has been suggestions around some async traits, but no suitable one has actually been found yet. Yes, it has been a very long time, but that’s just how it goes sometimes.
FWIW, Tokio's API is not the right one for io_uring, buffer pools for reads changes everything. There'll be yet another huge ecosystem churn. I'm personally hoping for it to happen sooner rather than later.
> Why replace the already existing std::range in-place with the new version
We didn't. `std::range` is new. The existing range types have always been in `std::ops`. They have to stay there because we don't have a way of resolving paths in an edition dependent way.
See: https://rust-lang.github.io/rfcs/3550-new-range.html#new-pat...
> The other day there was some talking about Go's stdlib around here, and I truly believe they got it much better thought out.
I used Go for over a decade and loved every minute of it.
As someone with significant API design experience in both Go and Rust, Go has it way easier. I don't want to go into a big long diatribe about it, but the space in which Rust operates means that getting APIs correct in a way that lasts forever is harder. To a first approximation, this is a result of project goals (hand wavy: being able to write code while thinking about "what I want the CPU to do") and expressive power provided by the language.
Go added generics after I mostly stopped using it, but even with that, there are considerable differences in expressive power that translate directly into more complex APIs.
Plus, Rust started with Cargo. Go didn't get "proper" package management until much later. The promise (and one that it has fulfilled ten-fold) was precisely that Rust's standard library could be "small" and gaps could be filled by ecosystem crates that can use semver incompatible changes to evolve when necessary.
(My intent is for the above to be mostly descriptive. I'm not trying to cast shade on Go here. The Rust and Go projects have different goals that they optimize for. To be prescriptive: Go does an excellent job of optimizing for their goals IMO. And also, IMO, to be frank, I would consider this a feature of Go that it has over Rust. Having batteries in std is great. I'd love to have more. It's just fucking hard in the Rust world. That's not to minimize and say Go has it easy... But, well, okay. I'll stop hedging here. Lol.)
Go, on the other hand took simplicity as a major goal, and while not the most efficient or expressive language out there, that single goal is paying massive dividents.
The good news is, all this means, is that rust can / will be a lot more serious when someone, possibly a big corporation with deep pockets to maintain this until a critical mass has formed, develops and maintains a golang-style standard library. It can be like C++'s in which the initial std lib was crap compared to what it is now. But people ended up using and eventually evolving the language and the std lib together. We are missing that kind of library at the moment.
Expecting a kitchen sink approach for a low-level language can't work out. In low level systems languages your algorithms and interfaces are (or should be) much more tightly bound to specific solutions. It's much easier for abstraction to become excessive and counterproductive.
This is really not good enough. The real gigantic problem with supply chain risk is not that you get tricked to use a package by bad actor, it is that if everyone using gazillion packages by known good authors, that makes all those known good authors with upload rights for their own packages into exploitable vulnerabilities for all the software that depends on their libraries. So far, this has mostly looked like someone stealing creds and sneakily uploading compromised versions, if the situation persists it will eventually get worse with organized crime attacking and using rubber hose cryptoanalysis on devs. There is too much value hanging on too wobbly a foundation here, the situation is not stable and it needs to change.
The C++ standard library is terrible because it was designed from nothing with no actual real-world testing. IMHO the best path forwards for Rust is that when crates become established and "complete" with little further development needed, they should eventually be merged into some large conglomerated library with an actual organization behind it. This doesn't necessarily need to be the standard library that ships with the language. Yes, this would end up like Python, where eventually there would be 4 http clients in there with 3 of them deprecated, but that would still be better than the present state of affairs.
I disagree about merging existing "done" libraries into a mega library. That can work to some extent, but that approach will not produce something lasting (in the sense that it will remain without the need for changes for a long time). The way to achieve a lasting mega library is by putting all the pieces you need, and constantly working to increase the consistency between them. Somewhat like turning a long winded rambling into a much denser article.
Going from a set of good and working libraries to a large CONSISTENT library would be substantially laborious. Hence the need for someone with deep pockets to take it on. (There are other ways for that to happen but those are rarer).
It went out of favour since the 2000's, because of the raise of ecosystems like Java and .NET, followed by everyone with exception of Microsoft, going for other systems programming languages on their desktop and mobile OS platforms.
Also the consequence that we eventually got reduced to GCC, clang, and MSVC, and only one of them cares about frameworks. The other exception being C++ Builder, but that one is largely ignored outside big corporations.
Recent C++, together with a couple of major libraries, and with a good style guide and a matching lint (that removes / restricts many footguns) is far better than it was, 15-20 years ago. While it is not exactly cool, it can be totally bearable.
My point is the current success can be "copied over" to rust by cloning (or otherwise obtaining) a good base std lib, and a few domain specific comprehensive libraries. That doesn't even need to affect the existing ecosystem. There can be several parallel ecosystems and each one can be relatively thriving (one doing nodejs style YOLO, one doing enterprise extreme best-practices, one doing efficient embedded or OS level work, etc.). However, apart from the nodejs style community, the rest will benefit [heavily] from a base library that is well designed and NOT subject to change. Even a travesty such as a vibe-cloned golang std lib would be an improvement over the current situation.
Which is the main reason why despite its warts, C++ is my go to systems language, when I need to do something outside Java, C#, node. It is anyway for "unsafe stuff" for the most part.
Additionally being the systems language those runtimes rely on, and for stuff like GPGPU.
Always use static analysers and hardened runtime, it isn't Rust, but still so much better than C.
> My point is the current success can be "copied over" to rust by cloning (or otherwise obtaining) a good base std lib,
That I agree as well, it cannot be that for basic stuff like general purpose error handling, or handling macros, we need to rely on third party crates. Or that for all pratical purposes, tokio is the async runtime.
This kind of spam trains new users from the get to stop thinking about their tools. Is it necessary? Of course not, the language itself can be written with chalk and stone. The lowest tech solution naturally leads to the most comprehensible code that solves the problem, mo' tech mo' problems. We shouldn't train beginners to work on the ISS before they know how to hold a mop.
Go has this problem too, just to a slight lesser degree. The tools existing are debatably a problem, but them being pushed on beginners is certainly one. And just maybe the point of programming isn't to contribute to billion line corporate codebases.
Isn’t this what editions are for?
Editions are for language evolution. Evolving the std does fit the bill. Edition aware path resolution isn't a thing. It will likely be a thing starting with Edition 2027. Range is likely to be the first type to use this feature upcoming.
Especially because ISO languages always have to care about multiple implementations, C++ isn't alone in this.
Rust idioms do of course change over time, such that if you come back to the language after a while you'll have some catching up to do, but that's just as true of C++.
The paper you want to look up is “epochs” (the OG name for editions) but there were questions that never got resolved, and so the proposals are dead for now at least.
Do you have a particular scenario in mind for incompatible crates? This doesn't seem like a language evolution problem.
I wonder how painless the transition will be.
It’s a new world for breaking things