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

21–30 of 39 posts

Re: Announcing Rust 1.96

#21

Post by pjmlp »

wahern wrote: post #16
honr wrote: post #15

Earlier quoted context omitted.

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…

It worked well for C++ during its first decade, each compiler had quite nice frameworks with kitchen sink approach.

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.

Re: Announcing Rust 1.96

#22

Post by pjmlp »

estebank wrote: post #14
metaltyphoon wrote: post #11

Earlier quoted context omitted.

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

Which is why I always give library evolution as one example why editions don't solve everything as many people think they do.

Re: Announcing Rust 1.96

#23

Post by pjmlp »

TazeTSchnitzel wrote: post #7
Tuna-Fish wrote: post #2

I honestly didn't expect the ranges to be ever fixed, I just expected they would remain as an eternal wart. I wonder how painless the transition will be.

When the new edition rolls around that swaps to the new type, I expect a bunch of libraries are going to get really annoying to use. And vice-versa for new libraries with the old editions.

I will watch it quite interested, as it tends to be an example I give where editions don't really work as people expect.

Re: Announcing Rust 1.96

#24

Post by honr »

pjmlp wrote: post #21
wahern wrote: post #16

Earlier quoted context omitted.

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…

It worked well for C++ during its first decade, each compiler had quite nice frameworks with kitchen sink approach. 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…

C++ (the language) and its extreme complexities (each perhaps added for a good reason at the time, and then held together with backward compatibility as glue) reduced itself to gcc and clang. Not the std lib. The std lib is, de facto, removing some of the complexity.

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.

Re: Announcing Rust 1.96

#25

Post by casey2 »

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…

That's just rust culture there is no changing it at this point. How many tools are new users exposed to in the first hour of the language? 'rustup -> rustc -> cargo -> random nonstandard crates, toml, git' (and then the optional rustfmt, language server, ide, clippy)

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.

Re: Announcing Rust 1.96

#26

Post by pjmlp »

honr wrote: post #24
pjmlp wrote: post #21

Earlier quoted context omitted.

It worked well for C++ during its first decade, each compiler had quite nice frameworks with kitchen sink approach. 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…

C++ (the language) and its extreme complexities (each perhaps added for a good reason at the time, and then held together with backward compatibility as glue) reduced itself to gcc and clang. Not the std lib. The std lib is, de facto, removing some of the complexity. 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 b…

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

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.

Re: Announcing Rust 1.96

#27

Post by Tuna-Fish »

wahern wrote: post #16
honr wrote: post #15

Earlier quoted context omitted.

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…

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

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.

Re: Announcing Rust 1.96

#28

Post by j1elo »

steveklabnik wrote: post #13
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.

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.

Re: Announcing Rust 1.96

#29

Post by metaltyphoon »

pjmlp wrote: post #22
estebank wrote: post #14

Earlier quoted context omitted.

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.

Which is why I always give library evolution as one example why editions don't solve everything as many people think they do.

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.
Post reply on HN