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

361–370 of 574 posts

Re: C Is Best (2025)

#361

Post by josephg »

Ygg2 wrote: post #320
pjdesno wrote: post #238

Earlier quoted context omitted.

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

> This is a fundamental limitation Not really. Yeah you need to reach into unsafe to make a doubly linked list that passes borrow checker. Guess what. You need unsafe implementation to print to console. Doesn't mean printing out is unsafe in Rust. That's the whole point of safe abstraction.

I love rust, but C does make it a lot easier to make certain kinds of container types. Eg, intrusive lists are trivial in C but very awkward in rust. Even if you use unsafe, rust’s noalias requirement can make a lot of code much harder to implement correctly. I’ve concluded for myself (after a writing a lot of code and a lot of soul searching) that the best way to implement certain data structures is quite different in rust from how you would do the same thing in C. I don’t think this is a bad thing - they’re different languages. Of course the best way to solve a problem in languages X and Y are different.

And safe abstractions mean this stuff usually only matters if you’re implementing new, complex collection types. Like an ECS, b-tree, or Fenwick tree. Most code can just use the standard collection types. (Vec, HashMap, etc). And then you don’t have to think about any of this.

Re: C Is Best (2025)

#362

Post by coffeemug »

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…

Not always, but sometimes, new things are just better.

One example is null-- a billion dollar mistake as Tony Hoare called it. A Maybe type with exhaustive pattern matching is so dramatically better, it can be worth switching just for that feature alone.

Re: C Is Best (2025)

#364

Post by marcosdumay »

TZubiri wrote: post #244
samiv wrote: post #203

Earlier quoted context omitted.

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

> Are we playing word games here?

No. A single process can have several allocators, switch between them, or use temporary low limits to enforce some kind of safety. None of that has any relation to your system running out of memory.

You won't see any of that in a desktop or a server. In fact, I haven't seen people even discuss that in decades. But it exists, and there are real reasons to use it.

Re: C Is Best (2025)

#365

Post by lelanthran »

gpm wrote: post #356
lelanthran wrote: post #332

Earlier quoted context omitted.

> I'm not saying "automatic", I'm including "sanitizer retursn an error" as default - that's not what happens in C (or at least any C project I've worked on). You have to actively remember and choose to check the error code. Right. But this is what you initially responded to: > You can write code that handles OOM conditions gracefully, but that way of writing code is the default only in C. How did you get from "That…

> How did you get from "That way" to thinking I claimed that C, by default, handles allocation failures? I think you might want to reread the line you quoted directly above this, That way of writing code, i.e. "write[ing] code that handles OOM conditions gracefully" "is the default [...] in C". This is what I am saying is not the case. The default in C is undefined behavior (libc) or crashing (a significant fraction…

> I think you might want to reread the line you quoted directly above this,

I am reading exactly what I said:

> You can write code that handles OOM conditions gracefully, but that way of writing code is the default only in C.

How is it possible to read that as anything other than "That Way Of Writing Code Is The Default Way In C"?

Are you saying that checking the result of malloc (and others) is not the default way of allocating memory?

Re: C Is Best (2025)

#367

Post by uecker »

kibwen wrote: post #294
antirez wrote: post #196

Earlier quoted context omitted.

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.

If so, then it should be trivial for someone to introduce something like Rust's `unsafe` keyword in C such that the unsafe operations can be explicitly annotated and encapsulated. Of course, it's not actually this trivial because what you're saying is incorrect. C is not equipped to enforce memory safety; even mundane C code is thoroughly suffused with operations that threaten to spiral off the rails into undefined b…

It is not so hard to introduce a "safe" keyword in C. I have a patched GCC that does it. The subset of the language which can be used safety is a bit too small to be full replacement on its own, but also not that small.

Re: C Is Best (2025)

#368

Post by stouset »

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.

Go has already more or less won its target market. Rust proponents are still working to convince C and C++ holdouts, who are understandably skeptical given the past several decades of promised replacements that never materialized.

Re: C Is Best (2025)

#369

Post by goku12 »

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…

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

I don't know about Zig, but my experience with Rust's trait system is that it isn't explicitly against OOP. Traits and generics feel like an extension and generalization of the OOP principles. With OOP, you have classes (types) and/or objects (instances) and bunch of methods specific to the class/object. In Rust, you extend that concept to almost all types including structs and enums.

> OOP, by contrast, offers a new conceptual lens: objects, inheritance, polymorphism, and eventually design patterns.

Rust doesn't have inheritance in the traditional sense, but most OOP languages prefer composition to data inheritance. Meanwhile, polymorphism, dynamic dispatch and design patterns all exist in Rust.

Re: C Is Best (2025)

#370

Post by josephg »

antirez wrote: post #158
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…

In Rust you can avoid "unsafe" when you use Rust like it was Go or Python. If you write low level code, that is where C is in theory replaceable only by Rust (and not by Go), then you find yourself in need of writing many unsafe sections. And to lower the amount of unsafe sections, you have to build unnatural abstractions, often, in order to group such unsafe sections into common patterns. Is is a tradeoff, not a sil…

In my experience (several years of writing high performance rust code), there’s only really 2 instances where you need unsafe blocks:

- C interop

- Low level machine code (eg inline assembly)

Most programs don’t need to do either of those things. I think you could directly port redis to entirely safe rust, and it would be just as fast. (Though there will need be unsafe code somewhere to wrap epoll).

And even when you need a bit of unsafe, it’s usually a tiny minority of any given program.

I used to think you needed unsafe for custom container types, but now I write custom container types in purely safe rust on top of Vec. The code is simpler, and easier to debug. And I’m shocked to find performance has mostly improved as a result.

Post reply on HN