What the post says is that you can do software engineering in C and be portable.
C Is Best (2025)
171–180 of 574 posts
Re: C Is Best (2025)
#172Re: C Is Best (2025)
#173Earlier quoted context omitted.
> most code is not in a position to do anything other than crash in an OOM scenario. That's intentional; IOW the "most code" that is unable to handle OOM conditions are written that way. You can write code that handles OOM conditions gracefully, but that way of writing code is the default only in C. In every other language you need to go off the beaten path to gracefully handle OOM conditions.
Handling OOM gracefully - i.e. doing anything other than immediately crashing and/or invoking undefined behaviour - is absolutely not the default in C. It's possible. But very very few projects do.
> Handling OOM gracefully - i.e. doing anything other than immediately crashing and/or invoking undefined behaviour - is absolutely not the default in C.
What are you talking about? Every allocation must be checked at the point of allocation, which is "the default"
If you write non-idiomatically, then sure, in other languages you can jump through a couple of hoops and check every allocation, but that's not the default.
The default in C is to return an error when allocation fails.
The default in C++, Rust, etc is to throw an exception. The idiomatic way in C++, etc is to not handle that exception.
Re: C Is Best (2025)
#174Earlier quoted context omitted.
Zig hasn't even had it's first release yet. And projects written in it still break in new releases. Given their stance on boringness and maturity it would make no sense for Sqlite to consider zig yet.
SQLite is never gonna be rewritten by its creators in another language. That is highly doubtful considering the age of SQLite and the roadmap for support I think until 2060 or mid 2050s based on what I’ve read.
[deleted]
Re: C Is Best (2025)
#175Re: C Is Best (2025)
#176As an outsider when I read about Rust it seems like it is positioning itself as the language to rewrite things that already work.
It's just the simplistic first feeling of a language, in the same way I feel like Go is the language for Kubernetes/cloud/net servers, Ruby is for Rails, JS is the browser/bootcamp language, Python is Data Science and AI...
Sure, you get that safety but you are also throwing the stability that an old (and maintained) codebase has just for the sake of being patched to handle the presssure from the real world.
Maybe it's time Rust positions itself as something more than "the language of rewrites".
Re: C Is Best (2025)
#177WRONG! Plain and simple C is, by far, one of the current _LESS WORSE_ performant alternatives which can be used, actually, from low level to large applications. C syntax is already waaaaay to rich and complex (and ISO is a bit too much pushing feature creep over 5/10 years cycles).
That's the first time I've heard the C syntax being called "too rich". It's the epitome of succinctness IMHO (too a fault, even, or maybe I'm just old). Are you confusing it with C++? If so, you have a point.
C's syntax is pretty lacking by modern standards, requiring gross things like The Lexer Hack to resolve ambiguities that other languages just don't suffer from: https://en.wikipedia.org/wiki/Lexer_hack . To say nothing of the madness that is C's type declaration syntax, necessitating tools like https://cdecl.org/ and "the spiral rule" for reading type declarations (which doesn't actually produce the correct result anyway).
Re: C Is Best (2025)
#178Earlier quoted context omitted.
> most code is not in a position to do anything other than crash in an OOM scenario. That's intentional; IOW the "most code" that is unable to handle OOM conditions are written that way. You can write code that handles OOM conditions gracefully, but that way of writing code is the default only in C. In every other language you need to go off the beaten path to gracefully handle OOM conditions.
Handling OOM gracefully - i.e. doing anything other than immediately crashing and/or invoking undefined behaviour - is absolutely not the default in C. It's possible. But very very few projects do.
I know one C++ library that caches data but never evicts. Instead, the library author expects you to restart your app every 24 hours.
Re: C Is Best (2025)
#179Re: C Is Best (2025)
#180Earlier quoted context omitted.
The recent bug in the Linux kernel Rust code, based on my understanding, was in unsafe code, and related to interop with C. So I wouldn't really classify it as a Rust bug. In fact, under normal circumstances (no interop), people rarely use unsafe in Rust, and the use is very isolated. I think the idea of developers developing a "bugs antenna" is good in theory, though in practice the kernel, Redis, and many other pro…
In Rust you can avoid "unsafe" when you use Rust like it was Go or Python. If you write low level code, that is where C is in theory replaceable only by Rust (and not by Go), then you find yourself in need of writing many unsafe sections. And to lower the amount of unsafe sections, you have to build unnatural abstractions, often, in order to group such unsafe sections into common patterns. Is is a tradeoff, not a sil…
I think this framing is a bit backwards. Many C programs (and many parts of C programs) would benefit from being more like Go or Python as evident by your very own sds.c.
Now, if what you're saying is that with super highly optimized sections of a codebase, or extremely specific circumstances (some kernel drivers) you'd need a bit of unsafe rust: then sure. Though all of a sudden you flipped the script, and the unsafe becomes the exception, not the rule; and you can keep those pieces of code contained. Similarly to how C programmers use inline assembly in some scenarios.
Funny enough, this is similar to something that Rust did the opposite of C, and is much better for it: immutable by default (let mut vs. const in C) and non-nullable by default (and even being able to define something as non-null). Flipping the script so that GOOD is default and BAD is rare was a huge win.
I definitely don't think Rust is a silver bullet, though I'd definitely say it's at least a silver alloy bullet. At least when it comes to the above topics.