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

441–450 of 574 posts

Re: C Is Best (2025)

#441

Post by kibwen »

usefulcat wrote: post #156
muvlon wrote: post #66

Earlier quoted context omitted.

> old code gets automatically compiled by the old version of the compile That's not what happens. You always use the same version of the compiler. It's just that the newer compiler version also knows several older dialects (known as editions) of the language.

And it remains to be seen how well this approach will work as time passes and the number of versions continues to increase.

That won't be any more of a problem than the support that every existing C or C++ compiler has for targeting different versions of the standard.

Re: C Is Best (2025)

#442

Post by arroquw »

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…

Actually, GO is ported to microcontrollers with Tinygo. Even u-root works on microcontrollers nowadays.

For the more bulky processors, there's also tamago.

Re: C Is Best (2025)

#443

Post by gf000 »

coffeemug wrote: post #362
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…

Not always, but sometimes, new things are just better. One example is null-- a billion dollar mistake as Tony Hoare called it. A Maybe type with exhaustive pattern matching is so dramatically better, it can be worth switching just for that feature alone.

This "new" thing could have grandkids now :D

ML is not some new development, it just took this long to get some of its ideas mainstream.

Re: C Is Best (2025)

#444

Post by vips7L »

orthoxerox wrote: post #393
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.

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.

I did a decent amount of AoC this year in F#. I felt it was more verbose than I would have expected. There were a lot of things that helped brevity; I really liked type definitions, unless I was using OO features where it was extremely verbose to define members. I also really didn't like having to to Seq.map or List.filter for everything instead of just calling methods off of the seq or list.

Re: C Is Best (2025)

#445

Post by koakuma-chan »

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

Earlier quoted context omitted.

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

Well if you've hit OOM, you're kinda screwed anyways. But, if you allocate a ring buffer at the beginning, you can always do a best attempt write.

Why screwed? It could just be that there is more load than your application can handle. Why should it necessarily crash because of that?

Re: C Is Best (2025)

#446

Post by riku_iki »

Svoka wrote: post #287
hbbio wrote: post #5

Makes a lot of sense for SQLite to be written in C. It's a heavily optimized and debugged database implementation: Just look at btree.c with all its gotos :) The only language that would make sense for a partial/progressive migration is zig, in huge part due to its compatibility with C. It's not mentioned in the article though.

What would be a reason to bring Zig in? For example, Rust has additional memory guarantees when compared to C.

Zig has better ergonomics over C but not as complex as Rust.

Re: C Is Best (2025)

#447

Post by tialaramex »

bobbylarrybobby wrote: post #301
vlovich123 wrote: post #265

Earlier quoted context omitted.

No you’re misunderstanding the ecosystem. Rust 2024 code can call 2021 code without issue (and vice versa I think although could be wrong on the vice versa). So you can progressively update code of individual components as you want or not at all and still continue using it just fine in new code using later editions. Thats the very definition of back compat, something you really really shouldn’t do with C++ (every fil…

As long as the compiler is new enough to handle 2024 code (i.e., you're not using a 2021 version of the compiler itself), 2021 code can use 2024 code.

Right. A good mental model would be to imagine every crate of Rust source has an associated Edition and there's a sort of "pre-processing" step where we translate that into the latest version of Rust seamlessly, preserving its exact meaning.

So e.g. 2018 Edition said r# at the start of an identifier now marks a "raw" identifier. Keywords promise never to start this way, so r#foo is the same as foo but r#foo even works if some lunatic makes foo a keyword whereas just foo would become a keyword if that happened. As a result if you write

   let async = 5;
... in Rust 1.0 that translator treats it exactly as though you'd written

   let r#async = 5;
... in a modern Rust edition because these days the keyword async exists.

Re: C Is Best (2025)

#448

Post by locknitpicker »

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…

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

The "long history of safety issues" is actually a combination of being extremely successful (the world runs on C and C++) and production software always featuring bugs.

The moment Rust started to gain some traction, we immediately started seeing CVEs originating from Rust code.

Re: C Is Best (2025)

#449

Post by zabzonk »

lelanthran wrote: post #262
zabzonk wrote: post #229

Earlier quoted context omitted.

how exactly do you think C and C++ differ here?

> how exactly do you think C and C++ differ here? `new` throws, `malloc` returns. That's a pretty big difference! Idiomatic C++ code never puts a `try` around `new`, while idiomatic C code always checks the return from an allocation.

Well: https://en.cppreference.com/w/cpp/memory/new/nothrow.html

I thought you were talking about the use of malloc in both languages - you never mentioned new in your first post. and i think we have different views on what is "idiomatic" in the languages.

Re: C Is Best (2025)

#450

Post by locknitpicker »

arghwhat wrote: post #359
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 don't agree. First of all, Java isn't a platform. Kotlin and Java are both just languages, and Kotlin has explicit interoperability with Java exactly to make it easy for Java devs to "upgrade". The JVM is a common target for both Java and Kotlin, where the two are intentionally interoperable - from the Kotlin-side, by virtue of explicit annotation. Both languages have other targets through other compilers, e.g., Ko…

> First of all, Java isn't a platform.

You are being facetious. I mean, do you actually believe that the JVM exists in a context where Java does not exist? What does the J in JVM stand for?

> The JVM is a common target for both Java and Kotlin, where the two are intentionally interoperable (...)

Yes, in the sense that Java exists and Kotlin by design piggybacks on the JVM.

> The C → Rust migrations that happen a lot these days underline how differences in features isn't at all a problem (quite the opposite when there's new features), but that interoperability allowing partial work is by far the most important thing.

This analysis is very superficial and fails to identify any of the real world arguments to switch from C. For example, Microsoft outright strangled C by wasting many years refusing to support any standard beyond C89, in spite of being directly involved in it's drafts. This was a major contribution to address any of the pain points and DX shortcomings. Compare the evolution of C and C++ during that time period, and we see C++ going through the same path in the C++0x days to then recover spectacularly once C++11 got unstuck.

Post reply on HN