> much easier ecosystem for things like data structures and more complex libraries that make writing many programs much easier than in C.

So many people have implemented those data structures though, and they are available freely and openly, you can choose to your liking, i.e. ohash, or uthash, or khash, etc. and that is only for a hash table.

Those complex libraries are out there, too, for C, obviously.

The reason for why it is not in the standard library is obvious enough: there are many ways to implement those data structures, and there is no one size that fits all.

I followed the discussion about Rust in Linux.

One comment talked about not using a (faster) B-Tree instead of a AVL-tree in C, because of the complexity (thus maintenance burden and risk of mistakes) it would add to the code.

They were happy to use a B-Tree in Rust though

There are! But composability is easier in the languages that have generics/templates/etc. There's less passing around of function pointers and writing of custom comparator functions, using something like binary search or sort as an example, and the fact that those comparators can be inlined can often make the rust or C++ version faster than the "as simple to write" C version.

Obviously, all of these languages are capable of doing anything the others can. Turing complete is turing complete. But compare the experience of writing a multithreaded program that has, as part of it, an embedded HTTP server that provides statistics as it runs. It's painful in C, fairly annoying in C++ unless you match well to some existing framework, pretty straightforward in Rust, and kinda trivial in Go.

When it comes to multithreaded programs, I much prefer Go over C, too. :)

I also like Ada, it has built-in concurrency support, but I typically pick Go (and Elixir) these days. It used to be Ada and Erlang before.