I have a similar issue. I like the memory safety in Rust, but I don't like Rust: it limits my productivity for two reasons. 1. In order to reach memory safety it add abstractions that don't make programming simpler, but harder. 2. It is a language that started to enter the slippery slope of too many ad-hoc features. And given that I work alone, I try to write safe C code as much as I can (it is impossible to reach perfection, anyway), and avoid Rust as much as I can. What I will do more, however, is using more other safe languages when the C low-level control is not needed. Go is a good option, for my tastes.

P.S. I see in realtime, reloading the post, the number of downvotes received (the score goes up and then ways down with the downvotes). Another problem is the Rust community. It has a very peculiar way to stay in this world.

> I don't like Rust: it limits my productivity [...] I try to write safe C code

It's definitely fair to argue that Rust is complex. But this doesn't compute.

You don't like Rust because you're less productive with it so you write... C? Rust is so much more productive compared to C it's not even funny, even with its limitations and extra complexity that are necessary for memory safety. Things that take pages of code in C can be done in a single line of code in Rust.

This starts at fairly fundamental data structures. Need a hash map? In Rust you have one available, out-of-box, with state-of-art performance. In C? Implement one yourself. And good luck getting even a fraction of the performance the Rust one has.

Then there is dependency management and a huge ecosystem of libraries. Do you need to, say, encode an AVIF image? (Something I personally had to do.) Easy. `cargo add ravif`, and two lines of code later you're done.

I can keep on going, but I'm sure you get the idea.

I really honestly don't see how anyone can in good faith argue about productivity and say that C (out of all things!) is more productive than Rust. That Rust is more complex, sure. That you don't like it for aesthetic reasons? Fair enough. But not as productive as C? No way. Perhaps this is where the downvotes you're complaining about come from?

I bet when you say "Rust is more productive than C", what you actually mean is "the Rust stdlib and its wider library ecosystem enabled by Cargo is more productive than what the C stdlib offers", and that is no doubt true. But when you look at just the language, the OPs statement is also no doubt true.

The libraries that make C more productive are out there, they are just harder to find than in the Rust ecosystem.

IME C programmers (including myself) separate a language and its stdlib much more strictly than (for instance) the Rust, C++ or Python crowd, mainly because the C stdlib is pretty much useless for anything that's not a simple command line tool (and because of such restrictions, C programmers also often use a whole language toolbox instead of attempting to write everything in C - Python and C go very well together for instance, right tool for the job etc...).

> I bet when you say "Rust is more productive than C", what you actually mean is "the Rust stdlib and its wider library ecosystem enabled by Cargo is more productive than what the C stdlib offers", and that is no doubt true. But when you look at just the language, the OPs statement is also no doubt true.

No. I also mean that the language itself is more productive, even without the standard library and the tooling. (Although, indeed, to a lesser degree.)

Sum types. Pattern matching. No need to bother with header files. A module system. Proper generics. AST-based hygienic better macros. Procedural macros. Stronger type system. RAII. A proper string type which knows its length. A proper array type which knows its length. Unicode support*. Async + await support. Support for closures. Ergonomic error handling (with the '?' operator). Proper abstraction for iterators.

Do you want me to keep going? Because I can keep going. (:

Again, this is more complex than what you have in C. And it is harder to learn. But that's not what we're talking about. We're talking about pure productivity here, so I'm assuming on one side you have someone who has mastered C, and on the other side you have someone who has mastered Rust. There's just no contest that the Rust person will get things done significantly faster than the C person, because the language itself is so much more powerful. (But of course it's a lot harder to master Rust, so the calculus might be different if you don't want to master your tools.)

* - part of Rust's core so also available in `no_std` contexts, so I don't see it as part of the stdlib but part of the language.

Some language features from your list I agree with (e.g. Rust's "everything is an expression" is really nice), others are just batshit-crazy from my pov (the macro system for instance), others are just more or less random tack-on features (e.g. I don't really see the usefulness of async-await in a systems programming language - especially not when it potentially fragments the library ecosystem).

I would still argue that none of those language features really move the productivity needle a lot into one or the other direction. A good library ecosystem on the other hand does make a difference.

All in all, I would probably add fewer features to C than I would remove from Rust to get close to what I expect from a performance-oriented systems programming language (Zig is actually pretty close to that ideal, but that's a different discussion).

Ah yes, I won't disagree here; macros get very complex very fast. It's one of the more undercooked parts of Rust.

> e.g. I don't really see the usefulness of async-await in a systems programming language

This really depends on the task, but honestly it is genuinely useful. Even in places you wouldn't expect, e.g. in embedded: https://github.com/embassy-rs/embassy

And AFAIK there are plans to use async Rust in the Linux kernel.