Given they added Section 2 and 3 in response to previous commentary: https://news.ycombinator.com/item?id=16585120 it seems rather stupid to take a sub-heading as the title.
I'm certain you can think why I chose that second heading.
Yeh, clickbait
C Is Best (2025)
501–510 of 574 posts
Re: C Is Best (2025)
#502Earlier quoted context omitted.
I'm very much into Rust but this article is precisely about the fact that Rust is not "better in every way"...
This article was written nine years ago, when Rust 1.0 was two years old, by an author who spent a small (but nonzero) amount of time evaluating Rust.
The most charitable interpretation of this is that the Reddit mods should stick to Reddit. If they had, this wouldn't have reflected so poorly on them.
Re: C Is Best (2025)
#503Earlier quoted context omitted.
Depends on your definition of graceful but the C standard doesn't preclude handling it and there's POSIX interfaces such as sigaltstack / sigsetjmp etc that fit and indeed some code like language runtimes use this to react to stack exhaustion (having first set up guard pages etc).
Or in short: no, C is no better than Rust at gracefully recovering from stack overflow, either in theory or in practice.
[deleted]
Re: C Is Best (2025)
#504Earlier quoted context omitted.
Yes, sorry, apparently not quick enough. I actually do not think it is horrible. It is a nice language, but I still do not like it and see many downsides. What I hate though is how aggressively it is marketed. See my other response for details.
Nobody is marketing it. It doesn't have a marketing budget. What you're seeing are lots of people that really like it because it's really good. Not flawless obviously but a significant improvement on C and C++.
I see a lot of activity of very specific parts of the industry promoting it. But also enthusiasts doing aggressive marketing are doing aggressive marketing - even if they do not have a budget. Whether it is an improvement is debatable. From my perspective, it is an improvement in some aspects and a significant step back in others. What is unacceptable though is the significant hate and pressure towards people who have other priorities and preferences, which is created by the "we must stamp out memory safety issues at all cost and Rust is the solution" narrative.
Re: C Is Best (2025)
#505Earlier quoted context omitted.
> 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 o…
> Are you saying that checking the result of malloc (and others) is not the default way of allocating memory? In C - yes. I've said that repeatedly now...
>> Are you saying that checking the result of malloc (and others) is not the default way of allocating memory?
> In C - yes. I've said that repeatedly now...
Well, that's just not true. The instances of unchecked allocations are both few and far between, *and* treated as bugs when reported :-/
Maybe you should program in a language for a little bit before forming an opinion on it :-/
Re: C Is Best (2025)
#506Earlier quoted context omitted.
Of course it matters, because you (the system admin) can tell your OS not to do that. Which is only helpful if your app knows how to handle the case. Most don't, so overcommit, in general, makes sense.
You can't really on linux. There's no way to do sparse allocations then because when you turn off overcommit MAP_NORESERVE still reserves memory ... It's a place where windows legitimately is better than linux.
> You can't really on linux. There's no way to do sparse allocations then because when you turn off overcommit MAP_NORESERVE still reserves memory...
Sure, but ... what does that have to do with this thread? Using `mmap` is not the same as using `malloc` and friends.
If you turn off overcommit, malloc will return NULL on failure to allocate. If you specifically request mmap to ignore overcommit, and it does, why are you surprised?
Re: C Is Best (2025)
#507Earlier quoted context omitted.
I know one C++ library that caches data but never evicts. Instead, the library author expects you to restart your app every 24 hours.
> I know one C++ library that caches data but never evicts. Instead, the library author expects you to restart your app every 24 hours. It may not be as simple as "that's our policy". I worked at one place (embedded C++ code, 2018) that simply reset the device every 24h because they never managed to track down all the leaks. Finding memory leaks in C++ is a non-trivial and time-consuming task. It gets easier if your…
Use Valgrind? Or are we talking projects that have become far too big for their own good, cause leaks aren't hard at all to find with the right tools and a bit of profiling... now crossing thread boundaries and weird dynamic programming tricks maybe, but thats a very different case and not really refecting on C++ itself, would likely trip up a GC lang as well.
Re: C Is Best (2025)
#508Earlier quoted context omitted.
Lack of (useful) dynamic linking is a huge problem IMO.
What do you mean by useful dynamic linking? Dynamic linking with C ABI is supported natively in Rust and is very widely used (just checked GitHub), especially for FFI like in Python modules (PyO3). If you mean an ABI that supports all the Rust features (without extern C), then it's a problem faced by every language that has more features than C - C++, Haskell, Go, Zig, etc included. To solve that problem, somebody wi…
It is problem of all languages whose extensions to C are badly designed. That it works with the C FFI just shows that C part properly supports it while Rust does not. And yes, C++ has similar problems as Rust.
Re: C Is Best (2025)
#509Earlier quoted context omitted.
I'm confused. What is a matter of skill? You linked 6 hour livestream where person is working on translating AVR assembly to 6502. What was your point, that translating assembly or executables to another architecture takes a lot of skill? Yes, it does! Because I could not, by scrubbing that video, find anything where immense skill is used to deal with the enormous overhead that standard C++ forces on every program th…
Here is a better one then, "Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17" https://youtu.be/zBkNBP00wJE?si=uqUwVMMEpp4ZPWun It is a matter of skill, understanding C++ and how to make it useful for embedded systems, and being able to understand standard library isn't a requirement for each executable. By the way, the famous Arduino and ESP32 hasve no problem dealing with C++. As we also didn't, bac…
> standard library isn't a requirement for each executable.
So you also agree that C++ libraries are a bad fit for embedded? Because in the video you linked, that person did not use any libraries.
It is one thing to compile small standalone binary, using non-conforming compiler extensions to disable rtti and exceptions. It is another to write C++ library. By standard, even freestanding C++ requires RTTI, exceptions and most of standard library. If you need to implement your own STL subset to satisfy the library, then modify the library to work with your STL, the resulting API is not much of an API, is it?
Re: C Is Best (2025)
#510Earlier quoted context omitted.
Here is a better one then, "Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17" https://youtu.be/zBkNBP00wJE?si=uqUwVMMEpp4ZPWun It is a matter of skill, understanding C++ and how to make it useful for embedded systems, and being able to understand standard library isn't a requirement for each executable. By the way, the famous Arduino and ESP32 hasve no problem dealing with C++. As we also didn't, bac…
> standard library isn't a requirement for each executable. So you also agree that C++ libraries are a bad fit for embedded? Because in the video you linked, that person did not use any libraries. It is one thing to compile small standalone binary, using non-conforming compiler extensions to disable rtti and exceptions. It is another to write C++ library. By standard, even freestanding C++ requires RTTI, exceptions a…
Just like C libraries are a bad fit for embedded, no difference there, although C++ haters pretend otherwise, even though half of libc is unusable in freestanding.
It takes skill to make use of Arduino, ESP32, and other C++ embedded libraries, being able to write custom C++ libraries, master compiler switches and linker maps.