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

241–250 of 574 posts

Re: C Is Best (2025)

#241

Post by signa11 »

shakna wrote: post #74
jll29 wrote: post #46

BTW, the study referred to in 1.2, which claims that SQLite was faster than the file system is not supported by the numbers in the study referenced: https://github.com/chrisdavies/dbench

> For a my real(ish) world scenario, SQLite-- once warmed up-- is roughly twice as fast as the file system.

is that actually surprising ?

once data leaves the fs and is all (or in part) bought into a processes memory, access is just limited by the memory bandwidth.

ofcourse if you start touching uncached data things slow down, but just for a short while…

Re: C Is Best (2025)

#242

Post by IvanK_net »

Many non-programmers think that programming languages get outdated, just like operating systems or computer hardware, or even some software (old algorithms replaced by better algorithms), and each programmer should "follow trends", since using the same programming language for 10+ years sounds wrong.

But programming languages are like Math. It is like saying "multiplying is outdated" or "the square root is outdated".

Re: C Is Best (2025)

#243

Post by tialaramex »

> 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 developer time is needed. 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.

Re: C Is Best (2025)

#244

Post by TZubiri »

samiv wrote: post #203
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…

Talking as a long time C++ programmer. I really don't get this mind set. First off allocation failure (typically indicated by bad_alloc exception in C++ code, or nullptr in C style code) does not mean that the system (or even the process) as a whole is out of memory. It just means that this particular allocator could not satisfy the allocation request. The allocator could have "ulimit" or such limit that is completel…

>does not mean that the system is out of memory. >"The allocator could have "ulimit" or such limit that is completely independent from actual process/system limitations."

Are we playing word games here? If a process has a set amount of memory, and it's out of it, then that process is OOM, if a VM is out of memory, it's OOM. Yes, OOM is typically used for OS OOM, and Linus is talking about rust in the kernel, so that's what OOM would mean.

>Secondarily what reason is there to make an allocation failure any different than any other resource allocation failure.

Of course there is, would you treat being out of bread similar to being out of oxygen? Again this can be explained by the context being kernel development and not application development.

Re: C Is Best (2025)

#245

Post by sigzero »

kibwen wrote: post #182
andrepd wrote: post #112

Earlier quoted context omitted.

I'm very much into Rust but this article is precisely about the fact that Rust is not "better in every way"...

This article was written nine years ago, when Rust 1.0 was two years old, by an author who spent a small (but nonzero) amount of time evaluating Rust.

This page was last updated on 2025-05-09 15:56:17Z

Re: C Is Best (2025)

#246

Post by vips7L »

halfmatthalfcat wrote: post #194
donkeybeer wrote: post #159

Earlier quoted context omitted.

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!

Nah it’s too complex, has shipped too many breaking changes, and the community sucks.

Re: C Is Best (2025)

#248

Post by halfmatthalfcat »

vips7L wrote: post #246
halfmatthalfcat wrote: post #194

Earlier quoted context omitted.

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!

Nah it’s too complex, has shipped too many breaking changes, and the community sucks.

Always gotta get my yum yucked.

Re: C Is Best (2025)

#249

Post by knowitnone3 »

IvanK_net wrote: post #242

Many non-programmers think that programming languages get outdated, just like operating systems or computer hardware, or even some software (old algorithms replaced by better algorithms), and each programmer should "follow trends", since using the same programming language for 10+ years sounds wrong. But programming languages are like Math. It is like saying "multiplying is outdated" or "the square root is outdated".

if you don't think programming languages can get outdated then why is assembly, fortran, lisp, smalltalk, pascal, basic practically disappeared? programming languages are not like math, it's like the moon

Re: C Is Best (2025)

#250

Post by TZubiri »

pie_flavor wrote: post #44
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…

The 'some degree' is pretty important, though. The Rust language undergoes backwards incompatible changes sometimes, but the Rust tools do not. The 2024 edition has breaking changes since the 2021 edition, but all compilers can compile all historical editions and will do so forever, and new language features are available in as many editions as possible, and editions can be mixed in a dependency tree, so you do not e…

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.

Post reply on HN