Not Rust itself, but I really hope we can finally get BSN in Bevy in 2026.
1 Like
I want everyone designing and developing Rust and suggesting new features to watch this:
The worst programming language of all time
It's basically a rant about all the misfeatures of C++ and how it got that way. Every little feature added to a language ends up dictating how future features can look. It's a horribly complex puzzle where every little steps locks in what steps you can take next. Which can very easily lead one to a place other than where one wants or should be.
We have seen this so many times: ALGOL to ALGOL68 for example, C to C++ as many other standards evolutions.
5 Likes
Warning: It's 2 hours long.
Sorry it's a bit long. One can listen while doing the washing up or something.
Of course the other great work on how language decisions today dictate what you can do in the language tomorrow is Bjarne Stroustrup's book from decades ago: "The Design and Evolution of C++". In there he explains pretty much all C++ features and why they are done the way they are. As I read it back in the day many times I had the thought that some feature or other was done in a really weird or unpleasant way. But then Bjarne explains the reasons the feature had to be done that way and not any other. Mostly to be inline with C. Then you find yourself thinking "Yeah, OK, that's how it has to be" and accepting it as inevitable. That train of logic has continued with all the new C++ features over the decades, always they are done in some complex, ugly way because to do it the nice way is ruled out by previous language choices. All the while never being able to fix old misfeatures and problems. Leading to the monster that is C++ today.
Maybe there is no way to prevent this "language rot" happening. After all it seems to require seeing into the future.
1 Like
I don't believe that's necessary.
Putting aside the fact that every design decision will constrain what can be done in the future, there is an approach that I've not seen many PLs take in their design i.e. a design from first principles (this goes for package managers too btw).
When a PL is designed from first principles, generally you end up with nicer designs that make more sense, are easier to reason about, and yeah, have better aesthetics (in the mathematical sense) than the result of ad-hoc design will be.
Since C was fit for purpose but rather ad-hoc when it was first designed, that carries forward today in both C and C++.
I find Rust to be somewhere in the middle on this spectrum btw, there are definitely things in rust that are designed from first principles (eg borrowck, and arguably typeck), but there are also things that are either ugly hacks or the result of ugly hacks (e.g. pinning, or the lack of a library-first approach to rustc components, and perhaps even macro_rules, as convenient as that can be at times) that result in solutions that are unsatisfactory, and the way they came about looks a lot like C++'s evolution i.e. "yes it's ugly but it has to be this way because <reasons>".
3 Likes
I was sort of thinking about that after I posted. Wouldn't it be great if a we had a set of concrete rules, principles, that could be used from the outset to guide language development. Then whenever some language feature is suggested we could check it against those rules and see if it violated any of them.
That begins to sound like mathematics with its axioms on inference rules. Against which all future theorems can be tested. Think Euclid's Elements.
But even in maths it's not so clear. Euclid being the classic example. He laid down his axioms of geometry and derived lots of things from it in a beautifully consistent way. But the some folks came along and decided to forget the thing about parallel lines and see what happened. Which gave us the non-Euclidean geometry.
Also maths notation has changed over the centuries as well. And mathematicians have a habit of reusing symbols for totally different things (overloading)
I'm afraid I have a lost cause here.
1 Like
As a licensed C++ hater I was quite curious about this video. But I only had strength for the first 20 minutes or so. Even putting aside shit-post-quality ai-generated-memes constantly being displayed, the quality of speaker's arguments are just so bad. It is debatable if "rants" by nature can allow themselves to be more emotional and not so strict when it comes the the argumentation (I don't believe in this, but I can see someone making this argument). But the arguments against C++ presented here as laughable.
OP mentions some real design problems C++ has, however he does not explain why it is a problem. For example he talks about many ways of data initialisation for about 20 seconds without even mentioning why it is so dangerous. And then he spends an absurd amount of time focusing on things that don't matter (or compared to other flaws C++ has are very far down the line of its problems).
For example we can hear following arguments:
- namespaces are bad, because they require a lot of typing
- In order to define constructor you need to write the name of the class 4 times (two times in the header and two times in source file), but in Java you just need to do it twice, therefore
Java > C++ - or my favourite one: "[...] another example of something that is dead simple in other languages, but complicated in C++ is creating a global variable. [...] a fundamental basic thing that would take two seconds to learn in any other language." where OP does not explain why is it "hard", and completely ignores that this is only example of internal compleity of actually having global shared memory (and that other languages might be simpler, by basically cheating).
This goes on and on. It went to the point, where I wanted to interject him and start defending C++! I can only suspect how infuriating must be listening of those bad-faith "arguments", for someone who actually enjoys this language. If someone would create similar video about Rust and filled it with a bunch of half-assed arguments I would have thought that it was made by an idiot and that it is not even worth trying to discuss anything with them.
I believe that "rants" as this are part of the reason why "Rust community" has very negative image in many people's opinion. Although OP does not explicitly performs his critique from the Rust user perspective, by association real arguments against C++ can be ignored by many people. Therefore I (as a big critic of C++) think it is even more important to publicly criticise this kinds of "video essays". They do much more harm than good, as in the essence they are nothing more than an emotional circle-jerk.
3 Likes
That must be a very important part, and I agree with what you said.
C++ was invented in a busy period where languages were exploring and testing new paradigms. Stroustrup started working on it in 1980, and he took the inspiration from the OO language Simula, for its more abstract, close-to-human nature, and from the imperative language C, for its efficient, low-level and general nature. That way, programmers could use a high abstraction that is still efficient and close enough to the hardware. Had he chosen another family like ALGOL/Pascal (or maybe even Ada, since there had been a number of publications at that point), it could have been different, but those languages were mainly for scientific applications (and embedded systems for Ada).
I don't have the impression that there were many concerns for robust code and safety then. Maybe designing a language with a more complex memory model and more safety in general would have been considered as a luxury at the time for that sort of usage.
The same could be said of security: crypto wasn't yet what it was today; it was still well guarded by the NSA, even if scientists had started challenging them (DH and RSA were relatively new). Viruses existed, but more as the occasional prank than a real threat.
Coroutines, lambda expressions, type inference, and algebraic types were already known, but were not included from the start, and maybe not considered early enough for a smooth integration. I honestly don't know the reasons behind it[1].
However, even if I'm not a fan of C++ any more, I find it hard to reproach a language that's been around 40+ years for becoming so complex when there's pressure to include more features. Maybe it was inevitable indeed, and maybe it's time to create a new one.
I don't believe it's the worst programming language of all time, but I suppose it's a little clickbait in order to get attention. Most of all, I'm a little perplexed when I see someone creating a Youtube account and making a 2-hour-long video (and is that a synthetic voice?) to criticize every little detail and comparing that to a language born not even 15 years ago, which had the luxury of insight from more than half a century of PL evolution, thanks partly to languages like C++. It must be a very frustrated programmer.
Maybe it can be used as a warning for the language evolution, but it'd be more educational to consider several languages objectively and see why they introduced something that ultimately proved to be a mistake. Who knows what the constraints and pressures will be during the next 25 years for Rust?
I'm not even sure those features are bad in C++; I'm just looking briefly at its evolution. ↩︎
1 Like
I think you hit the problem on the head. I always imagined C++ as being like building a huge multi-storey complex of apartments, shops, restaurants and a casino on top of the foundations of a couple of wood cabins. Using the same principles. The results being an unstable edifice where the doors don't close the windows are draughty the roof leaks and the whole thing could collapse at any moment.
I will agree the arguments were not presented in any depth. But as a list of gripes it all fits well with my experience of using C++ for far too many years. It could have been longer...
Anyway, my purpose in pointing out that vid is not really to bash on C++ but to illustrate the problems of every one's wish list getting added to a language.
1 Like
The part you quoted wasn't my opinion, just what I heard him say once.
You're obviously being sarcastic. I don't disagree with the analogy for the recent versions of C++, as far as I can tell (which is not very far 
), but earlier versions of C++ were fine. The language was just that: a more abstract language that could still be used at low level. Nothing is perfect, of course; I would have preferred interfaces instead of multiple inheritance, I was using printf instead of the stream rigmarole, and I was missing features like lambda and coroutines... Nothing major, though.
This is like playing go. When the stones you put later make the previous stones useful, they are all well balanced and each one is optimal.
1 Like
Interesting what he would have done had he not been at Bell Labs - "extending C" with still experimental OO features might not have been the choice...
We would have ended up with Objective C, or maybe Clascal.
OOP is simply too alluring for GUI, when you don't have enough resources.
And it works well enough for that, it only falls apart when you attempt to make it reliable: you end up with something gigantic, unwieldy… and still unreliable.
I need the three logic operators: AND, OR and NOT.
Those were included from the start. Perhaps you're referring to operator overloading i.e. traits for those operators that allow impls for user-defined types?
I'm pretty sure Rust already has those logical operators.
Maybe he wants alternate syntax? In C++ you may write something like this:
int main() <%
int x<::> = <%1, 2, 3%>;
int bitand y = x<:0:>;
y = 2;
std::cout << x<:0:>;
%>
When you go all the way in that direction program starts looking weird, but using and, or and not could be useful, sometimes.
not is more noticeable than !, for one thing.
2 Likes
I meant standard alternative operator representations. They make the code more readable.
What I need are the and/or/not logical operators, not the symbol versions like &&/||/!. I’m cool with both operator notations existing side by side.
You got me.