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

511–520 of 574 posts

Re: C Is Best (2025)

#511

Post by lelanthran »

zabzonk wrote: post #449
lelanthran wrote: post #262

Earlier quoted context omitted.

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

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

That's fair, but malloc is certainly non-idiomatic, isn't it?

Re: C Is Best (2025)

#512

Post by fclairamb »

thesz wrote: post #404
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…

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

Re: C Is Best (2025)

#513

Post by 112233 »

pjmlp wrote: post #510
112233 wrote: post #509

Earlier quoted context omitted.

> standard library isn't a requirement for each executable. So you also agree that C++ libraries are a bad fit for embedded? Because in the video you linked, that person did not use any libraries. It is one thing to compile small standalone binary, using non-conforming compiler extensions to disable rtti and exceptions. It is another to write C++ library. By standard, even freestanding C++ requires RTTI, exceptions a…

Just like C libraries are a bad fit for embedded, no difference there, although C++ haters pretend otherwise, even though half of libc is unusable in freestanding. It takes skill to make use of Arduino, ESP32, and other C++ embedded libraries, being able to write custom C++ libraries, master compiler switches and linker maps.

C libraries are excellent for embedded! You can write libraries like SQLite, that can run on bare metal and only require a few external functions from the platform, while still being valid C library!

You cannot make it in C++, because any valid C++ library imposes massive requirements on the environment I already mentioned. C does no such thing!

Re: C Is Best (2025)

#514

Post by throwaway81523 »

1. This isn't a 2025 article, it's much older but it received some updates in 2025.

2. Ada is about as old as C so should have been considered as a possible safe language. It's safer than Rust in my opinion. GNAT was released in 1995 while SQLite is from 2000, so it was a possibility. C++ was also around: still unsafe, though less so than C.

Re: C Is Best (2025)

#515

Post by lenkite »

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…

Java has features that Kotlin does not have. Virtual Threads and the API's that support then are effectively incompatible with the Kotlin co-routine libraries.

Re: C Is Best (2025)

#516

Post by paul_ch »

sylware wrote: post #299
kitd wrote: post #12

Earlier quoted context omitted.

That's the first time I've heard the C syntax being called "too rich". It's the epitome of succinctness IMHO (too a fault, even, or maybe I'm just old). Are you confusing it with C++? If so, you have a point.

I am talking about C syntax, not absurdely grotesque ultra-complex syntax like the ones from c++, java and similar (is that true that rust syntax is not that much less worse than c++ one now?). We need a new C, fixed, leaner and less complex: primitives are all sized (u64, u8, f64, etc), only one loop primitive (loop{}), no switch, no enum, no typedef, no typeof and other c11 _generic/etc, no integer promotion, no im…

New C is old B? https://en.wikipedia.org/wiki/B_(programming_language) I implemented some examples using B language. I like its typeless and simplicity. It would be nice if there was a modern and mature implementation of this language, it's a true portable assembler.

Re: C Is Best (2025)

#517

Post by paulf38 »

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…

OOP is pretty much has-been.

Value semantics is the hot thing now I'd say.

Re: C Is Best (2025)

#518

Post by paulf38 »

lelanthran wrote: post #220
koakuma-chan wrote: post #178

Earlier quoted context omitted.

I know one C++ library that caches data but never evicts. Instead, the library author expects you to restart your app every 24 hours.

> I know one C++ library that caches data but never evicts. Instead, the library author expects you to restart your app every 24 hours. It may not be as simple as "that's our policy". I worked at one place (embedded C++ code, 2018) that simply reset the device every 24h because they never managed to track down all the leaks. Finding memory leaks in C++ is a non-trivial and time-consuming task. It gets easier if your…

In my experience that is usually the result of years and years of accumulation of shit code. The results is thousands of leaks. That makes detection of incremental leaks much more difficult. If you start with clean code and use ASAN or Valgrind then leak detection is not difficult.

Re: C Is Best (2025)

#519

Post by lelanthran »

williamoforange wrote: post #507
lelanthran wrote: post #220

Earlier quoted context omitted.

> I know one C++ library that caches data but never evicts. Instead, the library author expects you to restart your app every 24 hours. It may not be as simple as "that's our policy". I worked at one place (embedded C++ code, 2018) that simply reset the device every 24h because they never managed to track down all the leaks. Finding memory leaks in C++ is a non-trivial and time-consuming task. It gets easier if your…

Use Valgrind? Or are we talking projects that have become far too big for their own good, cause leaks aren't hard at all to find with the right tools and a bit of profiling... now crossing thread boundaries and weird dynamic programming tricks maybe, but thats a very different case and not really refecting on C++ itself, would likely trip up a GC lang as well.

> Use Valgrind?

Was not available for that specific device, but even with Valgrind and similar tools, you are still going to run into weird destructor issues with inheritance.

There are many possible combinations of virtual, non-virtual, base-class, derived-class, constructors and destructors; some of them will indeed cause a memory leak, and are allowed to by the standard.

Re: C Is Best (2025)

#520

Post by IshKebab »

uecker wrote: post #504
IshKebab wrote: post #460

Earlier quoted context omitted.

Nobody is marketing it. It doesn't have a marketing budget. What you're seeing are lots of people that really like it because it's really good. Not flawless obviously but a significant improvement on C and C++.

I see a lot of activity of very specific parts of the industry promoting it. But also enthusiasts doing aggressive marketing are doing aggressive marketing - even if they do not have a budget. Whether it is an improvement is debatable. From my perspective, it is an improvement in some aspects and a significant step back in others. What is unacceptable though is the significant hate and pressure towards people who hav…

> Whether it is an improvement is debatable.

Not really.

> it is an improvement in some aspects and a significant step back in others

Of course. Very few improvements are better in every way. There's always something you can find to like about the old solution. Horses are friendlier than cars. Records allow bigger artwork than CDs. Unlike DVDs (at first anyway) you can write to VHS. Unlike Typescript, Javascript doesn't need a compile step. FORTRAN77 fits nicely on punch cards.

That doesn't mean there's really any serious debate about them being improvements.

I will freely admit that Rust has only average compile time (though it's better than C++ at this point), high complexity, and async Rust is full of footguns. But I could come up with a much longer list of complaints for C.

> we must stamp out memory safety issues at all cost and Rust is the solution

Yeah I think memory safety is actually probably not the most important thing about Rust. Having a modern strong type system is arguably more significant. Memory safety is important too of course - even if you don't care about security memory safety issues are often plain hard to debug bugs.

Post reply on HN