Hacker News Reader

Comment by devit | Hacker News Reader

For some reason the Rust project seems to be plagued by glacial development speed, with features taking years and years to be stabilized after design and often even after initial implementation.

Not sure why, progress used to be way faster years ago.

For example, this "four year plan" should be implemented in 6 months at most, not 4 years.

And the "long-term features" that "should be considered carefully, could not be addressed in the next few years" (lol, seriously?!?) should have serious work start right now and be released as part as the next edition in 2024 (since they need an edition break to be ergonomic). These are basic misdesigns of the type system that should have been fixed 10 years ago.

Whoever is managing and paying for the Rust developers needs to fix this.

View on HN

> For some reason the Rust project seems to be plagued by glacial development speed, with features taking years and years to be stabilized after design and often even after initial implementation.

I wonder if it feels this way just because Rust has such a fast development cycle. But like, most languages takes years and years to do something like async. Rust went extremely fast, relative to other languages.

> For example, this "four year plan" should be implemented in 6 months at most, not 4 years.

That seems kind of insane. What language goes from idea to shipping major features in 6 months? Who even wants that?

When you want to ship features that essentially will have to be maintained forever, and can't be meaningfully changed after shipping, you don't rush into things without a strong belief that you've gotten things as right as you can.

Consider the bit in OP about wanting to add a Move trait and deprecate Pin, and reverse the semantics so types are immovable by default. That's a difficult change to make now, after async has been stabilized. Obviously in this case the longer, deliberate process didn't save them from this (apparent) mistake, but overall new big language features should never be rushed.

> For example, this "four year plan" should be implemented in 6 months at most, not 4 years.

Now that just sounds reckless to me.

> Not sure why, progress used to be way faster years ago.

Yes, and the language was qualified as unstable for evolving so quickly. Move fast and people complain, move slow and people complain. They lose both ways.

I find the development cycle to be quite good: they ship features and improvements and refinement, and I don't need to rewrite my codebase every three months because something subtly broke.

Because "stabilized" means that the feature is effectively frozen and every subsequent change must be backwards compatible. Even edition changes are restricted by the need to ensure that the vast majority of code at least can be forward-ported by automated means. So you really don't want to stabilize a new feature unless you're super confident that every part of it has the absolute best design.

Reply on news.ycombinator.com