I'm far more productive in Rust than I am in C. The amount of time I spend writing for loop boilerplate alone is worth the price of admission.
Pretty much all of the ergonomics improvements this year have been improving on things you can't do in C to begin with. Like automatic serialization (serde). Or const generics. Or error handling via ?. Or pretty much any reasonable string manipulation ever.
There's a legitimate debate to be had with the ergonomics of C++ vs. Rust (though I think Rust wins there too). But not with C. C, as a language that makes you jump through hoops to even get a hash table, doesn't even come close.
I suppose pretty much everyone here already knows, but when making this specific type of comment ("I'm far more productive in Rust than C"), can you please disclose that you are one of the core people involved in Rust/Servo?
It's almost like Chuck Moore coming on HN and saying he finds Forth to be the most productive language. Of course it is, for you. (Nothing against the productivity of Forth or Rust.)
I'm a relative beginner in both Rust and C and I'd like to say that, as much as the learning curve for Rust could be better, even for a beginner, Rust is light years ahead of C, especially if you've used a more modern language. And using a hash table as an example is actually pretty sharp. Someone used to python might not know how much of a pain any type of container is in C. You could reasonably make the case it's easier to use hash tables in assembly -- the C language does you essentially no favors.
Rust is quite amazing, though. Very slick, to the point where I use it and I don't care that much about things running fast or with low memory requirements, I just want something with the syntax and comprehensibility of python/ruby/etc (at least compared to erlang/elixir, which I'd otherwise use -- not having local mutable variables makes things a bit more puzzling for no reason like three times a day) and the sweet tools from haskell, and Rust fits the bill.
people write better c than c++ because they are less tempted to over-architect. We've all come across terrible meta-templated c++ code with abuse of OOP all in the name of "information hiding". The main problem against c is the puny standard library. It would be nice to have a few more built-ins.
I think c++ without inheritance would be a very nice language.
C has so many design flaws, from the lack of reasonable iterators to null pointers to the preprocessor to bizarre type syntax to switch fall through to terrible error handling to no generics, etc. The attempts to patch the more broken parts of its design (e.g. ergonomics favoring signed induction variables in for loops) have resulted in more problems (e.g. signed overflow being undefined behavior). As a language from 1978, it was good in its day, but it's not worth saving anymore. It should become a respected piece of history.
I am always startled by people who hate inheritance "lock stock and barrel". I have long-running memories of being utterly appalled by multiple inheritance - all the way back to having to learn how to answer those damn "how many pure virtual base classes can dance on the head of a pin?" type questions in my 3rd-year C++/soft-eng class.
But single inheritance, used judiciously, has really led to some vastly better designs in my experience and doing away with inheritance would generally mean those designs would just be redone with a clumsy "let's fake up inheritance" interface.
I think you can write bad code in any language. Bad C++ is especially egregious, as it's possible to make the bad code practically incomprehensible even at a surface level. However, I suspect that carving feature after feature away from C++ leaves a language that is now just as good for writing toy programs ("hey, look how elegant the language is now that pesky inheritance/template/exception/<insert hated feature of choice> is gone"), but will now allow you write verbose and shitty (but shallowly more understandable) code in place of the C++.
I do find the sheer size of C++ objectionable (the usual arguments about how nearly all C++ programmers seem to program in subset "house styles" of the language). I am generally very suspicious of efforts to replace C++ that come from people who don't seem to understand it at all, however. Generally I like Rust in this regard as the Rust approach seems to display a mature understanding of what was actually good about C++ (constrast: Go).
Inheritance is usually really great when you want to extend the type outside the context it was created in.
GUI is a very clear example of that where composition may work but is greatly tedious (reimplementing the whole interface, exposing it, and rewiring), and sum types are right off the bat inapplicable.
I was including Linux there, as it follows a standard UNIX architecture.
There is a big difference in having POSIX support and being a UNIX.
Windows, IBM i, IBM z/OS, Unysis MCA ClearPath, Green Hills INTEGRITY OS, Genode and many other OSes have POSIX support, yet their architectures have nothing to do with UNIX.
In lesser languages this tends to translate to "you need to deal with code using bizarre pre-processor coding and/or external code generators". glib*-stuff is a neat example for the former (although a lot of it's code and most of the architecture is overall bizarre, not just the pre-processor parts), things like Qt and some libraries parsing stuff using generated parsers / lexers are typical examples of the latter.
Pretty much all of the ergonomics improvements this year have been improving on things you can't do in C to begin with. Like automatic serialization (serde). Or const generics. Or error handling via ?. Or pretty much any reasonable string manipulation ever.
There's a legitimate debate to be had with the ergonomics of C++ vs. Rust (though I think Rust wins there too). But not with C. C, as a language that makes you jump through hoops to even get a hash table, doesn't even come close.