[flohofwoe]

In my case: because writing C code (specifically C99 or later - designated init and compound literals!) gives me joy in a way that neither C++ nor Rust provide (C++ was my go-to language for nearly two decade between ca. 1998 and 2017), and I tinkered with Rust a couple of years ago, enough that I realized that I don't much enjoy it.

IMHO, both C++ and Rust feel too much like puzzle solving ("how do I solve this problem in *C++*" or "how do I solve this problem in *Rust*?"), when writing C code, the programming language disappears and it simply becomes "how do I solve this problem?").

PS: I agree that the C standard isn't all that relevant in practice though, you still need to build and test your code across the relevant compilers.

[mathstuf]

Maybe we just work on different kinds of software, but I feel like I'm actually solving problems in Rust when I'm using it. I don't have to think about all the terrible string manipulation APIs and how they can come back and bite me, who owns what is something I still have to decide except that the compiler actually helps out, and I have access to nice APIs that solve ancillary problems for me already (e.g., rayon, serde, etc.). I can't wait for the day when another parser will never be written in C again.

In C, I feel like I'm building a house out of tinker toys, C++ is Lego Techniks, and Rust I'm using bricks and mortar. FWIW, Python feels like waterballoons and drywall to me; while it might look OK from the outside, one thing pierces your exterior and things tend to sag sadly from there.

[flohofwoe]

> terrible string manipulation APIs

Don't use (most of) the C stdlib, it's useless and hopelessly antiquated (not just for string manipulation), instead use 3rd party libs.

> who owns what is something I still have to decide except that the compiler actually helps out

Lifetime management for dynamically allocated memory in C should also be wrapped in libraries and not left to the library user. In general, well designed C library APIs replace "high level abstractions" in other languages.

But I agree, the memory safety aspect of Rust is great, and I'd love a small language similar to C, but with a Rust-like borrow checker (but without all the stdlib bells'n'whistles that come with it, like Box<>, RefCell<>, Rc<>, Arc<>, etc etc etc...) - instead such a language should try to discourage the user from complex dynamic memory management scenarios in the first place.

It's not the memory safety in Rust that turns me off, but the rest of the 'kitchen sink' (for instance the heavy functional-programming influence).

[mathstuf]

> use 3rd party libs

And now I have more problems ;) . (And I develop on CMake; consistently using external deps is a nightmare.)

The thing is that I usually am that library author (or working in an area that acts like that).

I'm not sure what you expect to be left if you say "the stack is all you can use" (which is what I understand to be remaining when you remove those "bells'n'whistles").

I also really enjoy the functional aspects. I don't want to think about what some of the iterator-based code I've done looks like in C or C++ (even with ranges).

[flohofwoe]

> "the stack is all you can use" (which is what I understand to be remaining when you remove those "bells'n'whistles")

Not what I meant, heap allocations are allowed (although the stack should be preferred if possible), but ideally only with long lifetimes and stable locations (e.g. pre-allocated at program startup, and alive until the program shuts down), and you need a robust solution for spatial and temporal memory safety, like generation-counted index handles: https://floooh.github.io/2018/06/17/handles-vs-pointers.html).

[mathstuf]

Yeah, I feel like we work in completely different realms of programming. Which is fine; there are plenty of languages out there for all kinds of use cases. FWIW, pre-allocation absolutely doesn't work when you support loading GB-size datasets. You certainly can't leave it sitting around forever either once it is loaded.

[steveklabnik]

What is your favorite 3rd party string library? I'm aware of several, but haven't used any of them in anger.

[anfilt]

"IMHO, both C++ and Rust feel too much like puzzle solving ("how do I solve this problem in C++" or "how do I solve this problem in Rust?"), when writing C code, the programming language disappears and it simply becomes "how do I solve this problem?")."

This statement very much resonates with me. It's honestly one of the things I like about C. Although it's not perfectly like this for me all the time. For example string manipulation is not great.

An other aspect I like about C is there is not a plethora ways of doing the same thing which I have found always made it more readable than rust and C++.

[Mindless2112]

In contrast, when I write C, I spend far too much time thinking "how do I solve this problem without causing undefined behavior?"

[flohofwoe]

That what UBSAN is for (along with ASAN, TSAN, static analyzers and compiler warnings, just dial everything to eleven and you can offload a lot of that thinking to the compiler - it's not the 1990's anymore ;)

[Mindless2112]

UB sanitizers can only show that your code has undefined behavior, not that it does not. And the results are only as good as your tests. Those sanitizers are also not available with old embedded toolchains.

I do dial up the warnings to 11, yet it is not enough.

I've written C code that's currently running on hardware orbiting the earth. I'll never do it again if I can help it; it wasn't worth the stress. You only get one chance to get it right.

[flohofwoe]

> I've written C code that's currently running on hardware orbiting the earth.

I guess in such a situation I would not not trust any compiler (for any programming language), no matter how 'safe' it claims to be, but instead carefully audit and test every single assembly instruction in the compiler output ;)