Correctness is not just about security. And the threat environment to which a program may eventually be exposed is not always obvious up front.

Also, no: that's only true for some kinds of programs. Rust, c++, and go all have a much easier ecosystem for things like data structures and more complex libraries that make writing many programs much easier than in C.

The only place I find C still useful over one of the other three is embedded, mostly because of the ecosystem, and rust is catching up there also.

(This is somewhat ironic, because I teach a class in C. It remains a useful language when you want someone to quickly see the relationship between the line of code they wrote and the resulting assembly, but it's also fraught - undefined behavior lurks in many places and adds a lot of pain. I will one day switch the class to rust, but I inherited the C version and it takes a while.)

> 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.

It also depends on what you want to get away from.

I don't disagree that Rust might technically be a better option for a new project, but it's still a fairly fast moving language with an ecosystem that hasn't completely settled down. Many are increasingly turned off by the fast changing developer environments and ecosystems, and C provides you with a language and libraries that has already been around for decades and aren't likely to change much.

There are also so many programming concepts and ideas in Rust, which are all fine and useful in their own right, but they are a distraction if you don't need them. Some might say that you could just not use them, but they sneak up on you in third party libraries, code snippets, examples and suggestions from others.

Personally I find C a more cosy language, which is great for just enjoying programming for a bit.

C might beat Rust at simplicity and speed of development (don't know, I never developed in Rust) but I remember why I stopped developing in C about 30 years ago: the hundreds of inevitably bug ridden lines of C to build a CGI back then (malloc, free, strcpy, etc) vs little more than string slicing and "string" . "concatenation" in Perl and forget about everything else. That could have been Python (which I didn't know about,) or the languages there were born in those years: Ruby and PHP. Even Java was simpler to write. Runtime speed was seldom a problem even in the 90s. C programs are fast to run but they are not fast to develop.

String handling is certainly one of C's main weaknesses

> All that security in Rust is only needed if there is a danger of hacks compromising the system.

Rust's safety features help prevent a large class of bugs. Security issues are only one kind of bug.

> C beats it due to simplicity and speed of development

C being faster to develop than Rust is a ludicrous claim.

I don't think its ludicrous.

Rust is a complex language that is safe.

C is a simple language that is unsafe.

There are always compromises and it always depends on the project. Of course importing a dependency is faster in Rust.

But the best language ever imho is Golang. Its simple and safe with the compromise being the GC.

> All that security in Rust is only needed if there is a danger of hacks compromising the system.

It's not just about security, it's about reliability too. If my program crashes because of a use-after-free or null pointer dereference, I'm going to be pissed off even if there aren't security implications.

I prefer Rust to C for all sorts of projects, even those that will never sit in front of a network.