A lot of Graydon's ideas feel like interesting extensions to ML-style languages. I bet if he had continued down that path, it would have been a lot more of an experimental language with a hodgepodge of different ideas. Which is totally valid (you need these languages to test new paradigms and features), but definitely would not have become mainstream.
Basically, I view Grayson as a leader who set the tone for Rust being a language that was willing to take ambitious swings on cutting edge features. But I don't think he would have been the person to eventually make the cuts and compromises necessary to hew the language into a cohesive, mainstream language. Rust ending up as a replacement C++ helped it not only determine which features to keep and which rules to follow, but also helped it create the right pitch for developers to use it.
This does lead to a larger question about BDFLs. Perhaps, like CEOs, the BDFL you want when you're starting a language is not the BDFL you want when you're maturing a language, or maintaining a language. Especially around feature selection, in the beginning it may pay off to add a lot of features based on user feedback, but later on it may be better to push back more. And from a psychological standpoint, I have wondered about the pressure of being a BDFL. Grayson has been open about stepping down partially due to reaching his limits, and I suspect other BDFLs have thought about it too. The job sounds exhausting and thankless. At a certain point, wouldn't you want to leave and start a new project? And wouldn't we want the person who had success once to give it another shot?
If anything, it's more a C replacement than a C++ replacement. It will take some market share from both of course (and other languages to a lesser extent too), but functionality-wise, it just isn't (currently, at least) practically able to replace some C++ use cases.
(Not your parent) Many people point to more advanced meta programming, such as variadrics, higher kinded types (though as mentioned GATs advance Rust in this general area), and specialization.
This is just one example, but moves are always bitwise, correct? So if I want an object to track all users of it in C++, I can just make a smart pointer for it whose copy/move/destruction operations notify the object about each event. How would you do that in Rust? (Similarly, what if I want a relative pointer?)
You can track all of this (things like Rc or Arc do) except move.
Relative pointers are possible, depending on what you mean. Making this safe (e.g. preventing users of that type from breaking the relative addressing) is done via the Pin type.
> You can track all of this (things like Rc or Arc do) except move.
Which means you can't track this. Tracking moves is fundamental here.
> Relative pointers are possible, depending on what you mean.
Pretty sure they're not possible in the sense I mean, for the same reason as above - you need custom moves for this. I'm referring to a pointer (not an offset; a pointer) that automatically adjusts itself when copied or moved. So that it always points somewhere N blocks before/after itself.
These are just two examples, to get the point across that Rust actually lacks some capabilities (since somehow that surprises people). You can find more.
I mean, arguably. If it is fundamental for your hypothetical use case, then sure, but this is not required for a lot of use cases, like smart pointers.
Am I the only one who works at a place where things don't make it into production unless at least one other person on the team fully understands the code during review?
Plenty of people don't, it's the most common thing. Maybe right now you are lucky enough to work in good contitions (that's great!), but are you sure it couldn't happen to you in 10 years? I think the standard tools we use in our profession should work in less than ideal conditions as well.
Oh I want my tools to help me, don't get me wrong. I just wonder if all the horror stories I hear are the norm, or just the stories we like to share the most.
In some ways I think Rust is a bad replacement for both. It's an alternative in some ways to C and an alternative in some ways to C++.
I don't think anyone who still uses C today and hasn't lived in a cave for the last 20 years would be very interested in Rust since it's just not at all like using C. There is the rare Bryan Cantrill who for some reason was seemingly unaware that other languages existed from 1990 until 2018 but I think it's safe to say most other people who primarily use C would not prefer the leap to something like Rust.
For the people who use C++, certainly they're already used to a language that wants to dominate, so Rust should be fine. In terms of features, apparently it doesn't hold up, but because it's like C++ I'm sure they're just a couple of years away from adding those things too, and then the language can continue being more important than the actual data transformations the programs are supposed to be doing.
> but because it's like C++ I'm sure they're just a couple of years away from adding those things too
If they're smart (which they are), I'm sure they'll eventually cave and add some of the missing stuff, no matter how much they want to believe these features are unnecessary. Just like how C is finally coming around and adding generics and all that. The particular capabilities I mentioned here wouldn't be impossible to add, and they can probably achieve some of them better than C++ did. But I do think there will remain use cases that Rust will fail to accommodate.
Basically, I view Grayson as a leader who set the tone for Rust being a language that was willing to take ambitious swings on cutting edge features. But I don't think he would have been the person to eventually make the cuts and compromises necessary to hew the language into a cohesive, mainstream language. Rust ending up as a replacement C++ helped it not only determine which features to keep and which rules to follow, but also helped it create the right pitch for developers to use it.
This does lead to a larger question about BDFLs. Perhaps, like CEOs, the BDFL you want when you're starting a language is not the BDFL you want when you're maturing a language, or maintaining a language. Especially around feature selection, in the beginning it may pay off to add a lot of features based on user feedback, but later on it may be better to push back more. And from a psychological standpoint, I have wondered about the pressure of being a BDFL. Grayson has been open about stepping down partially due to reaching his limits, and I suspect other BDFLs have thought about it too. The job sounds exhausting and thankless. At a certain point, wouldn't you want to leave and start a new project? And wouldn't we want the person who had success once to give it another shot?