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

281–290 of 574 posts

Re: C Is Best (2025)

#281

Post by lelanthran »

gpm wrote: post #223
lelanthran wrote: post #213

Earlier quoted context omitted.

> C doesn't force you to check the allocation at all. No one ever claimed it did; I said, and still do, that the in C , at any rate, the default is to check the returned value from memory allocations. And, that is true. The default in other language is not to recover.

> > C doesn't force you to check the allocation at all. > No one ever claimed it did; You specifically said > Every allocation must be checked at the point of allocation ... > the default is to check the returned value from memory allocations. Default has a meaning, and it's what happens if you don't explicitly choose to do something else. In libc - this is to invoke undefined behavior if the user uses the allocation…

> Default has a meaning, and it's what happens if you don't explicitly choose to do something else.

It also has the meaning of doing the common thing: https://www.merriam-webster.com/dictionary/default

> : a selection made usually automatically or without active consideration

See that "without active consideration" there? The default usage of malloc includes, whether you want to acknowledge it or not, checking the returned value.

C doesn't have anything done automatically, so I am wondering why you would choose to think that by "default" one would mean that something automatically gets done.

Re: C Is Best (2025)

#282

Post by onetoo »

TZubiri wrote: post #250
pie_flavor wrote: post #44

Earlier quoted context omitted.

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.

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 break your dependents either -unless they don't have a new enough version of the compiler to support said newer edition.

Re: C Is Best (2025)

#284

Post by cesaref »

The problem with articles like this is that they read a little like justifying a decision that has already been made. I've a feeling that if it was written in C++/Rust/Go/whatever, it would also be possible to justify that decision with similar reasoning.

Re: C Is Best (2025)

#285

Post by EricRiese »

d_burfoot wrote: post #226

Given SQLite's amazing battery of test code, it seems like it would be valuable, illuminating, and not too difficult to write a test implementation in Rust. Can you get the Rust implementation to pass the test suite? Either answer to that question would be interesting.

SQLite's test suite is proprietary.

A Rust implementation exists. It's called turso

https://github.com/tursodatabase/turso

There's a whole company around it.

Re: C Is Best (2025)

#286

Post by f1shy »

threethirtytwo wrote: post #278
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…

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…

In my circles, there is one part of OOP seen as positive: encapsulation. Everything else, specially inheritance and partly polymorphism are seen extremely negatively. The hype is over. BUT: I still hear more often as I would like, some manager stating “of course we will use C++, because is THE OOP language, and everybody knows OOP and UML are the only right way of doing software” this is an actual verbatim statement I had to listen 4 years ago.

Re: C Is Best (2025)

#287

Post by Svoka »

hbbio wrote: post #5

Makes a lot of sense for SQLite to be written in C. It's a heavily optimized and debugged database implementation: Just look at btree.c with all its gotos :) The only language that would make sense for a partial/progressive migration is zig, in huge part due to its compatibility with C. It's not mentioned in the article though.

What would be a reason to bring Zig in?

For example, Rust has additional memory guarantees when compared to C.

Re: C Is Best (2025)

#288

Post by fauigerzigerk »

wang_li wrote: post #256
bigfishrunning wrote: post #186

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…

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

Is it really activism though, i.e. a concerted effort to put pressure on project leaders and make actual "demands"? Or is it just the occasional young Rust enthusiast asking questions or making the case for Rust?

Re: C Is Best (2025)

#289

Post by nilslindemann »

klaussilveira wrote: post #7

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

Off topic: This CSS improves the usability of that page:

    ul.threadlist li:hover > a {
        color: red;
    }

    ul.threadlist li.origin > a {
        display: block;
        background: rgb(205, 216, 216);
        font-weight: normal;
        padding: 1px 6px;
        margin: 1px -6px;
    }

Re: C Is Best (2025)

#290

Post by kibwen »

pjdesno wrote: post #238
tasn wrote: post #154

Earlier quoted context omitted.

The recent bug in the Linux kernel Rust code, based on my understanding, was in unsafe code, and related to interop with C. So I wouldn't really classify it as a Rust bug. In fact, under normal circumstances (no interop), people rarely use unsafe in Rust, and the use is very isolated. I think the idea of developers developing a "bugs antenna" is good in theory, though in practice the kernel, Redis, and many other pro…

> was in unsafe code, and related to interop with C 1) "interop with C" is part of the fundamental requirements specification for any code running in the Linux kernel. If Rust can't handle that safely (not Rust "safe", but safely), it isn't appropriate for the job. 2) I believe the problem was related to the fact that Rust can't implement a doubly-linked list in safe code. This is a fundamental limitation, and again…

> If Rust can't handle that safely (not Rust "safe", but safely), it isn't appropriate for the job.

Rust is no less safe at C interop than using C directly.

Post reply on HN