C Is Best (2025) • Hacker News Board

Re: C Is Best (2025)

#541

Post by 112233 » Wed, Jan 07, 2026, 5:53 PM UTC

pjmlp wrote: post #524

112233 wrote: post #513

Earlier quoted context omitted.

C libraries are excellent for embedded! You can write libraries like SQLite, that can run on bare metal and only require a few external functions from the platform, while still being valid C library! You cannot make it in C++, because any valid C++ library imposes massive requirements on the environment I already mentioned. C does no such thing!

Some people have the skills to make C++ work on a GBA, https://github.com/GValiente/butano Arduino, https://docs.arduino.cc/arduino-cloud/guides/arduino-c/ Or even ESP32, https://docs.espressif.com/projects/esp-idf/en/stable/esp32/... Others do not. As for C does not such thing, strangly there are enough examples from TI, Microchip, Atmel that prove otherwise.

These are great, thanks! That GBA "butano" compiles with -fno-rtti -fno-exceptions, so it is not a C++ engine/library according to C++ standard! It is, however, an impressive piece of work.

The ESP32 SDK (I lol'd at your "even", those Xtensa/RISCV chips can even run linux kernel!) is extremely impressive - they support enabling/disabling rtti and exceptions (obviously disabled by default, but the fact they implemented support for that is amazing). So "real C++" is possible on ESP32, which is good to know.

For comparision, here are the minimum SQLite dependencies from the submitted article: memcmp() memcpy() memmove() memset() strcmp() strlen() strncmp()

Of course you could run javascript and erlang on MCU too, but is that API better than C? Your claim of "skill issue" sounds like RedBull challenge. Please let us unskilled people simply call library functions.

Re: C Is Best (2025)

#542

Post by ActorNightly » Wed, Jan 07, 2026, 6:24 PM UTC

pie_flavor wrote: post #58

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 should not be strange that a tool which is better in every way and makes your code less buggy by default has its praises sung by most of the people who use it. It would be odd to go around saying 'electric drills are strangely and disproportionately pushed at Home Depot over the good old hand auger', and even if I don't work at your contracting company I'd be slightly unnerved about you working on my house.

The issue is that Rust proponents automatically assume that if you write enough C code, there will be memory related bugs.

In reality, this is not the case. Bad code is the result of bad developers. Id rather have someone writing C code that understands how memory bugs happen rather than a Rust developer thinking that the compiler is going to take care of everything for them.

Re: C Is Best (2025)

#543

Post by blank_state » Wed, Jan 07, 2026, 6:57 PM UTC

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…

Rust programmers have this "holier than you" attitude that is so toxic. It's essentially wokeism for programming. No wonder it originates from San Francisco, from all places.

The language itself features interesting ideas, many of them borrowed (pun intended) from Haskell, so not that new after all. But the community behavior proved consistently abysmal. A real put off.

Re: C Is Best (2025)

#544

Post by steveklabnik » Wed, Jan 07, 2026, 7:40 PM UTC

irishcoffee wrote: post #539

steveklabnik wrote: post #536

Earlier quoted context omitted.

Qualifying Ferrocene was way, way, way less expensive than that, and they've already had multiple versions of Rust qualified. The incremental qualifications are even easier and cheaper than the initial one is.

26262 is a lot less expensive than DO-178.

I'd believe it, but from talking about this with the Ferrocene folks, there's just structural issues why it was much easier to qualify rustc than it has been to qualify C compilers. This is how they're able to offer the product at a significantly lower price point, and how they've been able to fairly regularly re-qualify new versions quickly.

It is certainly non-trivial.

Re: C Is Best (2025)

#545

Post by spopejoy » Wed, Jan 07, 2026, 9:35 PM UTC

ruszki wrote: post #170

Supernaut wrote: post #137

Earlier quoted context omitted.

Absolutely. Our thought leaders have been pushing functional programming for a long time now.

Is it possible to have an OOP language which is also functional? Or is it impossible without imperative paradigms?

Smalltalk, the original OOP lang, is "both", at least if you're not one of those people who thinks FP c'est impossible if it's not ML or haskell

Re: C Is Best (2025)

#546

Post by hulitu » Wed, Jan 07, 2026, 9:45 PM UTC

bigfishrunning wrote: post #186

donkeybeer wrote: post #159

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…

> Rust is firmly positioned to replace C and C++

I can't wait to see results. Until now, the only real world usage was for coreutils in Ubuntu, with disastrous consequences.

Anyway, without writing the OS in Rust, Rust will always be a second tier language.

Re: C Is Best (2025)

#547

Post by steveklabnik » Wed, Jan 07, 2026, 9:52 PM UTC

hulitu wrote: post #546

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…

> Rust is firmly positioned to replace C and C++ I can't wait to see results. Until now, the only real world usage was for coreutils in Ubuntu, with disastrous consequences. Anyway, without writing the OS in Rust, Rust will always be a second tier language.

> Until now, the only real world usage was for coreutils in Ubuntu,

This is simply not true, there are millions of lines of Rust code running in production at the largest tech companies in the world.

Re: C Is Best (2025)

#548

Post by pie_flavor » Thu, Jan 08, 2026, 12:11 AM UTC

TZubiri wrote: post #379

onetoo wrote: post #282

Earlier quoted context omitted.

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

Hmm, couple of questions. what would be the difference with a binary that's has both a py2 and py3 interpreter and a flag --edition=2 or =3 redirects to either file? If I have Rust code from 2021, can I add a feature from 2024 and run it with --edition=2021 or 2024? Wouldn't adding a 2024 feature then possibly break the 2021 code? I think the fact that rust is compiled has a big impact in terms of bc for dependencies…

Rust is not‡ dynamically linked. The whole tree is compiled from source every time. The same compiler compiles all editions of the language together, and it is exactly the same as py3 interpreting a py2 script and allowing a py3 script to call it or vice versa.

Very few features are restricted to the 2024 edition; only those that actively introduce or leverage breaking changes. Most things released since 2024 are available in 2015 edition. If you want to upgrade to 2024 edition, that is a manifest flag; your code may break when you change it, and there's incompatibility lints available on the lower editions to tell you what will break when that happens and how to fix it.

Re: C Is Best (2025)

#549

Post by cozzyd » Thu, Jan 08, 2026, 1:25 AM UTC

zavec wrote: post #302

fauigerzigerk wrote: post #288

Earlier quoted context omitted.

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?

You haven't been getting the checks? Bring that up at our next secret cabal meeting.

They're borrow checks

Re: C Is Best (2025)

#550

Post by School-Cotton » Thu, Jan 08, 2026, 3:12 AM UTC

hulitu wrote: post #546

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…

> Rust is firmly positioned to replace C and C++ I can't wait to see results. Until now, the only real world usage was for coreutils in Ubuntu, with disastrous consequences. Anyway, without writing the OS in Rust, Rust will always be a second tier language.

> I can't wait to see results. Until now, the only real world usage was for coreutils in Ubuntu

I spent five years working at a company (Materialize) whose main product is entirely in Rust. Since then I work at a company (Polar Signals) where sadly I have to use C and Go, but the main backend storage layer is in Rust. And several of our customers use Rust and it would be a show-stopping bug for them if our product stopped working on Rust codebases.

Besides all that, plenty of companies you’ve heard of are now writing large amounts of new code in Rust — most notably Meta and Amazon. Large parts of Firefox are in Rust and have been for years.

Ubuntu coreutils is underselling it a bit.