4 ms·

I've been a C programmer for several years now (out of necessity - C is still the best language for firmware and embedded development) There's been a lot of no

I've been a C programmer for several years now (out of necessity - C is still the best language for firmware and embedded development) There's been a lot of noise on the internet about Rust and C++20 and "modern" languages. I recently had an opportunity to try some of these first hand. Honestly the new language features are all terrible with few exceptions. In general, anything that was added to a language to support generics or to hide pointers and memory management from the developers on a language that isn't a lisp has only produced more harm than good. I grew up as a programmer always thinking about the underlying CPU and the underlying memory and how my code would interact with both of them. It requires greater care as a programmer and tools like static analysers, code reviews and rigorous testing are extremely important. Improving these tools and coming up with new ones is far more useful (in my opinion) than trying to update C. Yes C has it's flaws. Sometimes, those flaws are important and a replacement language is useful. I find that Go is a very interesting replacement for C at sufficiently higher up the stack. Something like Haskell probably will best fill in the gaps between C and Go. I'm not convinced that fixing C with something like C++ was a good idea. Similarly, anything that's trying to fix C++'s problems is unlikely to come up with a decent way to have generics and hide memory and pointers from developers. If I was going to create my own language, I'd keep it like C, remove some of the undefined behaviors, add support for Posits, 128 bit and arbitrarily wide signed and unsigned integers, features for explicit cache management (!!!), container classes as part of a standard library, Go-lang style interfaces and bake in something like cppcheck into the compiler. /rant

metalliqaz 7y ago
I feel the same way you do, but I still want to spend more time getting to know Rust.
SuspiciousSwan 7y ago
Even a subset of that would be amazing to me -- "removed all of the undefined behaviors, added 128 bit signed and unsigned integers, features for explicit cache management (!!!), and container classes as part of a standard library"
lhweroiuwer 7y ago
> remove some of the undefined behaviors, There was a great talk from a C/C++ compiler writer about why you can't remove undefined behaviors while at the same time keeping C like speed. Simple example: accessing an array past it's end it's undefined behaviour. If you want to remove this, you need to add bounds checking (either to raise an error or to just return 0).
- tynorf 7y ago
  I haven't actually watched it in a while, but are you referencing this talk by Chandler Carruth? https://youtu.be/yG1OZ69H_-o https://youtu.be/yG1OZ69H_-o
- T-hawk 7y ago
  > you can't remove undefined behaviors while at the same time keeping C like speed. This is absolutely correct. The specs of C allow so much undefined behavior in order to let the compiler just emit the instructions for the arithmetic operation or memory access or whatever. For edge cases like overflow and bounds, C deliberately says "not my problem" and you just get whatever that hardware architecture happens to do with that instruction. It's a deliberately leaky abstraction.
  - juped 7y ago
    It's more that things were left undefined for portability and compiler authors (ab)used them for optimization enough for that to become de facto true (especially now that portability is easier).
    - favorited 7y ago
      And if all C users decided that, now that portability is much easier, it was time to define some of that behavior, it would happen. But, as much as people want to blame optimizing compilers for their behavior around UB, absolutely no one is going to sacrifice C's performance for safety.
      - 7y ago
xtian 7y ago
Have a look at Zig and Odin.
wolrah 7y ago
> I grew up as a programmer always thinking about the underlying CPU and the underlying memory and how my code would interact with both of them. It requires greater care as a programmer and tools like static analysers, code reviews and rigorous testing are extremely important. This is the double-edged sword of C and other lower level languages though. The programmer is given great power over their environment, but as the saying goes with great power comes great responsibility. Not all programmers are capable of handling that responsibility, and even those who are make mistakes from time to time. If you don't need the power, there's a strong case to be made for giving some of it up in exchange for also reducing the number of ways you could misuse it. There will always be a place for low level programming in performance-critical code or extremely resource constrained environments, but there's a lot of software out there that spends most of its time waiting on I/O or user interaction while running on systems with gigabytes of free RAM and a half dozen idle cores. In those cases I believe the use of safer languages should be encouraged.
mrlala 7y ago
>In general, anything that was added to a language to support generics or to hide pointers and memory management from the developers on a language that isn't a lisp has only produced more harm than good. Why should I care or need to worry about pointers and memory management in every part of my code? Yeah as a C# developer I need to be aware if I'm passing a variable by value or reference.. but I don't want to and should not need to define this all the time. I know that built-in simple types (int, string, double) etc are passed as value... and everything else is passed as reference. So it's basically a non-issue. I grew up learning C/C++ and having to deal with all the crap. Why oh why do I want to handle all of this myself? I just want to code and focus on getting things done... C#, for example, allows me to do that. You saying these things have "produced more harm than good" is so obviously coming from a more academic standpoint, or purist in the sense of "oh my god he doesn't even realize that those 8 bytes are going to be held up until the garbage collector comes, whereas I can deallocate that precious memory right away!". Sorry but almost no one cares. Yeah there are times where you need to care, but for most developers that time is... never. The elitist attitudes on HN are astounding sometimes. Heaven forbid someone code without also managing every aspect of the underlying hardware!
- 4D1 7y ago
  How do you think these luxuries you were provided were given to you? If you are operating within a managed usermode level of an operating system then what you say is perfectly valid, especially for programs that do not require high availability such as web servers. You can program in a managed environment and trust in your languages JIT/GC to handle low level optimization. On embedded systems, software that requires high availability (video games for example), or kernel mode drivers and firmware, you are not always allowed that luxury. Understanding of and strong micromanagement of how memory is allocated and moved around the system becomes more and more crucial. It could be hardware limitations of the device that cause this, or in the case of firmware or drivers, any overhead that would be acceptable in a usermode application will be felt throughout the environment when you work on low-level. TLDR you and the parent post are talking about apples and oranges.
AnimalMuppet 7y ago
For embedded, C++ can still be useful. You just won't use most of it. I still like using classes; destructors can free up more resources than just memory. But yes, you can get most of what you need out of C. I also suspect that Haskell fits above Go, not between Go and C. Other than that, I'm pretty much in agreement with you.
nimrody 7y ago
Have you looked into Zig (https://ziglang.org/ https://ziglang.org/)? It's a little more than what you've asked since it does support compile time generics. But is specifically targeted at removing undefined behavior and improving safety.
- audunw 7y ago
  I can second this recommendation. Zig is really the best language I seen so far at attempting to be a direct replacement to C (Rust is good too, but maybe a bit too advanced.. feels more like a C++ replacement) The compile time generics is kind of necessary to replace some of the stuff people use C preprocessor macros for. I think Zig is just taking the idea of having compile time evaluation of code to its natural conclusion, and it ends up being a lot cleaner than C with preprocessor magic. The only thing they've added which isn't necessary for a "better C", is the async stuff they're working on now. But I think it's still a good idea.
jgwil2 7y ago
> In general, anything that was added to a language to support generics or to hide pointers and memory management from the developers on a language that isn't a lisp has only produced more harm than good. I understand why you would want explicit memory management, but what specifically is harmful about generics?
chillingeffect 7y ago
I understand it's against the rules to suggest someone hasn't read the article. But I think it's pretty clear from this comment that the article has zero to do with the posted article. The article's title was provocative and humorous, bc it's abt using C in a very peculiar way. It's not about the tired argument of "should we replace C with Rust/etc." which the above poster and many others have glommed onto. This waterfall of irrelevant comments has no place next to this article which is abt a very specific, interesting set of techniques.
- deleted 7y ago
  [deleted]
Upvoter33 7y ago
Great post. In particular: "remove some of the undefined behaviors" I think the confusion caused by this is not nearly worth the optimization gained. Compiler folks will say "but look, this loop is 58% faster!" but ignore the fact that slow code can be optimized through other means, including profiling, restructuring, etc.
- beached_whale 7y ago
  Or avoid them when your compiler hasn't documented if they support it. Such as gcc supporting union type punning in c++. Many compilers allow for reinterpret_cast'ing too, e.g. gcc and -fno-strict-aliasing This is more of knowing your language and tools. UB isn't some magic beast either, it's where it isn't really feasible for a language that runs on many platforms to dictate what happens. What should the std's say when you shift a signed int too far? Often the HW will have a way of doing it and others will not, so either don't do that or know your implementation
  - deleted 7y ago
    [deleted]
UncleMeat 7y ago
> I grew up as a programmer always thinking about the underlying CPU and the underlying memory and how my code would interact with both of them. It requires greater care as a programmer and tools like static analysers, code reviews and rigorous testing are extremely important. And yet, even projects filled with extremely strong engineers who participate in all the best practices and run interprocedural static analysis and sophisticated fuzzers still write piles of security vulns in c programs.

metalliqaz 7y ago

I feel the same way you do, but I still want to spend more time getting to know Rust.

SuspiciousSwan 7y ago

Even a subset of that would be amazing to me -- "removed all of the undefined behaviors, added 128 bit signed and unsigned integers, features for explicit cache management (!!!), and container classes as part of a standard library"

lhweroiuwer 7y ago

> remove some of the undefined behaviors, There was a great talk from a C/C++ compiler writer about why you can't remove undefined behaviors while at the same time keeping C like speed. Simple example: accessing an array past it's end it's undefined behaviour. If you want to remove this, you need to add bounds checking (either to raise an error or to just return 0).

tynorf 7y ago
I haven't actually watched it in a while, but are you referencing this talk by Chandler Carruth? https://youtu.be/yG1OZ69H_-o https://youtu.be/yG1OZ69H_-o
T-hawk 7y ago
> you can't remove undefined behaviors while at the same time keeping C like speed. This is absolutely correct. The specs of C allow so much undefined behavior in order to let the compiler just emit the instructions for the arithmetic operation or memory access or whatever. For edge cases like overflow and bounds, C deliberately says "not my problem" and you just get whatever that hardware architecture happens to do with that instruction. It's a deliberately leaky abstraction.
- juped 7y ago
  It's more that things were left undefined for portability and compiler authors (ab)used them for optimization enough for that to become de facto true (especially now that portability is easier).
  - favorited 7y ago
    And if all C users decided that, now that portability is much easier, it was time to define some of that behavior, it would happen. But, as much as people want to blame optimizing compilers for their behavior around UB, absolutely no one is going to sacrifice C's performance for safety.
    - 7y ago

xtian 7y ago

Have a look at Zig and Odin.

wolrah 7y ago

> I grew up as a programmer always thinking about the underlying CPU and the underlying memory and how my code would interact with both of them. It requires greater care as a programmer and tools like static analysers, code reviews and rigorous testing are extremely important. This is the double-edged sword of C and other lower level languages though. The programmer is given great power over their environment, but as the saying goes with great power comes great responsibility. Not all programmers are capable of handling that responsibility, and even those who are make mistakes from time to time. If you don't need the power, there's a strong case to be made for giving some of it up in exchange for also reducing the number of ways you could misuse it. There will always be a place for low level programming in performance-critical code or extremely resource constrained environments, but there's a lot of software out there that spends most of its time waiting on I/O or user interaction while running on systems with gigabytes of free RAM and a half dozen idle cores. In those cases I believe the use of safer languages should be encouraged.

mrlala 7y ago

>In general, anything that was added to a language to support generics or to hide pointers and memory management from the developers on a language that isn't a lisp has only produced more harm than good. Why should I care or need to worry about pointers and memory management in every part of my code? Yeah as a C# developer I need to be aware if I'm passing a variable by value or reference.. but I don't want to and should not need to define this all the time. I know that built-in simple types (int, string, double) etc are passed as value... and everything else is passed as reference. So it's basically a non-issue. I grew up learning C/C++ and having to deal with all the crap. Why oh why do I want to handle all of this myself? I just want to code and focus on getting things done... C#, for example, allows me to do that. You saying these things have "produced more harm than good" is so obviously coming from a more academic standpoint, or purist in the sense of "oh my god he doesn't even realize that those 8 bytes are going to be held up until the garbage collector comes, whereas I can deallocate that precious memory right away!". Sorry but almost no one cares. Yeah there are times where you need to care, but for most developers that time is... never. The elitist attitudes on HN are astounding sometimes. Heaven forbid someone code without also managing every aspect of the underlying hardware!

4D1 7y ago
How do you think these luxuries you were provided were given to you? If you are operating within a managed usermode level of an operating system then what you say is perfectly valid, especially for programs that do not require high availability such as web servers. You can program in a managed environment and trust in your languages JIT/GC to handle low level optimization. On embedded systems, software that requires high availability (video games for example), or kernel mode drivers and firmware, you are not always allowed that luxury. Understanding of and strong micromanagement of how memory is allocated and moved around the system becomes more and more crucial. It could be hardware limitations of the device that cause this, or in the case of firmware or drivers, any overhead that would be acceptable in a usermode application will be felt throughout the environment when you work on low-level. TLDR you and the parent post are talking about apples and oranges.

AnimalMuppet 7y ago

For embedded, C++ can still be useful. You just won't use most of it. I still like using classes; destructors can free up more resources than just memory. But yes, you can get most of what you need out of C. I also suspect that Haskell fits above Go, not between Go and C. Other than that, I'm pretty much in agreement with you.

nimrody 7y ago

Have you looked into Zig (https://ziglang.org/ https://ziglang.org/)? It's a little more than what you've asked since it does support compile time generics. But is specifically targeted at removing undefined behavior and improving safety.

audunw 7y ago
I can second this recommendation. Zig is really the best language I seen so far at attempting to be a direct replacement to C (Rust is good too, but maybe a bit too advanced.. feels more like a C++ replacement) The compile time generics is kind of necessary to replace some of the stuff people use C preprocessor macros for. I think Zig is just taking the idea of having compile time evaluation of code to its natural conclusion, and it ends up being a lot cleaner than C with preprocessor magic. The only thing they've added which isn't necessary for a "better C", is the async stuff they're working on now. But I think it's still a good idea.

jgwil2 7y ago

chillingeffect 7y ago

I understand it's against the rules to suggest someone hasn't read the article. But I think it's pretty clear from this comment that the article has zero to do with the posted article. The article's title was provocative and humorous, bc it's abt using C in a very peculiar way. It's not about the tired argument of "should we replace C with Rust/etc." which the above poster and many others have glommed onto. This waterfall of irrelevant comments has no place next to this article which is abt a very specific, interesting set of techniques.

deleted 7y ago
[deleted]

Upvoter33 7y ago

Great post. In particular: "remove some of the undefined behaviors" I think the confusion caused by this is not nearly worth the optimization gained. Compiler folks will say "but look, this loop is 58% faster!" but ignore the fact that slow code can be optimized through other means, including profiling, restructuring, etc.

beached_whale 7y ago
Or avoid them when your compiler hasn't documented if they support it. Such as gcc supporting union type punning in c++. Many compilers allow for reinterpret_cast'ing too, e.g. gcc and -fno-strict-aliasing This is more of knowing your language and tools. UB isn't some magic beast either, it's where it isn't really feasible for a language that runs on many platforms to dictate what happens. What should the std's say when you shift a signed int too far? Often the HW will have a way of doing it and others will not, so either don't do that or know your implementation
- deleted 7y ago
  [deleted]

UncleMeat 7y ago