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

191–200 of 574 posts

Re: C Is Best (2025)

#191

Post by rascul »

Koshkin wrote: post #144
titzer wrote: post #125

Earlier quoted context omitted.

C was my first language, more than thirty years ago. I've heard (and probably myself made) the same arguments over and over and over. But those arguments are lame and wrong. C cannot be made safe (at scale). It's like asbestos. In fact, C is a hazardous material in exactly the same way as asbestos. Naturally occurring, but over industrialized and deployed far too widely before its dangers were known. Still has its us…

> in exactly the same way C is not known to the state of California to cause cancer.

Not yet

Re: C Is Best (2025)

#192

Post by kibwen »

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.

> That's intentional; IOW the "most code" that is unable to handle OOM conditions are written that way.

No, this is wishful thinking. While plenty of programs out the are in the business of maintaining caches that could be optimistically evicted in order to proceed in low-memory situations, the vast majority of programs are not caching anything. If they're out of memory, they just can't proceed.

Re: C Is Best (2025)

#193

Post by blub »

staticassertion wrote: post #161
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…

(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 progra…

Google have published a couple high-level Rust blog posts with many graphs and claims, but no raw data or proofs, so they haven’t demonstrated anything.

By now their claims keep popping up in Rust discussion threads without any critical evaluation, so this whole communication is better understood as a marketing effort and not a technical analysis.

Re: C Is Best (2025)

#194

Post by halfmatthalfcat »

donkeybeer wrote: post #159
misnome wrote: post #59

Earlier quoted context omitted.

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

Can I start then with Scala - it's my favorite language and easily has the best of both OO and functional worlds with insanely useful libraries to express code ergonomically. EVERYBODY SHOULD USE IT!

Re: C Is Best (2025)

#195

Post by AnimalMuppet »

jll29 wrote: post #53
publicdebates wrote: post #37

> Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring. One of the very strange things about C is that it is designed by a committee that is inherently conservative and prefers to not add new features, especially if they have any chance of breaking any compatibility. This seems necessary before Rust ever becomes an old, boring language. But I don't see Rust ever goin…

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

This may have its own landmines. Worst case, old code getting compiled in the old way could mean that the exact same line means different things depending on which file it's in. (I don't know whether it is possible with how Rust does this.)

Re: C Is Best (2025)

#196

Post by antirez »

kibwen wrote: post #184
antirez wrote: post #168

Earlier quoted context omitted.

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.

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. The fact that the percentage is higher in the latter case doesn't change the fact that 95% of your codebase is just as safe as the Python project would be.

A big amount of C code does not do anything unsafe as well, it calls other stuff, do loops, logic business, and so forth. It is also wrong to believe 100% of the C code is basically unsafe.

Re: C Is Best (2025)

#197

Post by bigfishrunning »

ruszki wrote: post #170
Supernaut wrote: post #137

Earlier quoted context omitted.

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?

There's some muddiness in the terminology here -- OOP is really a design style, and "OOP languages" are generally imperative languages that have sematics that encourage OOP design. It is very possible, even encouraged, to represent state as "Objects" in many functional languages; it's just not really enforced by the language itself.

A good example of this are the object systems in Scheme and Common Lisp (which are less strictly Functional (note the capital F in that word) then something like Haskell).

Re: C Is Best (2025)

#198

Post by emorning4 »

I can't imagine how writing C directly could possibly be better than using a language like Dafny and then generating C code.

Edit: Dafny: A verification language capable of enforcing invariants

Re: C Is Best (2025)

#199

Post by elcritch »

enricozb wrote: post #10

The final comments in this text seem sobering and indicate an openness to change. I worked recently on a project to migrate RediSearch to Rust, and this was partially motivated by a decent number of recent CVEs. If SQLite doesn't have this problem, then there needs to be some other strong argument for moving to Rust. I also think it's important to have really solid understandings (which can take a few decades I imagi…

Something like Ada/SPARK might be a better choice for something like SQLite as well.

Re: C Is Best (2025)

#200

Post by joosters »

lelanthran wrote: post #173
gpm wrote: post #155

Earlier quoted context omitted.

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

From the parent comment:

because of OS-level overcommit, which is nearly always a good thing

It doesn't matter about the language you are writing in, because your OS can tell you that the allocation succeeded, but when you come to use it, only then do you find out that the memory isn't there.

Post reply on HN