Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Rust 1.96

blog.rust-lang.org

Post reply on HN
Print view View original

11–20 of 39 posts

Re: Announcing Rust 1.96

#11

Post by metaltyphoon »

j1elo wrote: post #9

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

Isn’t this what editions are for?

Re: Announcing Rust 1.96

#12

Post by burntsushi »

j1elo wrote: post #9

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.…

(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-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.)

Re: Announcing Rust 1.96

#13

Post by steveklabnik »

j1elo wrote: post #9

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.…

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.

Re: Announcing Rust 1.96

#14

Post by estebank »

metaltyphoon wrote: post #11
j1elo wrote: post #9

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 Isn’t this what editions are for?

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.

Re: Announcing Rust 1.96

#15

Post by honr »

burntsushi wrote: post #12
j1elo wrote: post #9

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.…

(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-…

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.

Re: Announcing Rust 1.96

#16

Post by wahern »

honr wrote: post #15
burntsushi wrote: post #12

Earlier quoted context omitted.

(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-…

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 node…

Or just make it more difficult to squat obvious namespaces, and add an identity management system (like PGP Web of Trust, but simpler) so you can limit yourself to trusted packages, e.g. packages vouched by your preferred set of root signers who publish compilations of trusted publisher keys.

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.

Re: Announcing Rust 1.96

#18

Post by bulbar »

j1elo wrote: post #9

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.…

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).

Re: Announcing Rust 1.96

#19

Post by pjmlp »

j1elo wrote: post #9

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.…

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

Re: Announcing Rust 1.96

#20

Post by pjmlp »

bulbar wrote: post #18
j1elo wrote: post #9

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.…

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).

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.

Post reply on HN