Rust - Better C++ by being "worse"

So, this week I'm playing with Rust, the new C++-esque language that everybody is raving about.

My conclusion? It's really a better C++, and in some ways much worse.

It fixes a _lot_ of the problems inherent in C++, making it really hard for you to shoot yourself in the foot (unknowingly). However, it also makes it super hard to do anything without reciting incantations that explicitly declare your intentions and thus prevent you from shooting yourself in the foot -- lifetimes, Copy traits, move semantics, "borrowing", Optionals, etc. etc...

The result is a mess of such "safety incantations" that distract from the "actual business logic" of the code. The added heft feels like Rust was a product of  C++ being disowned by C and then went to have a baby with Java.

I'm sure this added heft makes writing rust code much more safe (but not really 100%, hidden panics abound everywhere), and it's probably invaluable if you have a codebase that correctly utilizes these language features, but, man, it's crazy.

I spent the better half of a day trying to read, update, and iterate through a very simple adjacency list. Apparently you don't really use the '[]' operator to do anything to a HashMap -- Instead of adjl[a].push_back(b) , instead you call adjl.entry(a).or_default().push_back().  Otherwise you run down a rabbit hole of panics and mutability woes.

I'm pretty sure this isn't a language I'd be able to understand before being f_cked by C++ a couple times before. Every "annoyance" I have with it corresponds to some fundamental design issue/problem/flaw I encountered with C++, in that sense it truly is a "better" C++.  But then, those "fixes" make the whole language feel "worse" in the sense that when I write C++ they problems don't all smack me in my face as long as I use a "consistent-subset" of the language features...

Here's some (unfinished) code of a simple BFS program I am writing...

Bonus fun question: in std::collections::hash_map::Entry, what is the difference between:

- or_insert()
- or_insert_with()
- or_insert_with_key()
- and_modify()
- or_default() ?

(reference: https://doc.rust-lang.org/std/collections/hash_map/enum.Entry.html )

I doubt many people would be able to understand the answer even with documentation provided... To make things even more confusing, methods like "or_insert()" has a parameter named "default" , but "or_default()" probably takes the value from the default constructor... The explanation text looks almost the same though!

Ensures a value is in the entry by inserting the default if empty, and returns a mutable reference to the value in the entry.

Ensures a value is in the entry by inserting the default value if empty, and returns a mutable reference to the value in the entry.

(guess which is which?)

I can't imagine anyone but people with C++ PTSD could actually have thought this language was viable...

The "V" programming language

Such are the joys of experimenting with a shiny new programming language:

-- and the warning was removed 2 weeks ago in their git repo :0)

Seriously though, although it's new, the language has a good vibe to it.  I wouldn't use it for anything _serious_, but it might be a good choice when you need to do ad-hoc data processing with high speed, and yet don't want to use complicated languages like C++ / rust...

It's been a while since I've played with a new programming language. For now I'm just implementing basic standard algorithms with it as an exercise and feeling it out.