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

161–170 of 574 posts

Re: C Is Best (2025)

#161

Post by staticassertion »

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…

(2) and (3) just don't seem to be the case empirically. One bug that was directly in a grep'able `unsafe` block is hardly evidence of these, whereas Google's study on Rust has demonstrated (far more rigorously imo) the opposite. I think anyone paying attention would have guessed that the first Rust CVE would be a race - it is notoriously hard to get locking/ race semantics correct in the kernel, not even the C programmers get it right, it's an extremely common bug class and I believe Linus has basically said something along the lines of "no one understands it" (paraphrasing).

(4) Again, this doesn't seem to be borne out empirically.

(5) I've seen plenty of patches to C code that are way more than a single line for the Linux kernel, but sure, maybe we grant that a bug fix in Rust requires more LOC changed? It'd be nice to see evidence. Is the concern here that this will delay patching? That seems unlikely.

It's not uncommon at all for patches to the C code in the kernel for "make this generally safe" are 1000s of lines of code, seeding things like a "length" value through code, and take years to complete. I don't think it's fair to compare these sorts of "make the abstraction safe" vs "add a single line check" fixes.

(6) Also not borne out. Literally billions spent on this.

> So, is Rust an interesting language for certain features it has? Yes. Is Rust a silver bullet? No.

Agreed. I'm tempted to say that virtually no one contests the latter lol

> So should Rust be "pushed" to others, hell no, and I suggest you to reply in the most firm way to people stressing you out to adopt Rust at all the costs.

I guess? You can write whatever you want however you want, but users who are convinced that Rust code will provide a better product will ask for it, and you can provide your reasoning (as SQLite does here, very well imo) as firm as you'd please I think.

edit: And to this other comment (I'm rate limited): https://news.ycombinator.com/item?id=46513428

> made the current developers so able to reason about race conditions (also when they write Rust).

Aha. What? Where'd you get this from? Definitely not from Linus, who has repeatedly stated that lock issues are extremely hard to detect ahead of time.

> we’ve tweaked all the in-kernel locking over decades [..] and even people who know what they are doing tend to get it wrong several times

https://lwn.net/Articles/808498/

Definitely one of MANY quotes and Linus is not alone.

Re: C Is Best (2025)

#162

Post by lelanthran »

Drew_ wrote: post #109

> Safe languages usually want to abort if they encounter an out-of-memory (OOM) situation. SQLite is designed to recover gracefully from an OOM. As someone who runs into this problem a lot, this is pretty cool! Does anyone know how they can recover from this in SQLite?

> As someone who runs into this problem [OOM]a lot, this is pretty cool! Does anyone know how they can recover from this in SQLite?

How are you running into it?

If you're writing in C, idiomatic code works (check the return values of functions that allocate!)

If you're in C++, Rust or similar, you have to write pretty non-idiomatically to recover from an allocation failure.

Re: C Is Best (2025)

#163

Post by darkhorse13 »

MeetingsBrowser wrote: post #76
uecker wrote: post #73

I agree that C is best. I think Rust is actually a language with some severe downsides, despite having including some very good ideas and C having some real issues. But it will take a couple of years before one can discuss this rationally without being flamed at.

> Rust is actually a horrible language Can you expand a little?

They never said it's a horrible language.

Re: C Is Best (2025)

#164

Post by antirez »

erk__ wrote: post #160
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…

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.

If the kernel was completely written in Rust, we could have a lot of unsafe places, and many Rust CVEs. It is hard to tell, and the comparison in theory should be made after the kernel is developed only by people lacking the C experience that made the current developers so able to reason about race conditions (also when they write Rust).

Re: C Is Best (2025)

#165

Post by pclmulqdq »

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…

I hear "people rarely use unsafe rust" quite a lot, but every time I see a project or library with C-like performance, there's a _lot_ of unsafe code in there. Treating bugs in unsafe code as not being bugs in rust code is kind of silly, also.

Re: C Is Best (2025)

#166

Post by ashtonshears »

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…

Rust is pushed on the internet

Re: C Is Best (2025)

#167

Post by ViewTrick1002 »

koakuma-chan wrote: post #122
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…

I think this is bullshit. If you are running out of memory, you can, for example, choose to stop accepting more work ("backpressure"). I am always advocating for Rust, but this is one thing I really disagree on. I think Zig gets this right.

Now you need to ensure that your entire error path does not allocate or you have to deal with allocation errors in the error path as well.

Trying to apply backpressure from memory allocation failures which can appear anywhere completely disconnected from their source rather than capping the current in memory set seems like an incredibly hard path to make work reliably.

Re: C Is Best (2025)

#168

Post by antirez »

pclmulqdq wrote: post #165
tasn wrote: post #154

Earlier 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…

I hear "people rarely use unsafe rust" quite a lot, but every time I see a project or library with C-like performance, there's a _lot_ of unsafe code in there. Treating bugs in unsafe code as not being bugs in rust code is kind of silly, also.

Exactly. You don't need much unsafe if you use Rust to replace a Python project, for instance. If there is lower level code, high performances needs, things change.

Re: C Is Best (2025)

#169

Post by tialaramex »

pixelesque wrote: post #86
imglorp wrote: post #81

Earlier quoted context omitted.

That seems like an enormous question. Is anyone working on it?

There's experimental/nightly support for things like: `push_within_capacity()` which is a more manual way (user-space code would have to handle the return code and then increase the capacity manually if required) of trying to handle that situation.

And of course the kernel - which doesn't even use Rust's Vec but has its own entire allocator library because it is the kernel - likewise provides

https://rust.docs.kernel.org/next/kernel/alloc/kvec/struct.V...

Vec::push_within_capacity is a nice API to confront the reality of running out of memory. "Clever" ideas that don't actually work are obviously ineffective once we see this API. We need to do something with this T, we can't just say "Somebody else should ensure I have room to store it" because it's too late now. Here's your T back, there was no more space.

Re: C Is Best (2025)

#170

Post by ruszki »

Supernaut wrote: post #137
baq wrote: post #108

Earlier quoted context omitted.

I mostly agree, but the OOP is most definitely not in vogue on HN for the past decade at least, arguably far longer than that (think Rust pre-1.0, Go 1.0 times).

Absolutely. Our thought leaders have been pushing functional programming for a long time now.

Is it possible to have an OOP language which is also functional? Or is it impossible without imperative paradigms?
Post reply on HN