Fair words to the Rust community

community
#1

In "This week in Rust" 383 (last week of the time from this post), the first blog article is The biggest threat to Rust's sustainability which said

Unfortunately, there is one thing that makes me anxious about its future: the 6-week development cycles. It’s, I believe, one of the causes of an unhealthy problem: feature bloat. It’s also the cause, in my opinion, of another problem: the immaturity of the ecosystem.

and later he said

Learning materials quickly become obsolete : Programming in Rust today is entirely different than what was programming in Rust 1.5 years ago (mainly due to async-await hitting stable). Rust’s learning curve is already high enough to discourage people from learning it, the obsolescence of tutorials and guides does not help.

I personally feel those judgement are pretty unfair according to my experience during the last 1.5 years. Yes, the language introduced async-await, and for that purpose impl Traits which is the most significant changes I think. However, apart from that, I didn't see any big issues here - I have a project left behind 2 years ago and just picked up again recently, I didn't find any significant differences that make my code not working or looked outdated.

Of cause, I am still doing major refactoring but this is basically changes of the community and slightly better grammar - for example, I replaced the crate failure with fehler and derive-more to do basically the same thing, and clippy now gives more advices that I need to improve my code.

Compare to another project I left behind, which is a React frontend, now it seems to be another world - the Typescript standard has been changing quickly and I have to learn a bit more to get rid of some of the warnings/errors.

So I think we have no reason to blame the 6-week development circle. It worked better than that author thought, at least for me.

23 Likes
#2

Criticism of the Rust development cycle generally strikes me as FUD. Coming from a C++ background, I don’t think Rust is changing any faster than other current languages, including modern C++. C++ adds new language and library features at a similar rate, but in three-yearly drops of committee-designed features that are only partially (if at all) tested in production and require the implementations time to catch up or converge on. (Admittedly, it’s got a lot better in the catch-up and testing regard in recent years.) Like C++, Rust is committed to maintaining compatibility with old code, albeit via a different mechanism. The steady Rust cycle with editions and discrete opt-in testing features seems vastly superior to me! (Edited as typed in a hurry)

6 Likes
#3

This post was flagged by the community and is temporarily hidden.

2 Likes
#4

If the critisism is well argumented I think it is valid and necessary for Rust community.

2 Likes
#5

Surely, 6-week cycle is not similar rate to 3 year cycle?

#6

I’m thinking about the summed total features added over say a 3-year period. Rust releases a new compiler every six weeks with generally minor self-contained incremental new features. I’ve only been using Rust for about a year, and keeping an eye on it for a couple before, so I may well be wrong, but my impression so far is that the total rate of change is comparable to what I’m used to in C++. The same arguments about relevance and breadth of learning materials and best practice apply, along with old code continuing to work just with whatever drawbacks it had when it was written that way—and you can still write code the old way if you choose to.

2 Likes
#7

Moderation note: Folks please keep this conversation constructive. These forums are not a place to vent unconstructively. Please avoid posting flamebait. Before posting, please consider whether your comment meaningfully contributes to and advances the discussion forward.

6 Likes
#9

I actually disagree with you. If you are releasing every 3 years you have to learn new things (granted more of them) every three years, not every 6-weeks. Tbh, I prefer longer cycles, but rust is too young and they still have so many things to iron out that they simply have to do those iteration as quickly as pos. If they were releasing every 3 years, rust at this stage where it is, would become forgotten and irrelevant in my opinion.

#11

In practice, I need to learn new things about Rust every day, regardless of its release cycle-- I learn only enough to solve today's problem, and then get back to work. With the importance of 3rd-party crates to the ecosystem, the compiler's release cadence barely makes a dent in the pace of change I have to deal with.

9 Likes
#12

That is because you still learn rust. If you were at the stage where you more or less felt very comfortable with every aspect of it then you would most likely feel/think differently.
Just imagine, requirement to learn something every 6 weeks to do your job vs every 3 years.

#13

Well, my job is "Computer Science Researcher," so learning new things is kind of the entire job description. The more you learn about a large topic, the more you realize how much more there is to learn-- Nobody will ever "be comfortable with every aspect of it." The only sensible strategy I've found is to learn what's necessary for the task at hand, and leave everything else to be learned later.

That's part of why backwards compatibility is so important: Once you've learned how to do something one way, it'll continue to work even if it ceases to be the best practice.

11 Likes
#14

Yes, I know, and I'm also in that boat, but there are so many different things (not just rust) that we need to know/learn, that in my view it would be nicer if one could learn new language/features every 3 years not every 6 weeks.
This has nothing to do with being lazy, not wanting to learn or anything similar.
There is as you rightly pointed out so many things to learn that one specific thing (language) which requires you to learn every 6-weeks is high demand on already busy schedule of every developer.

1 Like
#15

We may just have to agree to disagree, then. I find it much easier to internalize many small changes over time than a big dump of changes all at once. And most of the changes in each release aren't directly relevant to me, anyway. My reaction to most changes in the release notes is always something like "That makes sense. If I'm ever working with that part of the language, I'll appreciate having it." If all of these changes get batched together from a multi-year period, I'd need to set aside at least half a day to even triage the changes, much less learn any of them.

12 Likes
#16

I think that the rapid release criticism/opinion is more-so relative to the example set by C.

#17

It depends what era you're talking about. Early on there were a great variety of C compilers that offered differing features. And even since the ISO standardization, compilers have continued to add and expand on their own extensions (few people actually use pure ISO C, although perhaps that's more viable nowadays). It's true the pace has slowed now... and yet compilers still release new versions fairly frequently.

Rust is young and many features exist but remain incomplete. Most recently const generics was released in an MVP state (and it took years to get to that point). And this is a part of much wider const work. Should they have waited until it was completely finished before releasing the whole thing at once? What if it's not ready for the arbitrary three year release window? Rush to get it in anyway? Or let it gather dust for three years even though it's almost ready now? These are trade-offs that, e.g., C++ has to deal with.

Besides, Rust doesn't make truly major changes often. And when it does you can safely ignore them. Even if you're committed to using the latest and greatest libraries it often takes quite some time for new features to filter through the ecosystem.

3 Likes
#18

The C WG has no plans for coming up with new language features. They just want to polish small details and make a few compiler extensions official. Microsoft is not interested in any new C features that aren't also in C++, so for C there literally is no other future than either staying as-is forever, or gradually becoming C++.

And I think that C's "inevitable path to C++" is used as a boogeyman to scare languages from evolving, as if accumulating complexity of C++ was the only possibility.

But that's nonsense. Look at PHP for example. Early versions were terrible, but the latest ones are pretty good actually. Language evolution managed to fix a lot of stuff. Similarly JavaScript managed to evolve from being a toy language to the language of choice for probably a majority of applications these days. Java has been evolving for quite a while, and I haven't seen anyone complain about it. C# and Ruby are doing pretty well too. Python had a misstep in how it handled evolution, but after migration, I think people will agree that v3 is a better language than v2 was.

And the frequency of releases has nothing to do with speed Rust evolves. If it released 10 times less frequently, it would just make 10 times bigger releases.

18 Likes
#19

You are not required to do that. Since they keep backwards compatibility, you are free to keep yourself always within the same language set. Or you could study again with each new edition. Hopefully, there is a big announcement with each edition to help people update. If there are obstacles from introducing warnings or lints, then perhaps it would be a good idea to have an easy way to opt out of them.

1 Like
#20

Rust editions are meant to be a rallying point, if you don't want to keep up with the 6-week cadence.

5 Likes
#21

I have been learning rust for the last 3 years, and sort of actively developing with it for the last 2, and honestly since Rust 2018 and the release of async/await, I see no major changes. I feel more confident programming in Rust than in any of the other 3 programming languages I know, and that alone means a big deal to me.

I don't see why people want Rust to be as boring and obsolete as those languages it's attempting to replace to begin with.

8 Likes
#22

I've found the pace of updates to the language to be just fine. (There's a few things I wish would hurry up, but that's just me.)

1 Like