For 98% of tasks Rust is incredible. But modeling those 2% of problems that don't fit neatly into Rusts domain, the level of "unsafe", "PhantomData", and advanced type-system hacks you need feels obscene when I can use some pointers in C++.
Rust also does not have a compelling platform/story baked into the std for low-level asynchronous programming.
High level Mutexes and locks are there, but you're in for a world of hurt if you want to do something like sharded/striped locking, where the actual data being protected isn't directly owned by the lock (see Tokio's "OwnedMutexGuard" for this, thanks to Alex Chi and Victor Yang for telling me about this)
Surely this monstrous code has advantages over C(++) but in no world would I voluntarily write code in this language if other options were viable. I don't get how people prefer this language outside of a very narrow application context where the lasts millisecond of optimization matters.
It's easier to read if you split it into tokens and qualifiers. The & is a reference. The '_ is a lifetime parameter. The things in the <>are types. So this is a function which doesn't mutate self and takes a mutable reference to a formatter with a sensible lifetime and returns a result which will contain either nothing (or a unit) or an error if things fail.
Thank you for posting this. I had to google and read up some things.
But the common practice is to have an alias Result<T> to mean Result<T, whateverErrorWeAreDealingWith>. This doesn't really maps well to doing impls in the Debug trait, since this trait uses an error that is generally different from the error defined by your own application, but with some care, it can be used. Then it becomes:
Okay, but what about the whole rest? it's syntactically heavy, but each part of it is very significant.
Take the <'_>. It means that the Formatter struct receives a lifetime parameter but you opted to explictly omit it. In previous Rust editions, you would keep it implicit
fn fmt(&self, _: &mut Formatter) -> Result<()> {}
But this was confusing and ambiguous! People looked at it and sometimes didn't know there is a lifetime involved - until it showed up in compiler error messages!
Now, there's two elided lifetimes in this snippet: one in the &self and one in the &mut. Rust has clear rules for this case: your snippet means
Once you learn the rules (and here are the rules https://doc.rust-lang.org/nomicon/lifetime-elision.html), this makes the syntax slightly lighter. It's not an issue like the other case because if you know the rule, it's not ambiguous.
The _ in place of the variable name is there just to not give a name to the formatter. It's actually a catch-all pattern (like one in the end of a match). If you wanted to give a name but disable the unused lint, you would write _formatter instead.
The rest, I can't really remove much sacrificing the semantics. The only superfluous thing I love is the ->, which is much better than the C convention of putting the return type before the function name (IMO).
The <> syntax itself for generic parameters sucks, and it's about the worst thing that Rust inherited from the C++ syntax. The :: also sucks, and it's also from C++ (the turbofish ::<> combines both, and it was Rust's brainchild. https://turbo.fish/ [0]) Actually most C++ influences on the Rust syntax is a disaster. I would much prefer to have a Haskell-inspired syntax for types, so that the type Result<A, Box<C>> would be written Result A (Box C)
Except there is one thing C++ might never get, security culture.
It is already better than C, as WG21 at least acknowledges there are some security issues and has taken multiple approaches to try to fix some of the underlying issues.
However the way defaults are managed, versus the compiler provided frameworks from pre-C++98, are completely the opposite that security minded developers would wish for.
The NSA cybersecurity bill seems to finally have hit home that this needs to change, however it remains to be seen if those at ISO that care about it will be able ot steer the ship around with their paper proposals like P2657R1, P2723R0,P2687R0.
Bjarne keeps adocating the adoption of Core Guidelines and static analyzers improvements, which in a world where clang struggles to catch up, seems to have quite low priority in tooling improvements.
In a way I guess it depends how relevant many key C++ frameworks and workloads (HPC/HFT/games/LLVM/GCC/FPGA/GUI) will evolve and what Rust can manage to take over.
I will openly say I think Rust is an all-around better language. If you are building general-purpose systems software, or just want to write fast software, use Rust.
If you are fiddling with bits, doing low-level concurrency, writing a GC/Memory Manager etc, or have self-referential datastructures like graphs or trees, you're going to have an order of magnitude easier time writing it in C++. (Rust-experts excepted)
Also, the developer experience writing C++ is worse than Rust by miles. Though the tooling (fuzzing, LSP, debugging, sanitizers, etc) is stellar, likewise with Rust.
I agree with this, but also sadly note structures like trees are sadly quite common, in the type of code I write anyway. It is a bit of a niggle I have with Rust.
I had to use recursion to build a tree in AoC '22 day 7. I needed to have both a mutable stack of current tree nodes (`cwd` if you like) and the tree structure. Or equivalently a doubly-linked tree, where nodes point at their parent. It was a bit ugly.
In C++ you just write it.
I get why it's hard in Rust, just saying, it really does crop up.
I prefer modern C++20/23 to Rust.
For 98% of tasks Rust is incredible. But modeling those 2% of problems that don't fit neatly into Rusts domain, the level of "unsafe", "PhantomData", and advanced type-system hacks you need feels obscene when I can use some pointers in C++.
Rust also does not have a compelling platform/story baked into the std for low-level asynchronous programming.
High level Mutexes and locks are there, but you're in for a world of hurt if you want to do something like sharded/striped locking, where the actual data being protected isn't directly owned by the lock (see Tokio's "OwnedMutexGuard" for this, thanks to Alex Chi and Victor Yang for telling me about this)