4 ms·

Those who think C is inherently good can’t be convinced otherwise. Any argument will be dismissed with “programmers need do be better”. Any assertion will be di

Those who think C is inherently good can’t be convinced otherwise. Any argument will be dismissed with “programmers need do be better”. Any assertion will be dismissed as subjective, lacking data. Any data backed study from Microsoft [1] or Google [2], [3] will be dismissed as Big Tech hiring mediocre programmers. There will be vague references to “just use the right sanitizers”. Ultimately we need to recognise that for some people, language is a core part of their identity. At that point criticising “their” language hurts them. If we’re talking to someone who feels this way, it’s best to politely say “is that so?” and gently disengage. I know it’s tempting to think that we could show them just one compelling data point that will change their minds. But that’s not any more possible than convincing someone to stop believing in religion by pointing out factual inconsistencies in scripture. If you tell a committed Christian that Jesus couldn’t have been born in 0AD because Herod died in 4BC and the census they were travelling for happened in 7AD … is that going to make them reconsider everything about their religion? No, they’ll dismiss this as a minor issue that can be worked around. Same with $language programmers. 1 - https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/ https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro... 2 - https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet... 3 - https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html https://security.googleblog.com/2022/12/memory-safe-language...

peoplefromibiza 4y ago
> Those who think C is inherently good can’t be convinced otherwise opposite is also true "those who think C is inherently not good [...]" > Any data backed study from Microsoft [1] or Google [2], [3] will be dismissed as Big Tech hiring mediocre programmers. They aren't being dismissed, but criticized when used to promote other languages. Those studies are partial and about a different topic. They are are about bugs in millions lines of code bloated products, written in C++. Not counting the actual implementation "bugs", like the browser X leaking details about users to make fingerprinting easier and then sell ads. You know why those companies are worried about memory safety and nothing else? Because it's the way people can circumvent the so called "features" and "protections" they implement. Here we are talking about Ruby extensions in C, which is a completely different domain, involving completely different tradeoffs. The author confess he's not a great Rust programmer yet, so probably using Rust over a language he knows better, just because Google said it, it's not the best of choices. Just think about the fact that the Ruby interpreter itself is written in C. Think about the fact that a bug in path traversal or input sanitization is at least an order of magnitude easier to exploit and usually more dangerous than a double free. > If you tell a committed Christian that Jesus couldn’t have been born in 0AD because Herod died in 4BC and the census they were travelling for happened in 7AD as a non believer, that is the least problematic issue about Christianity. dates are conventions, we are not actually leaving in 2022, would you change your calendar because dating is completely made up? also: Jesus does not exists nor can do anything for you, C does.
- nindalf 4y ago
  Oh, is that so?
  - peoplefromibiza 4y ago
    yes.
- jeltz 4y ago
  As a C programmer I am baffled by your attitude. Do you feel so threatened by people creating new programming languages? Personally I love that people are working on projects like Zig which try to be a better C. Rust is also an interesting project which has had a lot of positive effects on programming and programming language design, but it is not a perfect replacement for C and more of a better C++. While some "innovation" actually make things worse I see a lot of interesting ideas coming from both Rust and Zig. > The author confess he's not a great Rust programmer yet, so probably using Rust over a language he knows better, just because Google said it, it's not the best of choices. He used Zig, not Rust.
  - peoplefromibiza 4y ago
    > Do you feel so threatened by people creating new programming languages? that's a lot of assumptions. I never even said I write C code. It feels to me that you are projecting your doubts on me to validate your choices. I have absolutely no problem at all with programming languages, in fact I always try all the new ones I can, I can actually write code, with very different degrees of competence, in more than 30 of them, including Rust, my new language of choice to write NIF extensions for Erlang/Elixir. Thanks to rustler crate which is awesome. > While some "innovation" actually make things worse I see a lot of interesting ideas coming from both Rust and Zig. Never said the opposite though. Just that a C Ruby extension is not the same thing of "writing a browser at Google in C++" > He used Zig, not Rust. I was referring to this sentence he wrote Other options were not great as well. I can use Rust, but I have never been on good terms with Rust
    - 4y ago
tmtvl 4y ago
Okay, next time I need to dive deep to get all the performance out of my machine I'll use the language you recommend which: A) Has a clear specification (none of that "the implementation is the specification" shenanigans). B) Is not manually memory managed (that's what we're trying to avoid by getting away from C). C) Is not garbage collected (that's what we're trying to avoid by writing C). D) Compiles to native code for if not all, at least most of the platforms that C supports. ...now I wonder which languages match that description, C++ with RAII and maybe SPARK?
- masklinn 4y ago
  > A) Has a clear specification (none of that "the implementation is the specification" shenanigans). !C > D) Compiles to native code for if not all, at least most of the platforms that C supports. C Good luck finding C & !C.
Touche 4y ago
I think few people think that C is "inherently good". Many of us still like C because it is inherently simple. That doesn't mean that it's good. It just means that we value simple and will take some (a lot!) of bad to keep the simple. When others try to pawn off complex languages like Rust as alternatives because they solve C problems, they are not really listening. From my perspective the pushback is really about 2 groups having diametrically opposite values. 1 values purity and perfection, 1 values simplicity. These two groups are never going to see eye to eye.
- still_grokking 4y ago
  C is not simple. Not even close. It's the single language still in use with at least one or two orders of magnitude more quirks than features. C is full of bobby traps. And nobody survived. Ever. It's impossible to build reliable software in C. Even people tried for 50 years. People died in RL not only once because of issues with the C language. I think no other language carries a real world death toll around. C may seem "easy" because it lacks features one would need to know. But easy is not simple! Usually quite the contrary. https://www.entropywins.wtf/blog/2017/01/02/simple-is-not-easy/ https://www.entropywins.wtf/blog/2017/01/02/simple-is-not-ea...
  - rudedogg 4y ago
    > People died in RL not only once because of issues with the C language. I think no other language carries a real world death toll around. Can you link me info about those bugs? I'm familiar with the radiation software bugs, but they don't appear to have been written in C.
    - still_grokking 4y ago
      The Therac-25 used a PDP-11 computer. So I assumed the software was written in C. It wasn't? I would also assume that most embedded software (e.g. in cars, spaceships, weapons, etc.) is written in C. But I see now it's indeed hard to come up with definitive sources. A few failures can be found here (and it's easy to google some more): https://embeddedartistry.com/fieldatlas/historical-software-accidents-and-errors/ https://embeddedartistry.com/fieldatlas/historical-software-... But sadly no reference to the used languages anywhere there. So I forward the question as I'm now also unsure: Has anybody definitive sources that prove the absence of C code in the known fatal accidents?

peoplefromibiza 4y ago

> Those who think C is inherently good can’t be convinced otherwise opposite is also true "those who think C is inherently not good [...]" > Any data backed study from Microsoft [1] or Google [2], [3] will be dismissed as Big Tech hiring mediocre programmers. They aren't being dismissed, but criticized when used to promote other languages. Those studies are partial and about a different topic. They are are about bugs in millions lines of code bloated products, written in C++. Not counting the actual implementation "bugs", like the browser X leaking details about users to make fingerprinting easier and then sell ads. You know why those companies are worried about memory safety and nothing else? Because it's the way people can circumvent the so called "features" and "protections" they implement. Here we are talking about Ruby extensions in C, which is a completely different domain, involving completely different tradeoffs. The author confess he's not a great Rust programmer yet, so probably using Rust over a language he knows better, just because Google said it, it's not the best of choices. Just think about the fact that the Ruby interpreter itself is written in C. Think about the fact that a bug in path traversal or input sanitization is at least an order of magnitude easier to exploit and usually more dangerous than a double free. > If you tell a committed Christian that Jesus couldn’t have been born in 0AD because Herod died in 4BC and the census they were travelling for happened in 7AD as a non believer, that is the least problematic issue about Christianity. dates are conventions, we are not actually leaving in 2022, would you change your calendar because dating is completely made up? also: Jesus does not exists nor can do anything for you, C does.

nindalf 4y ago
Oh, is that so?
- peoplefromibiza 4y ago
  yes.
jeltz 4y ago
As a C programmer I am baffled by your attitude. Do you feel so threatened by people creating new programming languages? Personally I love that people are working on projects like Zig which try to be a better C. Rust is also an interesting project which has had a lot of positive effects on programming and programming language design, but it is not a perfect replacement for C and more of a better C++. While some "innovation" actually make things worse I see a lot of interesting ideas coming from both Rust and Zig. > The author confess he's not a great Rust programmer yet, so probably using Rust over a language he knows better, just because Google said it, it's not the best of choices. He used Zig, not Rust.
- peoplefromibiza 4y ago
  > Do you feel so threatened by people creating new programming languages? that's a lot of assumptions. I never even said I write C code. It feels to me that you are projecting your doubts on me to validate your choices. I have absolutely no problem at all with programming languages, in fact I always try all the new ones I can, I can actually write code, with very different degrees of competence, in more than 30 of them, including Rust, my new language of choice to write NIF extensions for Erlang/Elixir. Thanks to rustler crate which is awesome. > While some "innovation" actually make things worse I see a lot of interesting ideas coming from both Rust and Zig. Never said the opposite though. Just that a C Ruby extension is not the same thing of "writing a browser at Google in C++" > He used Zig, not Rust. I was referring to this sentence he wrote Other options were not great as well. I can use Rust, but I have never been on good terms with Rust
  - 4y ago

tmtvl 4y ago

Okay, next time I need to dive deep to get all the performance out of my machine I'll use the language you recommend which: A) Has a clear specification (none of that "the implementation is the specification" shenanigans). B) Is not manually memory managed (that's what we're trying to avoid by getting away from C). C) Is not garbage collected (that's what we're trying to avoid by writing C). D) Compiles to native code for if not all, at least most of the platforms that C supports. ...now I wonder which languages match that description, C++ with RAII and maybe SPARK?

masklinn 4y ago
> A) Has a clear specification (none of that "the implementation is the specification" shenanigans). !C > D) Compiles to native code for if not all, at least most of the platforms that C supports. C Good luck finding C & !C.

Touche 4y ago

I think few people think that C is "inherently good". Many of us still like C because it is inherently simple. That doesn't mean that it's good. It just means that we value simple and will take some (a lot!) of bad to keep the simple. When others try to pawn off complex languages like Rust as alternatives because they solve C problems, they are not really listening. From my perspective the pushback is really about 2 groups having diametrically opposite values. 1 values purity and perfection, 1 values simplicity. These two groups are never going to see eye to eye.

still_grokking 4y ago
C is not simple. Not even close. It's the single language still in use with at least one or two orders of magnitude more quirks than features. C is full of bobby traps. And nobody survived. Ever. It's impossible to build reliable software in C. Even people tried for 50 years. People died in RL not only once because of issues with the C language. I think no other language carries a real world death toll around. C may seem "easy" because it lacks features one would need to know. But easy is not simple! Usually quite the contrary. https://www.entropywins.wtf/blog/2017/01/02/simple-is-not-easy/ https://www.entropywins.wtf/blog/2017/01/02/simple-is-not-ea...
- rudedogg 4y ago
  > People died in RL not only once because of issues with the C language. I think no other language carries a real world death toll around. Can you link me info about those bugs? I'm familiar with the radiation software bugs, but they don't appear to have been written in C.
  - still_grokking 4y ago
    The Therac-25 used a PDP-11 computer. So I assumed the software was written in C. It wasn't? I would also assume that most embedded software (e.g. in cars, spaceships, weapons, etc.) is written in C. But I see now it's indeed hard to come up with definitive sources. A few failures can be found here (and it's easy to google some more): https://embeddedartistry.com/fieldatlas/historical-software-accidents-and-errors/ https://embeddedartistry.com/fieldatlas/historical-software-... But sadly no reference to the used languages anywhere there. So I forward the question as I'm now also unsure: Has anybody definitive sources that prove the absence of C code in the known fatal accidents?