The Last Thing Rust Needs (2019)
h2co3.github.io
h2co3.github.io
I suspect the author wouldn't have written this article if he acknowledged that Rust's decision-making committee lacks integrity.
But after sufficient adoption not to fizzle, its current user base would represent a decreasing <1% of users. The biggest roadblock to all the changes most needed to prevent fizzling are the most vocal of those same, hoped to be, <1%, who are still 100% of an overwhelmingly smaller number of current adoptees.
Many like being different from the hoped-for masses who would need to come on board. They were not put off by what keeps away the still-needed adoptees, and fondly imagine that the language and toolchain can both remain all unchanged and also gain enough traction not to fizzle.
But it really is either-or. The current stance of these vocal Rust users is, in effect, to have chosen to fizzle from poor adoption rate. They love to cite self-selected popularity measures that grossly over-count its users and (non-using) fans as proof it already has all the users it will need. The wider world is not fooled.
It is hard to see any way around core opposition to necessary change. The absolutely normal fate of any new language is to fizzle, and remain forever resource-starved, offering only niche employment.
Even with all the necessary changes, Rust's success is far from guaranteed. It depends on the personal choices of tens and hundreds of thousands of non-users, both those who would need to jump from what they use now, and new programmers-to-be choosing their first language. Their reaction to the changes cannot be predicted with any reliability. All that is certain is that, without, the mass will choose not to adopt.
Fizzling is the default fate of any new language, avoided only by ever-readiness and near-miraculous happenstance. It is sad when this fate is deliberately chosen.
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)
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++.
* 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.
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.
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.
I've heard a professor say "C is the best assembler out there" ... felt insightful
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.
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.
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.