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

371–380 of 574 posts

Re: C Is Best (2025)

#371

Post by staticassertion »

broken-kebab wrote: post #275
staticassertion wrote: post #210

Earlier quoted context omitted.

You're swapping definitions of unsafe. Earlier you were referring to the `unsafe` keyword. Now you're using `unsafe` to refer to a property of code. This makes it easy to say things like "It is also wrong to believe 100% of the C code is basically unsafe" but you're just swapping definitions partway through the conversation.

What I see is that antirez claims that absence of "safe" (as syntax) in C lang doesn't automatically mean that all of C code is unsafe (as property). There's no swapping of definitions as I see it.

I think there's a very clear switch of usage happening. Maybe it's hard to see so I'll try to point out exactly where it happens and how you can spot it.

First from antirez:

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

Use of the term `unsafe` here referring to the keyword / "blocks" of code. Note that this statement would be nonsensical if talking about `unsafe` as a property of code, certainly it would be inconsistent with the later unsafe since later it's claimed that C code is not inherently "unsafe" (therefor Rust would not be inherently "unsafe").

Kibwen staying on that definition here:

> For replacing a Python project with Rust, unsafe blocks will comprise 0% of your code. For replacing a C project with Rust, unsafe blocks will comprise about 5% of your code.

Here is the switch:

> A big amount of C code does not do anything unsafe as well

Complete shift to "unsafe" as being a property of code, no longer talking about the keyword or about blocks of code. You can spot it by just rewriting the sentences to use Rust instead of C.

You can say:

"A big amount of 'unsafe' Rust code does not do anything unsafe as well" "It is also wrong to believe 100% of the unsafe Rust code is basically unsafe."

I think that makes this conflation of terms clear, because we're now talking about the properties of the code within an "unsafe" block or globally in C. Note how clear it is in these sentences that the term `unsafe` is being swapped, we can see this by referring to "rust in unsafe blocks" explicitly.

This is just a change of definitions partway through the conversation.

p.s. @Dang can you remove my rate limit? It's been years, I'm a good boy now :)

Re: C Is Best (2025)

#372

Post by gwbas1c »

Koshkin wrote: post #151
gwbas1c wrote: post #110

Earlier quoted context omitted.

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?

Oh, SQLite (as a database) is easy compared to a client-server database, or an "embedded" database that runs in a separate process.

The issue is more of the object-relational impedance mismatch that happens when using any SQL database: ORMs can be slow / bloated, and hand-written SQL is time consuming.

I shipped a product on SQLite, and SQLite certainly lived up to its promise. What would have been more helpful was if it could index structured objects instead of rows, and serialize / deserialize the whole object. People are doing this now by putting JSON into SQLite. (Our competitors did it when I looked into their SQLite database.)

Re: C Is Best (2025)

#373

Post by threethirtytwo »

goku12 wrote: post #369
threethirtytwo wrote: post #278

Earlier quoted context omitted.

Is there still pressure to use OOP? On Hacker News, at least, the trend seems to be moving in the opposite direction. There’s growing skepticism toward OOP, and that’s reflected in the popularity of languages like Rust and Zig, which are explicitly designed to push against traditional object-oriented patterns. That’s not to say OOP advocacy has disappeared from HN. It still exists, but it no longer feels dominant or…

> There’s growing skepticism toward OOP, and that’s reflected in the popularity of languages like Rust and Zig, which are explicitly designed to push against traditional object-oriented patterns. I don't know about Zig, but my experience with Rust's trait system is that it isn't explicitly against OOP. Traits and generics feel like an extension and generalization of the OOP principles. With OOP, you have classes (typ…

> I don't know about Zig, but my experience with Rust's trait system is that it isn't explicitly against OOP. Traits and generics feel like an extension and generalization of the OOP principles. With OOP, you have classes (types) and/or objects (instances) and bunch of methods specific to the class/object. In Rust, you extend that concept to almost all types including structs and enums.

That’s not oop. Traits and generics are orthogonal to oop. It’s because oop is likely where you learned these concepts so you think the inception of these things is derived from oop.

What’s unique to oop is inheritance and encapsulation.

Design patterns isn’t unique to OOP either but there’s a strong cultural association with it. The term often involves strictly using encapsulated objects as the fundamental building block for each “pattern”.

The origin of the term “design patterns” was in fact established in context of OOP through the famous book and is often used exclusively to refer to OOP but the definition of the term itself is more broad.

Re: C Is Best (2025)

#374

Post by josephg »

lock1 wrote: post #254
burntsushi wrote: post #204

Earlier quoted context omitted.

> With C you may, if you wish, develop a big sensibility to race conditions, and stay alert. In general it is possible that C programmers have their "bugs antenna" a bit more developed than other folks. I suppose it's possible. I wonder if I'll become a better driver if I take off my seatbelt. Or even better, if I take my son out of my car seat and just let him roam free in the back seat. I'm sure my wife will buy th…

FWIW, FAFO is a very good way to learn. Assuming we can respawn indefinitely and preserve knowledge between respawns, driving fast and taking off your seatbelt would definitely teach you more than just reading a book. But in this specific case, if the respawn feature is not available or dying isn't a desirable event, FAFO might not be the best way to learn how to drive.

I also think we have the data in for memory safety in C. Even the best people, with the best processes in the world seem to keep writing memory safety bugs. The “just be more vigilant” plan doesn’t seem to work.

Re: C Is Best (2025)

#375

Post by atherton94027 »

erk__ wrote: post #366
atherton94027 wrote: post #224

Earlier quoted context omitted.

But you need to control for lines of code at the very least — otherwise you're comparing apples to oranges

Then it would not be unscientific.

Yeah I mean I could also say "there are no CVEs written in PERL in the kernel ergo PERL is safer to write than Rust". Given there's close to zero .pl files in the kernel, I think we can all agree my assertion holds

Re: C Is Best (2025)

#376

Post by staticassertion »

lock1 wrote: post #254
burntsushi wrote: post #204

Earlier quoted context omitted.

> With C you may, if you wish, develop a big sensibility to race conditions, and stay alert. In general it is possible that C programmers have their "bugs antenna" a bit more developed than other folks. I suppose it's possible. I wonder if I'll become a better driver if I take off my seatbelt. Or even better, if I take my son out of my car seat and just let him roam free in the back seat. I'm sure my wife will buy th…

FWIW, FAFO is a very good way to learn. Assuming we can respawn indefinitely and preserve knowledge between respawns, driving fast and taking off your seatbelt would definitely teach you more than just reading a book. But in this specific case, if the respawn feature is not available or dying isn't a desirable event, FAFO might not be the best way to learn how to drive.

> FWIW, FAFO is a very good way to learn. Assuming we can respawn indefinitely and preserve knowledge between respawns, driving fast and taking off your seatbelt would definitely teach you more than just reading a book.

Yes, just sucks for the person who you hit with your car, or the person whose laptop gets owned because of your code.

"FAFO" is not a great method of learning when the cost is externalized.

Re: C Is Best (2025)

#377

Post by goku12 »

phlakaton wrote: post #293
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…

This seems like the way. Why would Rustaceans bother to "argue their case" before an unwilling board if they can just do the rewrite themselves? Maybe it will succeed, maybe not, but you don't need SQLLite's blessing to test the proposition.

My hunch is that those aren't very serious Rustaceans. Even the original language developers developed Rust to interoperate with C as much as possible, and they often used to discourage the rewrite evangelism. If you are a serious Rustacean, you'd probably be worried about the safety tradeoffs in rewriting in Rust. As your parent commenter points out, a mature C codebase is already tested so well that rewriting it in Rust is likely to introduce more bugs - non-memory-safety bugs that are nevertheless serious enough. That's why I and many other Rustaceans don't recommend it. In fact, some Rustaceans even advise others to not rewrite Fortran 90 code (in order to preserve the performance advantage) and instead recommend integrating it with Rust using FFI.

Re: C Is Best (2025)

#378

Post by bluecalm »

tialaramex wrote: post #243

> But no other language claims to be faster than C for general-purpose programming, because none are. The "faster than C for general-purpose programming" is a pretty woolly claim so I'm not entirely surprised nobody claims that, but equally I think to be sure that "because none are" would need some serious caveats to make it true. In particular you're going to have to say you think it doesn't matter how much develope…

>>A project where C programmers spend five hours to make it run in 4 seconds is in this caveat "20% faster" than a project where Alt Lang programmers spend five minutes to make it run in 5 seconds - because only those seconds count. This is not how the real world works so it's a pretty nasty caveat.

For any project with non-trivial amount of users the C programmer did better. I mean I know companies like to save money and move the costs (time, electricity, hardware costs) to customers but if you care about users any non-trivial speed improvement is worth a lot in aggregate, surely more than your time implementing it.

Re: C Is Best (2025)

#379

Post by TZubiri »

onetoo wrote: post #282
TZubiri wrote: post #250

Earlier quoted context omitted.

Sounds like textbook bc break. I'm curious as to what you think a bc break would look like? Consider python2 and python3, you don't need to update your python2 code really, you can just use the python2 interpreter.

The equivalent in python-metaphor-land would be that python files clearly designate whether they are py2 or py3, and a single python interpreter can run both py2 and py3 scripts, as well as cross-include files of each version without issue. Rust editions only (and rarely!) break your code when you decide to upgrade your project's edition. Your public API stays the same as well (IIRC), so upgrading edition doesn't bre…

Hmm, couple of questions.

what would be the difference with a binary that's has both a py2 and py3 interpreter and a flag --edition=2 or =3 redirects to either file?

If I have Rust code from 2021, can I add a feature from 2024 and run it with --edition=2021 or 2024? Wouldn't adding a 2024 feature then possibly break the 2021 code?

I think the fact that rust is compiled has a big impact in terms of bc for dependencies. py2 must use py2 dependencies, but rust24 could use rust21 binaries as long as there were no API bc breaks, the code itself is already compiled away.

Re: C Is Best (2025)

#380

Post by oconnor663 »

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…

> With C you may, if you wish, develop a big sensibility to race conditions, and stay alert. In general it is possible that C programmers have their "bugs antenna" a bit more developed than other folks.

I think there are effects in both directions here. In C you get burned, and the pain is memorable. In Rust you get forced into safe patterns immediately. I could believe that someone who has done only Rust might be missing that "healthy paranoia". But for teaching in general, it's hard to beat frequent and immediate feedback. Anecdotally it's common for experienced C programmers to learn about some of the rules only late in their careers, maybe because they didn't happen to get burned by a particular rule earlier.

> Rust may create a false sense of security, and in the unsafe sections the programmer sometimes, when reviewing the code, is falsely convinced by the mandatory SAFETY comment.

This is an interesting contrast to the previous case. If you write a lot of unsafe Rust, you will eventually get burned. If you're lucky, it'll be a Miri failure. I think this makes folks who work with unsafe Rust extremely paranoid. It's also easier to sustain an that level of paranoia with Rust, because you hopefully only have to consider small bits of unsafe code in isolation, and not thousands of lines of application logic manipulating raw pointers or whatever.

Post reply on HN