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

411–420 of 574 posts

Re: C Is Best (2025)

#411

Post by riku_iki »

baranul wrote: post #216
runjake wrote: post #116

Earlier quoted context omitted.

Context: Along with the never ending pressure to migrate a project to new shiny, there is a lot of momentum against C and other memory-unsafe languages. The US government recently called on everyone to stop using them and move to memory-safe languages. Regardless, there are practices and tools that significantly help produce safe C code and I feel like more effort should be spent teaching C programmers those. Edit: T…

But oddly enough, Zig is not a memory-safe language, and yet still heavily pushed on here. There are a number of measures, comparatively, that can be taken to make C safer too. The story on what can be done with C is still evolving, as Fil-C and other related projects shows. For that matter, there are a number of compiled memory-safe and safer languages: Dlang, Vlang, Golang, etc... who could be discussed and are equ…

> Golang, etc... who could be discussed and are equally viable choices.

Golang is not 100% zero cost close to metal abstraction. You could add Java and .NET too, but they are not replacement for C obviously.

Re: C Is Best (2025)

#412

Post by pdimitar »

pclmulqdq wrote: post #405
pdimitar wrote: post #397

Earlier quoted context omitted.

I already agreed that technically it is indeed a bug in the Rust code. I would just contest that such a bug is representative is all. People in this thread seem way too eager to extrapolate which is not intellectually curious or fair.

Nobody is extrapolating from this bug to the rest of rust. The comment I responded to initially was denying that this was a rust bug.

You and a few others don't -- I did not make that clear, apologies. It's disheartening that a good amount of others do.

Re: C Is Best (2025)

#413

Post by jonny_eh »

> So, for example, Android applications written in Java are able to invoke SQLite (through an adaptor). Maybe it would have been more convenient for Android if SQLite had been coded in Java as that would make the interface simpler. However, on iPhone applications are coded in Objective-C or Swift, neither of which have the ability to call libraries written in Java. Thus, SQLite would be unusable on iPhones had it been written in Java.

This feels like they're responding to people asking for SQLite to be rewritten in Java. Who are these people?!

Re: C Is Best (2025)

#414

Post by senko »

joosters wrote: post #200
lelanthran wrote: post #173

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

Of course it matters, because you (the system admin) can tell your OS not to do that. Which is only helpful if your app knows how to handle the case. Most don't, so overcommit, in general, makes sense.

Re: C Is Best (2025)

#415

Post by [deleted] »

atherton94027 wrote: post #375
erk__ wrote: post #366

Earlier quoted context omitted.

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

[deleted]

Re: C Is Best (2025)

#417

Post by wewtyflakes »

lelanthran wrote: post #235
em3rgent0rdr wrote: post #219

Earlier quoted context omitted.

When C code is run in machines capable of failing with gruesome death, its unsafeness may indeed result in gruesome death.

> When C code is run in machines capable of failing with gruesome death, its unsafeness may indeed result in gruesome death. And yet, it never does. It's been powering those types of machines likely longer than you have been alive, and the one exception I can think of where lives were lost, the experts found that the development process was at fault, not the language. If it was as bad as you make out, we'd have many…

https://en.wikipedia.org/wiki/Therac-25#Root_causes

Re: C Is Best (2025)

#418

Post by pdimitar »

nec4b wrote: post #409
pdimitar wrote: post #341

Earlier quoted context omitted.

I did and it does not quite compute. That was glue code, related to interoperating with C. Not a "normal" everyday Rust code. It's an outlier. Helps to read and ingest context. Though I do agree that in the strictest of technical senses it's indeed a "Rust" bug, as in: bug in code written in Rust.

Why is glue code not normal code in Rust? I don't think anyone else would say that for any other language out there. Does it physically pain you to admit it's a bug in Rust code? I write bugs in all kind of languages and never feel the need for adjectives like "technical", "normal", "everyday" or words like "outlier" to make me feel not let down by the language of choice.

I have worked with Rust for ~3.5 years. I had to use the `unsafe` keyword, twice. In that context it's definitely not everyday code. Hence it's difficult to use that to gauge the language and the ecosystem.

Of course it's a bug in Rust code. It's just not a bug that you would have to protect against often in most workplaces. I probably would have allowed that bug easily because it's not something I stumble upon more than once a year, if even that.

To that effect, I don't believe it's fair to gauge the ecosystem by such statistical outliers. I make no excuses for the people who allowed the bug. This thread is a very good demonstration as to why: everything Rust-related is super closely scrutinized and immediately blown out of proportion.

As for the rest of your emotionally-loaded language -- get civil, please.

Re: C Is Best (2025)

#419

Post by christophilus »

epolanski wrote: post #303

> The C language is old and boring. It is a well-known and well-understood language. This is such an under appreciated feature. I'm tired of languages that just keep adding and adding to a language. Work on the standard library or ecosystem, but stop changing the language otherwise you'll never end up anywhere because there is always going to be something that would benefit from some love. Hell, I'd say the same is t…

This is one of the things I love about Clojure. It's a simple, elegant, stable language.

Re: C Is Best (2025)

#420

Post by bluecalm »

kibwen wrote: post #177
kitd wrote: post #12

Earlier quoted context omitted.

That's the first time I've heard the C syntax being called "too rich". It's the epitome of succinctness IMHO (too a fault, even, or maybe I'm just old). Are you confusing it with C++? If so, you have a point.

C's syntax is pretty lacking by modern standards, requiring gross things like The Lexer Hack to resolve ambiguities that other languages just don't suffer from: https://en.wikipedia.org/wiki/Lexer_hack . To say nothing of the madness that is C's type declaration syntax, necessitating tools like https://cdecl.org/ and "the spiral rule" for reading type declarations (which doesn't actually produce the correct result an…

So "modern standard" is to make it easier for compiler writers instead of programmer to read the code? Thanks god C designers had their priorities elsewhere.

>>"the spiral rule"

Not a problem in 99.99% of cases where it's just: type name = something;

with maybe * and [] somewhere.

Post reply on HN