There aren't millions. Maybe thousands which are completely insane considering Trump didn't kill any US citizen, unlike Haminayi killing 50k of his own people.
My nickname on here would at least suggest so. I think Grok is the closest option since they were working on making a snarky insulting version of their bot. Tame that down a bit and one could get the personality of Bender. [1]
Also neighbours tend to be very glad to receive free stuff :) I usually end up with way too many Basil plants every season and give them away, gotten to know some new neighbours that way!
Mature lanagues like CPP should stop adding more features to the language/std. Adding features to the language just makes it more complex, and adding to the std library just adds more overhead, and maybe even security issues.
This particular feature impacts only compiler writers, unless you choose to use it. You can write C++ till the end of time and never use std::is_within_lifetime and it will have zero impact on you or your code. If it gets used in stdlib, there's presumably a reason, and if there isn't, then that's worth criticizing. But adding the feature has no impact on 99% or more of all developers.
That’s assuming a developer owns all the codebases they work on. Many don’t, because they work for an employer with a large team and a large existing codebase. If the language evolves and the project manager is 100% keen on adopting new features then it’s going to affect everyone on the team.
You can just set -std=c++03 and program like the language never evolved if that's your personal preference.
Other than that, there's always an interesting psychology at play in software engineering but it really seems to come out when people talk about C++ for some reason. Complexity is just needless bloat when it's a feature you aren't using, and it's an essential part of the language when it's a feature you are.
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.
> 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.
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.
The Rust RFC process requires essentially unanimous consent: there's no formal voting procedure, but the various teams can block any feature from going in.
But sure, keep on saying they're basically the same thing.
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.
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.
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.
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?
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.
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.
reply