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

561–570 of 574 posts

Re: C Is Best (2025)

#561

Post by baranul »

giancarlostoro wrote: post #344
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…

Carbon is what could someday be a real successor to C++ in my eyes. It actually focuses on being compatible with C++ code similar to how Kotlin can work with Java directly, except it will make a lot more sense once it is stable and usable, I just hope its not a 'forever-project' like Fuchsia.

Good point. Many of these other languages claim to be "successors", but are really C++ alternatives, that can have very different programming philosophies, goals, and use cases.

Re: C Is Best (2025)

#562

Post by baranul »

fclairamb wrote: post #512
thesz wrote: post #404

Earlier quoted context omitted.

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

No commit for 7 years but https://tinygo.org/docs/reference/microcontrollers/ is up to date.

Not sure what you mean, because tinygo is significantly active[1].

[1] https://github.com/tinygo-org/tinygo (latest release was a month ago from this post)

Re: C Is Best (2025)

#563

Post by torstenvl »

wewtyflakes wrote: post #556
torstenvl wrote: post #555

Earlier quoted context omitted.

Please don't post flamebait or FUD here. The Therac-25 was not programmed in C.

How was this flamebait? It is an example of how bad programming choices/assumptions/guardrails costs lives, a counterargument to the statement of 'And yet, it never does'. Splitting hairs if the language is C or assembly is missing the spirit of the argument, as both those languages share the linguistic footguns that made this horrible situation happen (but hey, it _was_ the 80s and choices of languages was limited!)…

The claim was "And yet, it [C] never does ['result in gruesome death']."

Re: C Is Best (2025)

#564

Post by selfmodruntime »

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.

There is a reason for this. A lot of libraries were written at a time when the Rust compiler either rejected sound and safe code so you have to reach for unsafe, or `core` didn't yet deliver safe abstractions.

Re: C Is Best (2025)

#565

Post by selfmodruntime »

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…

For 1) The necessary safety guarantees downgrade to the level available in C all the time.

Re: C Is Best (2025)

#566

Post by selfmodruntime »

idle_zealot wrote: post #78
uecker wrote: post #73

I agree that C is best. I think Rust is actually a language with some severe downsides, despite having including some very good ideas and C having some real issues. But it will take a couple of years before one can discuss this rationally without being flamed at.

If you want to spread this idea, it would probably help your cause if you pointed to what you think Rust does particularly poorly. Steep learning curve, npm-esque packaging?

Both Pin Projection and the handling of async are pretty bad in my opinion and I write a lot of Rust code. The syntax is also slowly getting very funky with horrible additions like the recent `+ use ` snytax. I also agree with the orphan rule but it makes a lot of code very ugly, fast.

Re: C Is Best (2025)

#567

Post by selfmodruntime »

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…

Eh. I write quite a bit of Rust and this story is not as simple as you tell it.

Re: C Is Best (2025)

#568

Post by wewtyflakes »

torstenvl wrote: post #563
wewtyflakes wrote: post #556

Earlier quoted context omitted.

How was this flamebait? It is an example of how bad programming choices/assumptions/guardrails costs lives, a counterargument to the statement of 'And yet, it never does'. Splitting hairs if the language is C or assembly is missing the spirit of the argument, as both those languages share the linguistic footguns that made this horrible situation happen (but hey, it _was_ the 80s and choices of languages was limited!)…

The claim was "And yet, it [C] never does ['result in gruesome death']."

How many asterisks do you need in order to be technically correct while also missing the point?

Re: C Is Best (2025)

#569

Post by torstenvl »

wewtyflakes wrote: post #568
torstenvl wrote: post #563

Earlier quoted context omitted.

The claim was "And yet, it [C] never does ['result in gruesome death']."

How many asterisks do you need in order to be technically correct while also missing the point?

The point is simple. Don't make false claims and don't post flame bait.

Re: C Is Best (2025)

#570

Post by wewtyflakes »

torstenvl wrote: post #569
wewtyflakes wrote: post #568

Earlier quoted context omitted.

How many asterisks do you need in order to be technically correct while also missing the point?

The point is simple. Don't make false claims and don't post flame bait.

We need to agree to disagree on this one; the claim that C is fine and does not cause harm due to its multitude of foot-guns, I think, is an egregious and false claim. So don't make false claims and don't post toxic positivity, I guess?
Post reply on HN