It’s definitely easier to reason about than C++ because it errs on the side of safety and explicitness. You can use things you don’t understand without fear which straddles the boundary in a good way IMO. To your point that doesn’t make it simple.
As a work-a-day hacker it’s completely become my go to language when I’m writing tools, libraries or just want to knock out a simple algorithm to prove myself right or wrong.
See... I don't think that's true, and argue the huge body of C++ code and talent in the ecosystem is an existence proof to the contrary.
I mean, sure, C++ has its crazy edge cases and its odd notions. But you don't need to understand the vagaries of undefined behavior, or the RVO, or move semantics to write and deploy perfectly sensible code. Literally hundreds of thousands of people are doing this every day.
Now, that may not be a convincing argument about the value of that code. But it's absolutely an argument about the utility of the language in aggregate.
I'll be frank: probably 40% of professional C++ programmers aren't going to be able to pick up Rust and be productive in it, at all. And at the end of the day a language for The Elite isn't really going to mean much. We've had plenty of those. Rust is the new APL, like I said.
I'm not really arguing about the value of that code either, just that it's probably wrong, probably trivially breakable due to the sheer mountain of complexity underlying it. The compiler just happened to let it through because it can't help you. The language doesn't give it enough information to do so effectively.
Just off the top of my head, std::move doesn't... move [1]. It just returns an, I kid you not "static_cast<typename remove_reference<T>::type&&>(t)" without doing... anything. You can keep on using the old value probably, silently, until out of the blue, it stops working one day. Then you're super, duper sad. Even modern language features are, I don't want to say lies, but "hopes and dreams" the compiler can't enforce. It's like if you really wished C++ had Rust's features, but you can't without breaking things, so you give it your best shot, which ends up just creating yet more complexity.
Rust's answer is...
let x = Value::new();
let y = x;
let z = x; (COMPILER ERROR: X GOT MOVED INTO Y)
C++'s modern features are to Rust's equivalents what the ruined fresco [2] was to the original. If you stand far enough back, it's basically right. If you get up close it's hilariously and trivially broken.
It takes a lot of gymnastics to call this language approachable or understandable. It's basically a coal powered car made of foot-guns. That doesn't mean it's not a car, or that it won't get you where you're trying to go, I'm just saying it's an open question how many pieces you'll arrive in.
> Just off the top of my head, std::move doesn't... move [1].
I mean that makes sense in a (somewhat nonsensical) way, std::move is a marker for "you can move this thing if you want".
The much weirder part is that even if a value is moved it's not moved, it's carved out, you get to keep a shell value in a "valid but unspecified state". Reusing that value (which the compiler won't prevent) may or may not be UB depending on the exact nature of the operation and state.
Oh and of course that a change / override to the caller and recompile can change the behaviour of the callsite entirely (e.g. a previously moved value is not moved anymore, or the other way around) but that's pretty common for C++.
I'm curious, what has given you the impression that Rust is a language "for the elite"? It certainly has some rough edges around learnability, but I don't think anyone is actively trying to discourage people from picking it up. Rust is certainly hard for experienced programmers because some common patterns in other languages are not allowed by Rust's rules, but that's no different than trying to apply OOP in a functional language.
> But you don't need to understand the vagaries of undefined behavior, or the RVO, or move semantics to write and deploy perfectly sensible code.
Don't you kind of have to though? These invariants are in your code no matter what, in the case of Rust they are checked by the compiler (you don't necessarily have to understand every nuance, because it's checked for you), in C++ they aren't checked and are a potential bomb waiting to go off.
Perception always lags reality, and it definitely was hard to learn when I picked it up 3-4 years ago. Things have improved so much since then, with non-lexical lifetimes in R2018, better compiler errors, stdlib standardization, RLS + VSCode, etc.
I know you're trying to compare it to APL as that language mostly died off and is thus obscure, but I think the analogy is a little off.
While APL is weird, it is actually really easy for me (someone with less than 15 hours playing with the language in total over the past few years) to code up some basic scripts a lot easier than something like C++.
I'm being absolutely serious too. C++ is pretty low level and as a Python coder I feel like I'm sinking in quicksand with everything required to do something simple. APL is basically built around passing arrays of numbers or strings to weird symbols that operate on the whole array. This means I can do text processing with only a few symbols and a library function (and all interactively) where C++ requires lots of boilerplate and debuggers and compilation and pointers. In short, APL seems to be a lot less complicated than both Rust and C++ in my opinion and most using it have very little formal programming experience and have no problem picking it up from what I've read.
I know what you were essentially trying to say though.
I picked APL because it matches the "WTF cray cray" aesthetic that Rust's syntax presents to new users. I can see an argument that Ada is the right analogy if you're going for pure complexity.
And yes, Fortran, APL, Ada (also Modula-2 & Oberon, Smalltalk and a bunch of other forgotten languages presented as the Next Big Thing at the time) are all uniformly simpler than either C++ or Rust. The modern world is a more complicated place and programming tools have kept up.
That's a powerful endorsement of COBOL, but a lot of language success is “when did it become common”, “who was sponsoring it or what libraries did it come bundled with”, and path dependence that makes momentarily (due to transient conditions) sensible choices into standards that are mandatory for decades.
I don't think anybody is denying that C++ was (and is) unusually useful, simply by virtue of being the only serious game in town when you need that whole "don't pay for what you don't use" thing, and general performance stemming from that. And devising a better replacement that retains that feature is hard, which is why C++ had so much time to entrench.
But it doesn't mean that we can't do it better these days.
> I'll be frank: probably 40% of professional C++ programmers aren't going to be able to pick up Rust and be productive in it, at all.
Well, a certain number of professional programmers are past the point of being willing to learn new technologies, so maybe that's true. But close to 100% of the people who might become professional C++ programmers could instead become professional Rust programmers.
As a work-a-day hacker it’s completely become my go to language when I’m writing tools, libraries or just want to knock out a simple algorithm to prove myself right or wrong.