Rust is already a huge language. The editions are also 3 years apart. And between them are tons of new features.
Strange. EcmaScript/JavaScript kind of adds like 5-6 features every year. Python.
C on the other hand is great. What you wrote in 1990 still is understandable today? (not that C is the best language out there)
In addition, frequent releases do a better job of incentivizing taking the time to get the design right, because the consequence of missing a release window is that it gets delayed a few weeks, or maybe a few months, instead of a few years. You can totally see this happen with C++ for example.
That's a weird example. In my career I've noticed big stylistic changes over the years in C. I can usually point out C code from the 90s right away. Usually it just has dated style or is missing what are now common libraries or features. C didn't have a standard bool type until C99 which is usually a good sign of code's age. I remember once I came across some mid-90s code written with the pre-ANSI style of function declarations. It was the first time I'd ever seen it and I was confused on how it even compiled.
Outside stylistic things, there are a few idioms and features that I've never seen in newer code bases that might be lost on some newer developers. I can't think of many times I've seen longjump used in modern C.
* Restricting the rate of new releases doesn't necessarily mean you're reducing the average feature development rate. It might instead mean that you're releasing hundreds of new features per release, which is definitely worse than releasing a hundred versions with one feature each, because it can force people to rush things out to meet a release window instead of releasing them when they're actually ready.
* Restricting the number of feature bullet points per release doesn't necessarily mean you're reducing the amount of functionality being developed. It might instead mean that people try to develop huge "super-features" that technically count as one bullet point but actually gets used in dozens of different ways. Super-features are an easy way to wind up with a system where everything is possible, but the stuff you do every day is more difficult than it needs to be.
If the Rust team refuses to ship the features in stable releases, people are just going to use unstable releases and that will make the experience worse for everyone.
There is no way to artificially restrict features unless you have multiple software in the ecosystem that needs time to update: for C it is the other compilers following the C standard, for Python it is the Python executable on your end- user's machine. The minute rustc updates, Rust developers have little reason not to use the features.
How is this a problem? The crate authors targeting nightly features know full well that they are restricting their pool of users, while at the same time driving the testing and design of nightly features forward. If no one is actually using them, then they are unlikely to get quickly stabilized.
> If the Rust team refuses to ship the features in stable releases
Can you show a case of refusal to ship a needed feature?
> Rust developers have little reason not to use the features.
Rust developers of end user applications don't. Crate authors do, if they want to gain wide adoption.
Those languages have also been around long enough for the new language features to "cool down".
Rust was also designed from the beginning to have the language be able to move quickly and safely in this manner (just like Rust code itself!).
You're also forgetting the HUGE migration pains that resulted from JS. The gigantic gaps between ES3 and ES5 and ES6. Oh, did I forget ES4? Nope. It was cancelled. Not even going to get started on the disaster that was Python 2->3 or how wildly different the original K&R C is to modern C (I have the K&R book handy to prove it).
I honestly find it hilarious that those languages you chose each had terrible migrations between versions, where Rust differences between versions barely make a dev bat an eye.
I think there are many people who might actually agree with this. Tbh, I think anyone making the argument the other is making, would rather Rust follow the path of C than the path of C++.
If you ever need to debug code in a dependency, then you'll probably need to read code that targets a different edition than your home project does. Over a long enough time frame, you're going to need to at least be able to understand all of the editions.
The difference between "New Hotness" and "Feature-itis" is subjective, but I do enjoy the new python featues immensely.
The same was true of OpenGL until they moved on to Vulcan, and they seem to be getting the idea that things dont really have to change so much. Or maybe they're just shifting to making other "standards" instead.
To me Rust is more of a toolchain development at this point, where language features are added where it makes sense rather than being a goal.
I've heard a professor say "C is the best assembler out there" ... felt insightful