C Is Best (2025) • Hacker News Board

Re: C Is Best (2025)

#381

Post by TZubiri » Tue, Jan 06, 2026, 6:35 PM UTC

thisislife2 wrote: post #300

TZubiri wrote: post #244

Earlier quoted context omitted.

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

I am not well-versed in this area but have a doubt - when the OS sends a SIGKILL to a process because it has run of memory for it how can the program catch that before it is killed and deal with it "gracefully"? Does C provide any mechanism to deal with such scenario?

I may be getting SIGKILL and SIGABORT mixed up, but one of them is not sent to the process, rather it's sent to the OS.

If it were any other way then processes could ignore signals and just make themselves permanent, like Maduro or Putin.

Re: C Is Best (2025)

#382

Post by monocasa » Tue, Jan 06, 2026, 6:39 PM UTC

irishcoffee wrote: post #153

monocasa wrote: post #135

Earlier quoted context omitted.

https://blog.pictor.us/rust-is-do-178-certifiable/

> While Rust isn’t “certified” out of the box, it provides attributes that facilitate certification. By design, Rust restricts certain low-level operations and enforces strict memory safety rules, effectively shifting much of the error-checking and verification into compile-time. This means that issues that might otherwise be found by multiple external tools in C/C++ are caught early during the Rust build process. I…

> With developments such as the Ferrocene-qualified compiler, Rust can now meet all the analysis requirements under DO-178C, one of the most stringent safety-critical standards worldwide.

Re: C Is Best (2025)

#383

Post by p2detar » Tue, Jan 06, 2026, 6:39 PM UTC

vips7L wrote: post #252

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…

There is no chance that Kotlin will replace Java. Java is the platform and Kotlin does change semantics. They’ve developed their own features that don’t align with the platform. Suspend functions vs virtual threads, data classes vs records, Kotlin value classes vs Java value classes. The gap is widening.

I‘m in the process of migrating Kotlin code back to Java in our product. My experiment with Kotlin is over and I‘m sticking 100% with Java. I like writing Kotlin, but I dislike reading Kotlin code.

Re: C Is Best (2025)

#384

Post by blub » Tue, Jan 06, 2026, 6:39 PM UTC

pie_flavor wrote: post #187

agentultra wrote: post #83

Earlier quoted context omitted.

I’ve heard this analogy used to justify firing developers for not using GenAI: a cabinet maker who doesn’t use power tools shouldn’t be working as a cabinet maker . If only programming languages (or GenAI) were tools like hammers and augers and drills. Even then the cabinets you see that come out of shops that only use hand tools are some of the most sturdy, beautiful, and long lasting pieces that become the antiques…

Less glue and avoidance of nails and screws doesn't make it sturdier. Fastening things strongly makes your furniture sturdier than not doing so. Antiques suck as often as they don't, and moreover you are only seeing the ones that survived without a base rate to compare it to; they succeeded in spite of power tools, but power tools would have made the same object better. Comparing it to AI makes no sense. Invoking it…

There was an interesting video on YT where an engineer from a fastener company joined a carpenter to compare their products with traditional joints.

The traditional joints held up very well and even beat the engineered connectors in some cases. Additionally one must be careful with screws and fasteners: if they’re not used according to spec, they may be significantly weaker than expected. The presented screws had to be driven in diagonally from multiple positions to reach the specified strength; driving them straight in, as the average DIYer would, would have resulted in a weak joint.

Glue is typically used in traditional joinery, so less glue would actually have a negative effect.

Re: C Is Best (2025)

#385

Post by goku12 » Tue, Jan 06, 2026, 6:40 PM UTC

cozzyd wrote: post #336

uecker wrote: post #225

Earlier quoted context omitted.

The article gave many good reasons where Rust is lacking. The points you raise are also clearly issues. My main additional issues are the high complexity, the syntax, the lack of stability, compilation times (and monomorphization), and lack of alternate implementations. Ignoring the language itself, the aggressive and partially misleading negative and positive marketing.

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 will have to design a new stable standard common ABI that natively supports all the features from these languages, or at least makes it possible to express these features in some way.

Re: C Is Best (2025)

#386

Post by elbear » Tue, Jan 06, 2026, 6:44 PM UTC

9rx wrote: post #353

bigfishrunning wrote: post #239

Earlier quoted context omitted.

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

> 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 What, exactly, does distance mean here? The other explicitly told design consideration for Go was for it to "feel like a dynamically-typed language with statically-typed performance". In other words, the assumption was that Googlers were using C++ for network servers not becaus…

How I interpret his comment about the distance: The benefit of switching from C/C++ to Rust is higher than switching from C++ to Go (in the similar use-cases) or from Java to Kotlin.

Another argument offered for Rust is that it's high-level enough that you can also use it for the web (see how many web frameworks it has). So I think that Rust's proponents see it as this universal language that could be good for everything.

Re: C Is Best (2025)

#387

Post by goku12 » Tue, Jan 06, 2026, 6:45 PM UTC

ethin wrote: post #132

WhyNotHugo wrote: post #62

> Nearly all systems have the ability to call libraries written in C. This is not true of other implementation languages. This is no longer true. Rust, Zig and likely others satisfy this requirements. > Safe languages usually want to abort if they encounter an out-of-memory (OOM) situation. SQLite is designed to recover gracefully from an OOM. It is unclear how this could be accomplished in the current crop of safe l…

> This is no longer true. Rust, Zig and likely others satisfy this requirements. Rust and Zig satisfy this by being C ABI-compatible when explicitly requested. I'm pretty sure that that solution is not actually what the author meant. When you don't explicitly use `extern "C"` in Rust or `export` in Zig, the ABI is completely undefined and undocumented. I would go as far as arguing that the ABI problem, with Rust at l…

The only reasonable way to solve that problem is to design a standard ABI that supports expression of all features in modern compiled languages like Rust, Go, Zig, Haskell, Ada, etc. It doesn't make any sense to design stable ABIs for each language separately, because then you'll end up with a system directory full of dynamic libraries of several distinct ABIs.

Re: C Is Best (2025)

#388

Post by 112233 » Tue, Jan 06, 2026, 6:47 PM UTC

pjmlp wrote: post #329

112233 wrote: post #113

Earlier quoted context omitted.

For big, fixed environments like Qt — sure. For embedded? Please no. Basic is good. Feel free to reimplement C++, your C library still will not have: most of STL as a dependency; unwind tables in all code (including C!); ctor/dtor arrays; insane kilobyte-sized symbols.

"C++20 for Commodore 64" https://www.youtube.com/live/EIKAqcLxtT0?si=J82Us4zBlXLPbZVq It is a matter of skill.

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 that uses it.

Re: C Is Best (2025)

#389

Post by cozzyd » Tue, Jan 06, 2026, 6:48 PM UTC

goku12 wrote: post #385

cozzyd wrote: post #336

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

C++ has reasonable dynamic linking (there are ABI breaks, but I only remember only one really bad one with std::basic_string and C++11), obviously excluding a lot of metaprogramming features, but a lot of C++ dynamic libraries exist that are widely used. Supposedly Swift does a better job, though I'm not familiar. Yes, Rust can dynamically link with a C ABI (as can any language) but it loses a lot of the expressiveness (I imagine, I'm not a rust developer) to have to use the C ABI.

Dynamic languages of course support dynamic linking.

Re: C Is Best (2025)

#390

Post by pclmulqdq » Tue, Jan 06, 2026, 6:50 PM UTC

pdimitar wrote: post #341

nec4b wrote: post #338

Earlier quoted context omitted.

>>Of course if one writes unsafe Rust and it leads to a CVE then that's on them. >>Who's denying that? >>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. Sometimes it's good to read the whole thread.

I did and it does not quite compute. That was glue code, related to interoperating with C. Not a "normal" everyday Rust code. It's an outlier. Helps to read and ingest context. Though I do agree that in the strictest of technical senses it's indeed a "Rust" bug, as in: bug in code written in Rust.

The bug in question is in rust glue code that interfaces with a C library. It's not in the rust-C interface or on the C side. If you write python glue code that interfaces with numpy and there's a bug in your glue, it's a python bug not a numpy bug.