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

391–400 of 574 posts

Re: C Is Best (2025)

#391

Post by gpm »

lelanthran wrote: post #365
gpm wrote: post #356

Earlier quoted context omitted.

> How did you get from "That way" to thinking I claimed that C, by default, handles allocation failures? I think you might want to reread the line you quoted directly above this, That way of writing code, i.e. "write[ing] code that handles OOM conditions gracefully" "is the default [...] in C". This is what I am saying is not the case. The default in C is undefined behavior (libc) or crashing (a significant fraction…

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

Re: C Is Best (2025)

#392

Post by goku12 »

shevy-java wrote: post #208

Well, can't argue with it. Ruby and Python are written mostly in C underneath. Many try to replace C. All failed. I'd love to see a language that could satisfy both high end needs and low need needs. I would not know how such a language would look though.

> Ruby and Python are written mostly in C underneath. > > Many try to replace C. All failed.

What do you mean by all failed? Rust supports CPython modules using PyO3 [1]. Even the popular polars dataframe library [2] uses it.

[1] https://github.com/PyO3/pyo3

[2] https://github.com/pola-rs/polars

Re: C Is Best (2025)

#393

Post by orthoxerox »

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.

Yeah, Kotlin is stuck in an uncomfortable position, like F# is in the .NET world. It has pioneered several important features, but now the big brother has implemented them slightly differently and people demand interop from you.

At least Kotlin can theoretically retreat to Android.

Re: C Is Best (2025)

#394

Post by locknitpicker »

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…

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

This is a disingenuous opinion. The level of militance involved in this propaganda push goes way beyond mere interest. Just look at people who actually enjoy Java, C++, Python, etc. These are the most popular languages that mankind ever developed,and countless people built very successful careers around them. Yet, you don't see even a fraction of the fanboys you see constantly pushing these experimental languages.

Re: C Is Best (2025)

#395

Post by goku12 »

knowitnone3 wrote: post #249
IvanK_net wrote: post #242

Many non-programmers think that programming languages get outdated, just like operating systems or computer hardware, or even some software (old algorithms replaced by better algorithms), and each programmer should "follow trends", since using the same programming language for 10+ years sounds wrong. But programming languages are like Math. It is like saying "multiplying is outdated" or "the square root is outdated".

if you don't think programming languages can get outdated then why is assembly, fortran, lisp, smalltalk, pascal, basic practically disappeared? programming languages are not like math, it's like the moon

Many of those are still under active development (both language and tooling) and code is still being written in them. They have hardly disappeared.

Re: C Is Best (2025)

#396

Post by hirvi74 »

kibwen wrote: post #290
pjdesno wrote: post #238

Earlier quoted context omitted.

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

> If Rust can't handle that safely (not Rust "safe", but safely), it isn't appropriate for the job. Rust is no less safe at C interop than using C directly.

(Not the user you were replying to)

If Rust is no less safe than C in such a regard, then what benefit is Rust providing that C could not? I am genuinely curious because OS development is not my forte. I assume the justification to implement Rust must be contingent on more than Rust just being 'newer = better', right?

Re: C Is Best (2025)

#397

Post by pdimitar »

pclmulqdq wrote: post #390
pdimitar wrote: post #341

Earlier quoted context omitted.

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.

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.

Re: C Is Best (2025)

#398

Post by guestbest »

p2detar wrote: post #383
vips7L wrote: post #252

Earlier quoted context omitted.

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.

Strange how people never say this with swift and objc

Re: C Is Best (2025)

#399

Post by kibwen »

fulafel wrote: post #318
craftkiller wrote: post #267

Earlier quoted context omitted.

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

Or in short: no, C is no better than Rust at gracefully recovering from stack overflow, either in theory or in practice.

Re: C Is Best (2025)

#400

Post by steveklabnik »

TZubiri wrote: post #379
onetoo wrote: post #282

Earlier quoted context omitted.

The equivalent in python-metaphor-land would be that python files clearly designate whether they are py2 or py3, and a single python interpreter can run both py2 and py3 scripts, as well as cross-include files of each version without issue. Rust editions only (and rarely!) break your code when you decide to upgrade your project's edition. Your public API stays the same as well (IIRC), so upgrading edition doesn't bre…

Hmm, couple of questions. what would be the difference with a binary that's has both a py2 and py3 interpreter and a flag --edition=2 or =3 redirects to either file? If I have Rust code from 2021, can I add a feature from 2024 and run it with --edition=2021 or 2024? Wouldn't adding a 2024 feature then possibly break the 2021 code? I think the fact that rust is compiled has a big impact in terms of bc for dependencies…

> what would be the difference with a binary that's has both a py2 and py3 interpreter and a flag --edition=2 or =3 redirects to either file?

The difference is that it's not the entire compiler. Rust's editions are only allowed to change the frontend. At the middle part of the compiler, it's all the same thing, and the differences are completely gone. This is the core of how the interop works, and it also means that you can't just change anything in an edition, only smaller things. But completely changing the language every few years wouldn't be good either, so it's fine in practice.

Post reply on HN