Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C Is Best (2025)

sqlite.org

Post reply on HN
Print view View original

151–160 of 574 posts

Re: C Is Best (2025)

#151

Post by Koshkin »

gwbas1c wrote: post #110
nu11ptr wrote: post #51

I am a pretty serious "Rustacean", but I like to think "for the right reasons". A rewrite in Rust of the main project would make very little sense, unless there is some objective the project wants that can't be met with C (see below). This person presents a well thought out case on why it makes little sense to rewrite, especially in the final section. Rust is great for many things, but when you have something old tha…

Honestly, instead of porting SQLite to Rust, IMO, it makes more sense to make an easier-to-use embedded database (in Rust) first.

Is SQLite hard to use?

Re: C Is Best (2025)

#152

Post by lelanthran »

kibwen wrote: post #87
nialv7 wrote: post #67

Earlier quoted context omitted.

well, as an example, Vec::push doesn't have a way to report allocation failure. it will just panic, which is not acceptable in the kernel.

Sure, which is a perfectly acceptable default considering that most code is not in a position to observe allocation failures (because of OS-level overcommit, which is nearly always a good thing), and furthermore most code is not in a position to do anything other than crash in an OOM scenario. If you still want to have control over this without going full no_std, Rust has Vec::try_reserve to grow a Vec while checking…

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

Re: C Is Best (2025)

#153

Post by irishcoffee »

monocasa wrote: post #135
irishcoffee wrote: post #126

Earlier quoted context omitted.

> The US government recently called on everyone to stop using them and move to memory-safe languages. The US government also _really_ (no sarcasm) cares about safety-critical code that can be formally verified, depending on program requirements. DO-178, LOR1, el. al. Developing those toolchains costs tens of millions, getting them certified costs tens of millions, and then buying those products to use costs 500k-1.5m…

https://blog.pictor.us/rust-is-do-178-certifiable/

> While Rust isn’t “certified” out of the box, it provides attributes that facilitate certification. By design, Rust restricts certain low-level operations and enforces strict memory safety rules, effectively shifting much of the error-checking and verification into compile-time. This means that issues that might otherwise be found by multiple external tools in C/C++ are caught early during the Rust build process.

I think your link agrees with me, actually.

Re: C Is Best (2025)

#154

Post by tasn »

antirez wrote: post #130
baranul wrote: post #34

Every project and programmer shouldn't feel they have to justify their choice not to use Rust (or Zig), who seem to be strangely and disproportionately pushed on Hacker News and specific other social media platforms. This includes the pressure, though a bit less in recent years, to use OOP. If they are getting good results with C and without OOP, and people like the product, then those from outside the project should…

It is also worth to note that the Rust design, in its theory, and the recent bug in the Linux kernel Rust code (the message passing abstraction used by Android), makes clear that: 1. With Rust, you may lower the exposure, but the same classes of bug still remain. And of course, all the other non memory related bugs. 2. With C you may, if you wish, develop a big sensibility to race conditions, and stay alert. In gener…

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 projects suffer from these classes of bugs consistently. Additionally, that's why people use linters and code formatters even though developers can develop a sensitivity to coding conventions (in fact, these tools used to be unpopular in C-land). Trusting humans develop sensibility is just not enough.

Specifically, about the concurrency: Redis is (mostly) single-threaded, and I guess that's at least in part because of the difficulty of building safe, fast and highly-concurrent C applications (please correct me if I'm wrong).

Can people write safer C (e.g. by using sds.c and the likes)? For sure! Though we've been writing C for 50+ years at this point, at some point "people can just do X" is no longer a valid argument. As while we could, in fact we don't.

Re: C Is Best (2025)

#155

Post by gpm »

lelanthran wrote: post #152
kibwen wrote: post #87

Earlier quoted context omitted.

Sure, which is a perfectly acceptable default considering that most code is not in a position to observe allocation failures (because of OS-level overcommit, which is nearly always a good thing), and furthermore most code is not in a position to do anything other than crash in an OOM scenario. If you still want to have control over this without going full no_std, Rust has Vec::try_reserve to grow a Vec while checking…

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

Re: C Is Best (2025)

#156

Post by usefulcat »

muvlon wrote: post #66
jll29 wrote: post #53

Earlier quoted context omitted.

> Rust's philosophy, which is to find the best solution to the problems it's trying to solve, at any cost, including breaking compatibility, at least to some degree. But the Rust team found a great way to avoid breaking backward compatibility: old code gets automatically compiled by the old version of the compiler, whereas more recent code is treated with the latest version of the compiler. That is much better IMHO t…

> old code gets automatically compiled by the old version of the compile That's not what happens. You always use the same version of the compiler. It's just that the newer compiler version also knows several older dialects (known as editions) of the language.

And it remains to be seen how well this approach will work as time passes and the number of versions continues to increase.

Re: C Is Best (2025)

#157

Post by hu3 »

anthonypasq wrote: post #141
hu3 wrote: post #100

Earlier quoted context omitted.

Bad analogy. If the alternative has drawbacks (they always do) or is not as well known by the team, it's perfecly fine to keep using the tool you know if it is working for you. People who incessantly try to evangelise their tool/belief/preferences to others are often seen as unpleasant to say the least and they often achieve the opposite effect of what they seek.

of course there are drawbacks to power tools. you could run out of battery for example and now its useless. but everyone with a brain knows the costs are worth the benefits.

I was talking in general if that escaped you. Hence "beliefs/preferences" and not only tools.

And when it comes to programming languages, it's not as clear cut. As exemplified by the article.

So the power tools is a poor analogy.

Re: C Is Best (2025)

#158

Post by antirez »

tasn wrote: post #154
antirez wrote: post #130

Earlier quoted context omitted.

It is also worth to note that the Rust design, in its theory, and the recent bug in the Linux kernel Rust code (the message passing abstraction used by Android), makes clear that: 1. With Rust, you may lower the exposure, but the same classes of bug still remain. And of course, all the other non memory related bugs. 2. With C you may, if you wish, develop a big sensibility to race conditions, and stay alert. In gener…

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

Re: C Is Best (2025)

#159

Post by donkeybeer »

misnome wrote: post #59
baranul wrote: post #34

Every project and programmer shouldn't feel they have to justify their choice not to use Rust (or Zig), who seem to be strangely and disproportionately pushed on Hacker News and specific other social media platforms. This includes the pressure, though a bit less in recent years, to use OOP. If they are getting good results with C and without OOP, and people like the product, then those from outside the project should…

> strangely and disproportionately pushed on Hacker News There is literally nothing strange or disproportionate. It's incredibly obvious that new languages, that were designed by people who found older languages lacking, are of interest to groups of people interested in new applications of technology and who want to use their new languages. > then those from outside the project shouldn't really have any say on it. It…

I think it's more than just the normal amount for advocacy of a new language. Rust isn't the only "newer" language. I don't feel this kind of mentally strung pushing of say Kotlin or Scala or Go or, etc from their fans.

Re: C Is Best (2025)

#160

Post by erk__ »

antirez wrote: post #130
baranul wrote: post #34

Every project and programmer shouldn't feel they have to justify their choice not to use Rust (or Zig), who seem to be strangely and disproportionately pushed on Hacker News and specific other social media platforms. This includes the pressure, though a bit less in recent years, to use OOP. If they are getting good results with C and without OOP, and people like the product, then those from outside the project should…

It is also worth to note that the Rust design, in its theory, and the recent bug in the Linux kernel Rust code (the message passing abstraction used by Android), makes clear that: 1. With Rust, you may lower the exposure, but the same classes of bug still remain. And of course, all the other non memory related bugs. 2. With C you may, if you wish, develop a big sensibility to race conditions, and stay alert. In gener…

A quick unscientific count on cve.org counts ~86 race condition CVEs in the Linux kernel last year, so you might be overstating how well bug antennas work.
Post reply on HN