The author chooses a great video where Scott Meyer implies that the lack of integrity in the C++ programming language and its decision-making committees causes C++ to be a mess. However, the author's conclusions for Rust does not address the matter of integrity: the author simply recommends feel-good band-aids like "Education" and "Maturity".
I suspect the author wouldn't have written this article if he acknowledged that Rust's decision-making committee lacks integrity.
Rust could very much still fizzle, and remain industrially irrelevant indefinitely. Fizzling is objectively guaranteed, by definition, if Rust's adoption rate does not grow by orders of magnitude. All of its ardent fans would surely love for it not to fizzle.
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.
Sorry for asking. But why even add new features in a language every year. Why not make it like once in 5 years? And focus on fixing and improving the language and the compiler.
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)
A lot of the "features" - most of them even - being added to Rust nowadays are just filling holes in the language. Things you might easily assume you could do that for arbitrary implementation reasons, you cannot. A lot of them are basically "fixing and improving the language" IMO.
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.
> C on the other hand is great. What you wrote in 1990 still is understandable today?
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.
How are you planning to limit the rate at which new features are added?
* 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.
Yeah in practice the Rust community writes a lot of code that uses experimental features, that need an explicit feature gate and the nightly build of the compiler. This is less common now, but it was huge during earlier development; a lot of the async work only ran on nightly compilers.
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.
> This is less common now, but it was huge during earlier development; a lot of the async work only ran on nightly compilers.
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.
I feel like you read my entire comment wrong. Like you didn't read what I replied to, stripped all the "ifs" and arguments, and hyper-focused on points I wasn't trying to make. Surely I wasn't as clear as I thought but this feels so strange.
> Strange. EcmaScript/JavaScript kind of adds like 5-6 features every year. Python. C on the other hand is great.
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++.
With language editions, the new features that Rust adds will be mostly a liability for the compiler writers, not the users. So sure you could ask that: why are the language implementors creating more maintenance work for themselves? Well maybe they think those features are worth it.
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.
C++ gets new features regularly because there is a comitte whose job is to do that.
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 suspect the author wouldn't have written this article if he acknowledged that Rust's decision-making committee lacks integrity.