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

401–410 of 574 posts

Re: C Is Best (2025)

#401

Post by goku12 »

epolanski wrote: post #303

> The C language is old and boring. It is a well-known and well-understood language. This is such an under appreciated feature. I'm tired of languages that just keep adding and adding to a language. Work on the standard library or ecosystem, but stop changing the language otherwise you'll never end up anywhere because there is always going to be something that would benefit from some love. Hell, I'd say the same is t…

> It is a well-known and well-understood language.

This isn't entirely true. There are a bunch of UBs that you have to be very careful about. C has the right idea about simplicity. But deterministic behavior is also important because someone will find a way to make use of UBs in their code.

Re: C Is Best (2025)

#402

Post by 9rx »

elbear wrote: post #386
9rx wrote: post #353

Earlier quoted context omitted.

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

> The benefit of switching from C/C++ to Rust is higher than switching from C++ to Go

Ten years ago the memory model was a compelling benefit, sure, but nowadays we have Fil-C, that C++ static analyzer posted here yesterday, etc. There is some remaining marginal benefit that C and C++ still haven't quite caught up with yet, but is that significantly smaller and continually shrinking gap sufficient to explain things as they stand today?

You are right that the aforementioned assumption did not play out in the end. It turns out that C++ developers did, in fact, choose C++ because of C++ and would have never selected Python even if Python was the fastest language out there. Although, funnily enough, a "faster Python" ended up being appealing to Python developers so Go does ultimately have the same story, except around Python (and Ruby) instead of C++.

> Another argument offered for Rust is that it's high-level enough that you can also use it for the web

It was able to do that ten years ago just as well. That doesn't really explain things either.

Re: C Is Best (2025)

#404

Post by thesz »

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…

  > you don't see Go ported to microcontrollers for instance.
AVRGo disagrees: https://github.com/avrgo-org/avrgo

Re: C Is Best (2025)

#405

Post by pclmulqdq »

pdimitar wrote: post #397
pclmulqdq wrote: post #390

Earlier quoted context omitted.

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.

I already agreed that technically it is indeed a bug in the Rust code. I would just contest that such a bug is representative is all. People in this thread seem way too eager to extrapolate which is not intellectually curious or fair.

Nobody is extrapolating from this bug to the rest of rust. The comment I responded to initially was denying that this was a rust bug.

Re: C Is Best (2025)

#406

Post by bluecalm »

epolanski wrote: post #303

> The C language is old and boring. It is a well-known and well-understood language. This is such an under appreciated feature. I'm tired of languages that just keep adding and adding to a language. Work on the standard library or ecosystem, but stop changing the language otherwise you'll never end up anywhere because there is always going to be something that would benefit from some love. Hell, I'd say the same is t…

What I like about C is that when they do add features they are just useful non-controversial features with maybe one exception of VLAs (that one was controversial).

Designated initializers, compound literals, binary literals and the way to printf numbers in binary, constexpr, alignas, #embed, stdbit.h, memset_explicit, restrict to name the ones I really like.

Re: C Is Best (2025)

#407

Post by goku12 »

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

(Memory) safe languages are allowed to guarantee memory safety at any stage, including at runtime using GC and bound checks. That makes every GC language memory safe to a reasonable extend. The novelty in Rust is that it does the same at compile time, mostly automatically.

Re: C Is Best (2025)

#408

Post by staticassertion »

atherton94027 wrote: post #224
staticassertion wrote: post #207

Earlier quoted context omitted.

It's 1 compared to 86, 86 is the baseline.

But you need to control for lines of code at the very least — otherwise you're comparing apples to oranges

I'm perfectly happy to say that it's not a very good way to make a comparison.

Re: C Is Best (2025)

#409

Post by nec4b »

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.

Why is glue code not normal code in Rust? I don't think anyone else would say that for any other language out there. Does it physically pain you to admit it's a bug in Rust code? I write bugs in all kind of languages and never feel the need for adjectives like "technical", "normal", "everyday" or words like "outlier" to make me feel not let down by the language of choice.

Re: C Is Best (2025)

#410

Post by senko »

lelanthran wrote: post #152
kibwen wrote: post #87

Earlier quoted context omitted.

Sure, which is a perfectly acceptable default considering that most code is not in a position to observe allocation failures (because of OS-level overcommit, which is nearly always a good thing), and furthermore most code is not in a position to do anything other than crash in an OOM scenario. If you still want to have control over this without going full no_std, Rust has Vec::try_reserve to grow a Vec while checking…

> most code is not in a position to do anything other than crash in an OOM scenario. That's intentional; IOW the "most code" that is unable to handle OOM conditions are written that way. You can write code that handles OOM conditions gracefully, but that way of writing code is the default only in C. In every other language you need to go off the beaten path to gracefully handle OOM conditions.

Zig puts OOM handling much more front and center than C. In C, you can handle OOM but it's easy to ignore NULL checks on mallocs &co because they almost never happen.

In Zig you must handle it. Even if handling means "don't care, panic", you have to spell that out.

Post reply on HN