There’s a reason both Go and Rust eschew exceptions. They’re something that superficially seemed like a great idea but that in practice complicate things by creating two exit paths for every function. They also don’t play nice with any form of async or dynamic programming.
C++ should never have had them, but we have sane clean C++ now. It’s called Rust.
IMO the pendulum swung too far with Rust. The experience is better than C++, but the template generics system is not very powerful. They ostensibly made up for this with macros, but (a) they're annoying to write and (b) they're really annoying to read. For these reasons Rust is much safer than C++ but has difficulty providing fluent interfaces like Eigen. There are libraries that try, but AFAICT none match Eigen's ability to eliminate unnecessary allocation for subexpressions and equivalently performing Rust code looks much more imperative.
Rust doesn't have a template system per se. C++'s templates are closer to C's macros. Rust has a typed generics system which does impose additional limits but also means everything is compile time checked in ways C++ isn't.
I agree that Rust's macros are annoying. I think it was a mistake to invent an entirely different language and syntax for it. Of course Rust also has procedural macros, which are macros written in Rust. IMHO that's how they should all work. Secondary languages explode cognitive load.
I'm not attached to the word "template", I just wanted to clarify that they're not Java-style generics with type erasure. If you'd like me to use "monomorphizing generics" instead I'm game :)
Even procedural macros are annoying, though. You need to make a separate crate for them. You still need to write fully-qualified everything, even standard functions, for hygiene reasons. Proc macros that actually do, erm, macro operations and produce a lot of code cause Rust's language server to grind to a halt in my experience. You're effectively writing another language that happens to share a lexer with Rust (what's the problem with that? Well, if I'd known that I'd need another language to solve my problem I might not have chosen Rust...).
For all its warts, using constrexpr if and concepts, is much more easier to do macro like programming than dealing with Rust's two worlds of macros and special syntax.
If static reflection does indeed land on C++26, this experience will be even better.
Rust panics are basically exceptions, aren’t they? Typically they aren’t caught without terminating. But you totally can. And if you’re writing a service that runs in the background you’ll probably have to.
Rust Result is basically a checked exception. Java makes you choose between adding an exception to "throws" or catching it, Rust makes you choose between declaring your function as returning Result or checking if you got an Err.
The only difference is that Rust has better syntactic sugar for the latter, but Result is really isomorphic to Java checked exceptions.
Panic could be said to be the same as an unchecked exception, except you have a lot more control on what causes them. The panic you get from calling unwrap() on an Option is the same as a NullPointerException, but you have full control on which points of the program that can generate it.
Rust goes to substantial lengths to allow unwinding from panics. For example, see how complicated `Vec::retain_mut` is. The complexity is due to the possibility of a panic, and the need to unwind.
I’ve never written any Java so your comparisons are lost on me.
Rust Result is great. I love it.
The root article was talking about C++. Rust panic is basically the same as a C++ exception afaict. With the caveat that Rust discourages catching and resuming from panics. But you can!
Catching panics is best-effort only. In general, Rust panics can't be caught. (Even if a program is compiled with panic=unwind, this can change to abort at run-time.)
If you find that exception-free code that is necessarily littered with exit value checks at every call, which discourages refactoring and adds massive noise, then you can call the decisions to eschew exceptions as “sane” and “clean”, but I find the resulting code to be neither. Or practically speaking, exit codes will often not be checked at all, or an error check will be omitted by mistake, thereby interrupting the entire intended error handling chain. Somehow that qualifies as a better outcome or more sane? Perhaps it is for a code base that is not changing (write-once) or is not expected to change (i.e. throwaway code written in “true microservice” style).
It is better. That doesn't make it perfect but it's better.
This is to be expected, in fact Rust has to be a lot better to even make a showing, because C is the "default" in some sense, you can't just be similarly good, you have to be significantly better for people to even notice.
I expect that long before 2050 there will be other, even better languages, which learn from not only the mistakes Rust learned from, but the mistakes in Rust, and in other languages from this period.
Take Editions. C was never able to figure out a way to add keywords. Simple idea, but it couldn't be done. They had to be kludged as magic with an underscore prefix to take advantage of an existing requirement in the language design, in C++ they decided to take the compatibility hit and invalidate all code using the to-be-reserved words. But in Rust they were able to add several new keywords, no trouble at all, because they'd thought about this and designed the language accordingly. That's what Editions did for them. You can expect future innovation along that dimension in future languages.
It's categorically better because it's memory-safe. We just had another RCE bug in the Windows TCP/IP stack and it's 2024. This should not be happening.
C++ should never have had them, but we have sane clean C++ now. It’s called Rust.