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

311–320 of 574 posts

Re: C Is Best (2025)

#311

Post by pdimitar »

pclmulqdq wrote: post #165
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…

I hear "people rarely use unsafe rust" quite a lot, but every time I see a project or library with C-like performance, there's a _lot_ of unsafe code in there. Treating bugs in unsafe code as not being bugs in rust code is kind of silly, also.

For your last sentence, I believe topics are conflated here.

Of course if one writes unsafe Rust and it leads to a CVE then that's on them. Who's denying that?

On the other hand, having to interact with the part of the landscape that's written in C mandates the use of the `unsafe` keyword and not everyone is ideally equipped to be careful.

I view the existence of `unsafe` as pragmatism; Rust never would have taken off without it. And if 5% of all Rust code is potentially unsafe, well, that's still much better than C where you can trivially introduce undefined behavior with many built-in constructs.

Obviously we can't fix everything in one fell swoop.

Re: C Is Best (2025)

#312

Post by pklausler »

waffletower wrote: post #279
pie_flavor wrote: post #58

Earlier quoted context omitted.

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 topic seems to be native programming languages -- I don't think any of the languages concerned are "better in every way" for every possible coding problem. Many will rightfully choose Fortran over Rust for their application -- knowing full well their choice is far away from "better in every way".

When writing code meant to last, you need a language that’s portable across compilers and through time. C has demonstrated both. Fortran 77 and 90 were portable across compilers, but are now at risk from breaking changes, and later versions are not very portable across compilers.

Re: C Is Best (2025)

#313

Post by tialaramex »

guywithahat wrote: post #272
a_random_user wrote: post #104

.. one of the safe languages like.. Go.. o_O

Go is a safe language? It has garbage collection and performs checks for things like buffer overflows and use-after-free

You can have data races in "safe" Go. If you race a trivial object [such as an integer] it's just radioactive and so long as you didn't need it to have any particular value (e.g. you were just going to write it to a log anyway, or you just discard it) you're fine. However if you race a non-trivial object then that's immediately Undefined Behaviour.

Of course Go programmers will say "Just don't do that" but that's exactly what C programmers told us about bounds misses, use after free and so on...

Re: C Is Best (2025)

#314

Post by b40d-48b2-979e »

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.

From my POV having worked at a giant 50,000 person tech org—primarily Java—Kotlin was the kick in the pants that ushered in a lot of changes in the post-Java 11 world. We were on the verge of migrating wholesale to Kotlin after our CTO wrote an internal whitepaper in favor of the direction.

Re: C Is Best (2025)

#315

Post by samiv »

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?

There are several levels here.

In your C++ (or C) program you have one (or more) allocators. These are just pieces of code that juggle blocks of memory into smaller chunks for the program to use. Typically the allocators get their memory from the OS in pages using some OS system call such as sbrk or mmap.

For the sake of argument, let's say I write an allocator that has a limit of 2MiB, while my system has 64Gib or RAM. The allocator can then fail some request when it's internal 2MiB has been exhausted. In C world it'd return a nullptr. In C++ world it would normally throw bad_alloc.

If this happens does this mean the process is out of memory? Or the system is out of memory? No, it doesn't.

That being said where things get murky is because there are allocators that in the absence of limits will just map more and more pages from the OS. The OS can "overcommit" which is to say it gives out more pages than can actually fit into the available physical memory (after taking into account what the OS itself uses etc). And when the overall system memory demand grows too high it will just kill some arbitrary process. On Linux this is the infamous OOM killer that uses the "niceness" score to determine what to kill.

And yes, for the OOM killer there's very little you can do.

But an allocation failure (nullptr or bad_alloc) does not mean OOM condition is happening in the system.

Re: C Is Best (2025)

#316

Post by koakuma-chan »

ViewTrick1002 wrote: post #306
smj-edison wrote: post #269

Earlier quoted context omitted.

In Zig's case, the entire stdlib never allocates on failure, and most libraries follow the same pattern. The philosophy of Zig is allocation/creation can fail, but freeing/destroying must never fail. It's caused me to be really thoughtful with how I design my data structures, and often made me use better ways of representing metadata.

How do you log or tell the world about the state of the program without allocating?

You don't have to allocate to print to stdout if that's what you're asking.

Re: C Is Best (2025)

#317

Post by pdimitar »

antirez wrote: post #196
kibwen wrote: post #184

Earlier quoted context omitted.

For replacing a Python project with Rust, unsafe blocks will comprise 0% of your code. For replacing a C project with Rust, unsafe blocks will comprise about 5% of your code. The fact that the percentage is higher in the latter case doesn't change the fact that 95% of your codebase is just as safe as the Python project would be.

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.

Who is saying that 100% of C code is unsafe? It's potentially unsafe, as in: the mainstream compilers are unable to prove the code is memory-safe.

Rust achieves a sizable but not complete victory on that front.

I can't find the extreme claims that you seem to argue against.

Re: C Is Best (2025)

#318

Post by fulafel »

craftkiller wrote: post #267
dnautics wrote: post #259

Earlier quoted context omitted.

you understand that stack allocation can OOM too?

Can C gracefully recover from running out of stack space?

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

Re: C Is Best (2025)

#319

Post by metalliqaz »

misnome wrote: post #59
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…

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

And here I was just reading in another thread that HN was so much less toxic than other places...

Re: C Is Best (2025)

#320

Post by Ygg2 »

pjdesno wrote: post #238
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…

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

Post reply on HN