Hacker News Reader

Comment by habibur | Hacker News Reader

> Fortunately, a few weeks ago an issue I’ve been tracking for about 3 years was resolved. Zig now can export functions with variable arguments.

The key part. It wasn't possible to write Ruby extensions in Zig until a few weeks back. Now you can.

> I have a story of rewriting part of our production code as Rust extension, which turned out to be 3-4 times faster, but we ditched it anyway, because maintenance cost would be too high.

My solution to this problem is to stick with C. Your code won't get obsolete. Most people are still using C99, and not much has changed in 20 years, even in recent versions.

View on HN

But sticking with C is exactly what we don't want... hence entertaining alternatives. Right?

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-appro...

2 - https://www.chromium.org/Home/chromium-security/memory-safet...

3 - https://security.googleblog.com/2022/12/memory-safe-language...

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.

Modern C is full of various extensions. This makes it a fair bit more complicated than it appears. C is also missing key simplicity features - like modules and forward referencing.

Those kinds of features are wonderful and all and they don't add much complexity to having them in your language. The thing that makes languages more or less simple (and more or less complex) is the number and degree of abstractions they have. C has relatively few abstractions, which means you can spend more time thinking about what you're building. Most of the C replacements have more abstractions, which means you spend a lot of time thinking about the code itself (am I using the right abstraction here?) and less time thinking about the thing you're building.

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.

I find the opposite is true. Having better abstractions makes the code easier to think about, and hence it's more productive. For example,

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.

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-ea...

> 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.

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-...

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?

> 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.

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.

> 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

> Just that a C Ruby extension is not the same thing of "writing a browser at Google in C++"

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.

> True. It's, if anything, worse:

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.”

Oh, is that so?

yes.

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?

> A) Has a clear specification (none of that "the implementation is the specification" shenanigans).

> D) Compiles to native code for if not all, at least most of the platforms that C supports.

Good luck finding C & !C.

But I don't like C. I like modern systems languages.

C was already dated when compared with languages like Modula-2 from 1978, modern system languages are kind of catching up with how the world used to look like outside Bell Labs walls.

Reply on news.ycombinator.com