I dunno. I take the position that language designers have blind spots around the weaknesses of their languages.
Python: Python is almost a hard-compiled language. Most of the dynamic stuff that's really hard to compile isn't all that useful. But Guido and his enablers love the dynamism, and the CPython implementation. So instead of PyPy taking over, we have CPython with hacks to call C.
Go: The "share by communicating" thing in Go works out about as well as it does in other languages, that is, it's useful but not central. Early on, there were tortured examples of implementing locks with queues. Nobody does that any more. People pretty much write Go like they do other languages, with shared state and locks. Queues are used when queues do something useful. The real strength of Go is that the libraries needed for webcrap are maintained and used by Google, so they're all well-tested and exercised. Also, goroutines/green threads eliminate the sync/async distinction. Garbage collection takes care of most ownership problems. Simple. (I recently wrote a web back end in Rust. Big mistake. Should have used Go.)
Rust: The "traits" system is an overreaction to Objects Are Bad. Rust probably would have been better off with single inheritance, which is well understood. (Multiple inheritance has too many dark corners.) People keep trying to do OOP with traits, which is like pounding a screw. Rust still doesn't have a good solution to the back reference problem, as I point out occasionally. The macro language sucks, but then almost all macro languages suck. "Async" is a nightmare but necessary to keep the Javascript crowd happy, since that's all they know. If you really need complex multiprocessor concurrency, Rust is currently the best game in town. Most people don't.
C++: They can't take anything out, and the cruft is too deep. "Modern C++" is not all that bad, but all of bad old C/C++ is still in there. So the safety situation remains awful. The cumulative complexity is now so high that even long-time language lawyers are giving up following it.
Javascript: Who thought that would rule the world? It's awful, but everywhere. Heroic efforts have made an inherently slow language go fast. It's kind of impressive, actually.
As far as I'm aware, Rust's trait system is more closely related to Haskell's type class system than to actual object-oriented programming. As a type class system, it is fine; it is a different mindset than classic OOP. Rust happens to also use this same system for something more closely resembling traditional objects, but this is much more restricted than either.
As a rubyist: traits are strictly typed ducktyping. I love them.
Python: I get how PyPy is better in some ways, but calling C libs is the most important feature of Python. It doesn't have a lot going for it otherwise.
Go: Greenthreading is a big deal in backends. Arguably the main reason for Kotlin is because Java didn't have that, but now there are vthreads. Rust has chipped away at the Go systems use cases, so it's mainly for backends and CLIs now, but I wish it had better error handling.
Rust: There's a very good preso from the Rust team about how they arrived at async/await, and also how every other language does concurrency. Greenthreading was considered, main problem being you need a runtime for that.
C++: Torvalds was right about it all along.
JS: Honestly the best high-level language, made better choices than Python, never made huge breaking changes, somehow had a decent answer to cooperative multitasking before most other langs, deserves its popularity.
I generally agree with your sentiment.
> Rust: The "traits" system is an overreaction to Objects Are Bad.
It's interesting. Interfaces, traits, and mixins are all OOP concepts.
> "Async" is a nightmare
In what way? I do agree though, that it's annoying to yet again have a new language not have concurrency baked into the language. In some ways, Rust has excuses, because they want their concurrency primitives to support microcontroller, real-time Linux, and general purpose programming.