top | item 47074523

(no title)

alphazard | 10 days ago

What no one wants to hear is rust is destined for the same fate. If you want to see the future of rust, look at C++. Rust has a much better initial state, but the rules evolving the system (the governance model, the kinds of developers that work on it, etc.) are the same as C++ and so we should expect the same trajectory.

Unless you have a system that says "no" a lot, and occasionally removes features, programming languages decay, and the game has been (historically, before LLMs) to pick a language that would be in the sweet spot for the time that you need to use it, while keeping your eye out for something else to switch to once it becomes sufficiently unusable.

discuss

order

jcranmer|10 days ago

> What no one wants to hear is rust is destined for the same fate. If you want to see the future of rust, look at C++. Rust has a much better initial state, but the rules evolving the system (the governance model, the kinds of developers that work on it, etc.) are the same as C++ and so we should expect the same trajectory.

Dear lord that is not the case. The C++ standardization process is extremely different from Rust's specification process, and the resulting pathologies are extremely dissimilar. Hell, C is fairly close to C++ in terms of process, and yet it still has its own set of pathologies.

The C++ committee is dominated not by experts on compiler implementation, but by people looking to get their own proposals incorporated into the standard, and is structurally organized in such a way that it can be difficult for any group to feel empowered to actually reject a feature. It should be noted that in the most recent batch of C++ papers, there was effectively an implementers' revolt: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p39....

The Rust proposal process is much more ponderous, and when you take into account the lag between an accepted RFC and implementation and stabilization (and the fact that some accepted RFCs turn out to be unworkable and effectively get backed out without ever being stabilized), it's pretty clear that the actual development process is night-and-day different. For example, the Try trait in Rust still has yet to be stabilized, despite the RFC proposing it being introduced over nine years ago and a v2 RFC being accepted five years ago.

alphazard|10 days ago

This kind of "but for us it's different" thinking is a little amusing.

I don't care about the implementation process or the RFCs or what-have-you. If there is a democratic committee of humans that decides what goes in, and there is no bias for minimalism (e.g. 1/3 could strike down a proposal instead of 1/2) then the process will tend towards bloat.

hypeatei|10 days ago

Rust intentionally keeps its std library small and makes no promises about ABI; it seems to have resisted a lot of pressure to do the opposite from C++ fanatics. I don't agree that the C++ path is inevitable.

armchairhacker|10 days ago

Even Go is encountering the same fate, albeit slower. It’s nearly impossible to remove a feature once it has seen adoption, especially without an alternative; whereas there are always patterns that are greatly simplified by some new feature, and when a language becomes large, these patterns become common enough that the absence of said feature becomes annoying.

alphazard|10 days ago

Yes agree, we are definitely past peak Go.

Suspiciously, after Rob Pike retired from the project, the amount of language and standard library changes skyrocketed. Many people now trying to get their thing into the language so they can add it to their list of accomplishments.

Clear evidence that you need someone saying "no" often.

raincole|10 days ago

Is there ever a successful programming language that occasionally removes features? Like, not just a big, one-time backward-incompatible upgrade, but occasional feature removal?

lights0123|10 days ago

Python removes features all the time in 3.x releases. For example, I was not a fan of the distutils removal in 3.12 which broke many legacy but otherwise functional packages. Deprecated functions and classes are also removed from packages regularly.

They do publish removal plans years in advance, e.g. see Python 3.17's plans: https://docs.python.org/3/deprecations/pending-removal-in-3....

pjmlp|10 days ago

Java, since Java 9 deprecated for removal really means it.

.NET, the whole .NET Framework to modern (core) .NET migration, left several parts behind, the foor loop semantics change on C#, introduction of field keyword, and with.

simonask|10 days ago

What are you talking about? Rust governance could not be more different from C++.