But sticking with C is exactly what we don't want... hence entertaining alternatives. Right?
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-appro...
2 - https://www.chromium.org/Home/chromium-security/memory-safet...
3 - https://security.googleblog.com/2022/12/memory-safe-language...
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.
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.
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
True. It's, if anything, worse: the users of the extension might not even know it's native, will definitely assume it's fully safe, and will absolutely feed it attacker-controlled data without a thought. And the extension author won't have the engineering review and tooling that a Google has in place either.
Ruby extensions in C (or any other language) are mostly - 100% of the time for non-trivial stuff - a thin layer wrapping a native library.
The attack surface is minimal and it's almost entirely in the realm of the library code, which usually the extension developer has no control over.
it is also much easier to sandbox a ruby process in a server than Chrome on the user's computer.
> the engineering review and tooling that a Google has in place either
hardly, I would argue that something that is hundreds of thousand times smaller in scope and number of lines of code is much easier to write, review, test and debug.
Chrome seats at 7 million LoC, the average Ruby extension is ~100 LoC.
The fact that writing a wrapper is trivial compared to writing a browser, also helps a lot.
Many people can write a bug free correct wrapper in any language using only their brain.
No one can write Google Chrome on their own, let alone a bug free correct implementation of it.
Premature optimization is the root of all evil.
“Omnia venenum sunt: nec sine veneno quicquam existit. Dosis sola facit, ut venenum non fit.”
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?
!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.
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.
That's one thing that has made Zig more attractive as an alternative for (a lot of) C developers, it stays close enough with only small abstractions.
D: foreach (i; 0 .. 10) { body }
C: for (int i = 0; i < 10; ++i); { body }
Which one is more better? I can speak from experience that the former is much better, much easier to read, and has fewer bugs.
C doesn't allow forward referencing. What this means in practice as people lay out the code in a source file backwards, i.e. the leaf functions come first and the top level functions come last.
This is just not the ergonomic way to write code. The public functions should be first and the private leaf functions last. The code should read top to bottom.
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-ea...
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.
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-...
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?