3 ms·

Why replace the already existing std::range in-place with the new version, and move the old one to std::range::legacy? That's confusing and not forward thinkin

by j1elo 4mo ago

Why replace the already existing std::range in-place with the new version, and move the old one to std::range::legacy? 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.

metaltyphoon 4mo ago
> std::range should stay where it is, and the new one be introduced as std::range/v2 Isn’t this what editions are for?
- estebank 4mo ago
  Yes, but no, but also yes. 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.
  - pjmlp 4mo ago
    Which is why I always give library evolution as one example why editions don't solve everything as many people think they do.
    - metaltyphoon 4mo ago
      Don't let perfect be the enemy of good enough. This is much better, IMO, than what many other languages do, including Go's modulename/v2 style.
burntsushi 4mo ago
(I am on the Rust libs-api team. I say "we" below, but I didn't do any of the amazing new range type work.) > 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-paths 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.)
- honr 4mo ago
  I believe by a wide margin the most significant long term problem with rust is lack of a good and comprehensive standard library, or a FEW set of crates that provides a really good set. We are in the age of supply chain risks and I personally know many great engineers who shun languages whose community / library providers don't take this problem with utmost care. At this point in time, rust is being treated like nodejs. That is not fair to rust, but that is the reality of the current situation. 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.
steveklabnik 4mo ago
That would be a reasonable worry, except that this specific issue has been discussed for like, a decade. It’s the only beef people have. It’s unlikely that they’ll find something else any time soon.
- j1elo 4mo ago
  Talking about this specifically, yes it's difficult to think of a reason to change ranges in the future. 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.
  - steveklabnik 4mo ago
    Async engines are one of the worst things you could have chosen as an example. They are wide and varied, with a ton of different tradeoffs for different scenarios. Ones for high performance networking are also complex, requiring tremendous engineering effort, and are massive. Putting something in the stdlib doesn’t magically make something better maintained. 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.
  - yencabulator 4mo ago
    > but not even compromising on an async engine 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.
bulbar 4mo ago
I don't follow Rust closely, but I somehow love that they just did it. I like C++, but it would be much less confusing if the committee dared to change the language or std from time to time. Instead, they only ever extend (with super rare outliers).
- pjmlp 4mo ago
  For better or worse, that is one reason why many of us still reach out to C++. Especially because ISO languages always have to care about multiple implementations, C++ isn't alone in this.
  - ameliaquining 4mo ago
    Note that the thing Rust is doing here doesn't break backwards compatibility, because of the edition mechanism. C++ doesn't have that (I don't know if they've considered adding it), so they can't do anything about language footguns without compatibility breaks. 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++.
    - steveklabnik 4mo ago
      > (I don't know if they've considered adding it) 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.
    - pjmlp 4mo ago
      Editions for the time being don't cover all language evolution scenarios, e.g. breaking changes on the standard library, and having incompatible crates on the same build talking to each other.
      - ameliaquining 4mo ago
        Is anybody contemplating nontrivial breaking changes to the standard library? When env::set_var and env::remove_var were marked unsafe, that was done across an edition boundary even though it's unsound to leave them as-is in older editions. Do you have a particular scenario in mind for incompatible crates? This doesn't seem like a language evolution problem.
pjmlp 4mo ago
Agree, not only Go, this would have been the approach in Java, C#, and C++, with newer namespace, or new data type.

by j1elo 4mo ago

metaltyphoon 4mo ago

> std::range should stay where it is, and the new one be introduced as std::range/v2 Isn’t this what editions are for?

estebank 4mo ago
Yes, but no, but also yes. 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.
- pjmlp 4mo ago
  Which is why I always give library evolution as one example why editions don't solve everything as many people think they do.
  - metaltyphoon 4mo ago
    Don't let perfect be the enemy of good enough. This is much better, IMO, than what many other languages do, including Go's modulename/v2 style.

burntsushi 4mo ago

(I am on the Rust libs-api team. I say "we" below, but I didn't do any of the amazing new range type work.) > 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-paths 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.)

honr 4mo ago
I believe by a wide margin the most significant long term problem with rust is lack of a good and comprehensive standard library, or a FEW set of crates that provides a really good set. We are in the age of supply chain risks and I personally know many great engineers who shun languages whose community / library providers don't take this problem with utmost care. At this point in time, rust is being treated like nodejs. That is not fair to rust, but that is the reality of the current situation. 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.

steveklabnik 4mo ago

That would be a reasonable worry, except that this specific issue has been discussed for like, a decade. It’s the only beef people have. It’s unlikely that they’ll find something else any time soon.

j1elo 4mo ago
Talking about this specifically, yes it's difficult to think of a reason to change ranges in the future. 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.
- steveklabnik 4mo ago
  Async engines are one of the worst things you could have chosen as an example. They are wide and varied, with a ton of different tradeoffs for different scenarios. Ones for high performance networking are also complex, requiring tremendous engineering effort, and are massive. Putting something in the stdlib doesn’t magically make something better maintained. 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.
- yencabulator 4mo ago
  > but not even compromising on an async engine 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.

bulbar 4mo ago

I don't follow Rust closely, but I somehow love that they just did it. I like C++, but it would be much less confusing if the committee dared to change the language or std from time to time. Instead, they only ever extend (with super rare outliers).

pjmlp 4mo ago
For better or worse, that is one reason why many of us still reach out to C++. Especially because ISO languages always have to care about multiple implementations, C++ isn't alone in this.
- ameliaquining 4mo ago
  Note that the thing Rust is doing here doesn't break backwards compatibility, because of the edition mechanism. C++ doesn't have that (I don't know if they've considered adding it), so they can't do anything about language footguns without compatibility breaks. 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++.
  - steveklabnik 4mo ago
    > (I don't know if they've considered adding it) 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.
  - pjmlp 4mo ago
    Editions for the time being don't cover all language evolution scenarios, e.g. breaking changes on the standard library, and having incompatible crates on the same build talking to each other.
    - ameliaquining 4mo ago
      Is anybody contemplating nontrivial breaking changes to the standard library? When env::set_var and env::remove_var were marked unsafe, that was done across an edition boundary even though it's unsound to leave them as-is in older editions. Do you have a particular scenario in mind for incompatible crates? This doesn't seem like a language evolution problem.

pjmlp 4mo ago

Agree, not only Go, this would have been the approach in Java, C#, and C++, with newer namespace, or new data type.