Live data from Hacker News

C Is Best (2025)

sqlite.org

251–260 of 574 posts

Re: C Is Best (2025)

#251

Earlier quoted context omitted.

I’ve heard this analogy used to justify firing developers for not using GenAI: a cabinet maker who doesn’t use power tools shouldn’t be working as a cabinet maker . If only programming languages (or GenAI) were tools like hammers and augers and drills. Even then the cabinets you see that come out of shops that only use hand tools are some of the most sturdy, beautiful, and long lasting pieces that become the antiques…

Less glue and avoidance of nails and screws doesn't make it sturdier. Fastening things strongly makes your furniture sturdier than not doing so. Antiques suck as often as they don't, and moreover you are only seeing the ones that survived without a base rate to compare it to; they succeeded in spite of power tools, but power tools would have made the same object better. Comparing it to AI makes no sense. Invoking it…

> Less glue and avoidance of nails and screws doesn't make it sturdier. Fastening things strongly makes your furniture sturdier than not doing so.

No disrespect intended, but your criticism of the analogy reveals that you are speaking from assumptions, but not knowledge, about furniture construction.

In fact, less glue, and fewer fasteners (i.e. design that leverages the strength of the materials), is exactly how quality furniture is made more sturdy.

Re: C Is Best (2025)

#252

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.

I think this is because of the gap in its target market -- Rust is firmly positioned to replace C and C++, which have a long history of safety issues. Kotlin is positioned to replace java, and besides a few quality-of-life improvements, it changes some syntax but very few semantics, so the gap is much smaller. Go was originally pitched as a C or C++ replacement, and it's very nice for deeply parallel programs like we…

There is no chance that Kotlin will replace Java. Java is the platform and Kotlin does change semantics. They’ve developed their own features that don’t align with the platform. Suspend functions vs virtual threads, data classes vs records, Kotlin value classes vs Java value classes. The gap is widening.

Re: C Is Best (2025)

#253

Earlier quoted context omitted.

I think this is because of the gap in its target market -- Rust is firmly positioned to replace C and C++, which have a long history of safety issues. Kotlin is positioned to replace java, and besides a few quality-of-life improvements, it changes some syntax but very few semantics, so the gap is much smaller. Go was originally pitched as a C or C++ replacement, and it's very nice for deeply parallel programs like we…

Out of interest > As a programmer that picks up a new language every 2-3 years (and one that is privileged to have an employer that tolerates this) does this mean they allow you to tinker around on your own for this, or do you actually then start to deploy things to production written in the new language. After having quite a long career as a programmer, I realised that if I were ever CTO at a startup, unless there w…

I do deploy things in different languages -- We are a small team of open-minded programmers, and we are on a constant search for better tools and methods. I work for a robotics company (and have for many years), and having the flexibility to use Pion WebRTC (in Go) or PCL (in C++) or PyTorch (in Python) outweighs the cost of having software written in multiple languages.

Re: C Is Best (2025)

#254

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…

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

Re: C Is Best (2025)

#255
post #246

Earlier quoted context omitted.

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

Always gotta get my yum yucked.

Just been screwed too many times I guess. I do like it more than Kotlin though. The language is powerful.

Re: C Is Best (2025)

#256

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.

I think this is because of the gap in its target market -- Rust is firmly positioned to replace C and C++, which have a long history of safety issues. Kotlin is positioned to replace java, and besides a few quality-of-life improvements, it changes some syntax but very few semantics, so the gap is much smaller. Go was originally pitched as a C or C++ replacement, and it's very nice for deeply parallel programs like we…

>To summarize, Rust provides a lot of compile-time discipline that C and C++ are lacking, and many people are tired of maintaining code that was developed without that discipline. Rust makes it harder to write low-effort software.

This doesn't explain why so many rust activists are going to projects they have no involvement in and demanding they be rewritten in rust.

What's happening is that there are progressive minded people who have progressive minded tactics, where they have a cause and everywhere they go they push their cause regardless of whether the places they are going have anything to do with their cause.

Re: C Is Best (2025)

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

Every serious project should be able to justify its choice of tools. "Because I feel like it" is fine for hobby projects or open-source passion projects, but production-worthy software should have reasoning behind its choices. That reasoning can be something like "it's most effective for us because we know it better" but it should be a deliberate, measured choice. SQLite is an example of an extremely high quality sof…

Indeed, indeed.

Re: C Is Best (2025)

#258

Earlier quoted context omitted.

Sure, Rust can compile old code. But you can't upgrade that old Rust code to new Rust code very easily. The fact that C was effectively "born old" means you can take a C89 program and compile it as C23 and it should simply work, with extremely minimal changes, if any. That's a killer feature when you're thinking in decades. Which SQLite is.

You would need to be incredibly careful with compiling old C89 code on a modern compiler. It's not the language changes that would get you, it's a change in how compilers treat undefined behavior. There has always been undefined behavior in C, but back in the day, compilers were nowhere near as aggressive in taking advantage of it to make your code faster. Most C programmers tended to treat C as portable assembly and…

> There has always been undefined behavior in C, but back in the day, compilers were nowhere near as aggressive in taking advantage of it to make your code faster.

That much is true. If you put the derefence of a pointer and the null check in the wrong order both those statements would have code emitted for them.

Now, it is almost certain that one of those statements would not be emitted.

OTOH, compiling with -O0 still leaves most code to be emitted and fewer dead-code elimination places.

Re: C Is Best (2025)

#259
post #17

> Rust needs a mechanism to recover gracefully from OOM errors. Linus also brought this up: https://lkml.org/lkml/2021/4/14/1099

None of Rust's language features allocate; not arrays, not closures, not iterators. Everything is stack-allocated by default. Rust code doesn't malloc unless you use a library that calls malloc; in other words, exactly like C. Rust fully supports turning off the parts of the standard library that perform allocation, and this is precisely what embedded code and the Linux kernel does. So Rust already gives you full con…

you understand that stack allocation can OOM too?

Re: C Is Best (2025)

#260
post #246

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.

I worked on a Scala project about 15 years ago and it definitely felt overly complex. Similar to early C++, everyone used their own dialect.
Post reply on HN