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

231–240 of 574 posts

Re: C Is Best (2025)

#231

Post by cladopa »

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 great thing about C is that is was not designed by a committee at all. It was designed by a person with strong opinions. This means it is really great for what it does well(what the author was interested in).

To illustrate the difference look at C++, it was designed by a person with strong opinions, but then left it to be controlled by a committee.

If you look at the structure of C++ in Backus Naur form it is absolutely nuts. The compile times have gone through the roof and people leave to create new languages like jai, Zig or whatever.

Common Lisp was designed by committee. It is as chaotic as C++.

Rust is also gigantic. I am very careful not to use in critical systems because it is so big unless we could restrict it with the compiler or something.

Re: C Is Best (2025)

#232

Post by wy1981 »

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…

> Every project and programmer shouldn't feel they have to justify their choice not to use Rust

Maybe writing about it was taken as an opportunity to clarify their own thinking about the topic?

Re: C Is Best (2025)

#233

Post by Certhas »

antirez wrote: post #164
erk__ wrote: post #160

Earlier quoted context omitted.

A quick unscientific count on cve.org counts ~86 race condition CVEs in the Linux kernel last year, so you might be overstating how well bug antennas work.

If the kernel was completely written in Rust, we could have a lot of unsafe places, and many Rust CVEs. It is hard to tell, and the comparison in theory should be made after the kernel is developed only by people lacking the C experience that made the current developers so able to reason about race conditions (also when they write Rust).

That's quite the double standard. You extrapolate from one single Rust bug, but insist that "it's hard to tell" and you need completely unrealistic levels of empirical evidence to draw conclusions from the reported C bugs...

Reminds me of this classic: "Beware Isolated Demands For Rigor" (https://slatestarcodex.com/2014/08/14/beware-isolated-demand...)

Re: C Is Best (2025)

#234

Post by benrutter »

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.

I think that's true - but I guess Rust and Zig are unique in that list on being new memory-managed languages (i.e. without garbage collectors).

Low level memory-managed languages have been C and C++ mostly for a really long time, so I think Rust and Zig probably seem "more new" than the likes of Kotlin, Go, Elixir, Gleam, etc.

Re: C Is Best (2025)

#235

Post by lelanthran »

em3rgent0rdr wrote: post #219
toxik wrote: post #142

Earlier quoted context omitted.

Asbestos causes mesothelioma and gruesome death. C does not. Be serious.

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 many many occurrences of this starting in the 80s. We don't.

Re: C Is Best (2025)

#238

Post by pjdesno »

tasn wrote: post #154
antirez wrote: post #130

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…

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 is an issue when the fundamental requirement for the task is to interface to data structures implemented as doubly-linked lists.

No matter how good a language is, if it doesn't have support for floating point types, it's not a good language for implementing math libraries. For most applications, the inability to safely express doubly-linked lists and difficulty in interfacing with C aren't fundamental problems - just don't use doubly-linked lists or interface with C code. (well, you still have to call system libraries, but these are slow-moving APIs that can be wrapped by Rust experts) For this particular example, however, C interop and doubly-linked lists are fundamental parts of the problem to be solved by the code.

Re: C Is Best (2025)

#239

Post by bigfishrunning »

9rx wrote: post #214
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…

> I think this is because of the gap in its target market Surely that gap has been filled for at least a decade, even if only by Rust itself? Moreover, I am not sure that serves as an explanation as it shows up in the strangest places. As you mention Go: Visit any discussion about Go and you'll find some arbitrary comment about Rust, even though, as you point out, they don't even exist in the same niche; being differ…

> Surely that gap has been filled for at least a decade, even if only by Rust itself?

I think this is the argument made by the "Rust Evangelism Task Force" -- that Rust provides the features that C and C++ are missing. What i meant by "gap" is "the distance between C or C++ and Rust is greater then the distance between C++ and Go (in Go's target use case) or between Java and Kotlin". For the record, I do think all of these languages are great; I'm just trying to reason out the "rewrite it in Rust" mantra that has taken hold in many online communities, including this one.

> You don't? https://tinygo.org

I wasn't aware of this, thank you.

Re: C Is Best (2025)

#240

Post by [deleted] »

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

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…

[deleted]
Post reply on HN