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

551–560 of 574 posts

Re: C Is Best (2025)

#551

Post by simon_void »

lenkite wrote: post #515
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…

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.

technically, Kotlin can use VirtualThreads like it can use any other Java Api (when being compiled to JVM bytecode).[1] If I remember correctly the Kotlin team was e.g. thinking about implementing a Coroutine Dispatcher with VirtualThreads. So building a Kotlin service that uses Virtual Threads instead of coroutines is -in principle- possible. But if you've got a Java project using Virtual Threads you could rewrite it slowly -class for class- to Kotlin (and later probably refactor the VirtualThreads to coroutines). What you have to keep in mind though: if you're creating a Kotlin lib that is meant to be used by Java then the public Api of this lib should include suspend functions! My company made that mistake at some point, they ordered a lib from an external supplier and since Java and Kotlin are both first class languages and "Kotlin is compatible with Java", they ordered this lib in Kotlin. They learned the hard way that Kotlin suspend methods translate to Java methods returning a Continuation class (!? If I remember correctly. I wasn't part of that project, but heard their story) which is very unergonomic to use manually. The fix was to write a small Kotlin shim lib that wrapped the other lib and replaced every suspend function with a normal function invoking their suspend counterpart in a runBlocking-block (I think). Hardly ideal, but workable. So yes, writing a Kotlin lib that's (also) meant to be consumed from Java requires more thought than one that is only meant to be used by Kotlin. (There is functionality in Kotlin to help with this though, e.g. look up the annotations @JvmStatic, @JvmName, @JvmRecord.)

[1] https://void2unit.onrender.com/post/virtualthreads-in-kotlin...

Re: C Is Best (2025)

#552

Post by paulf38 »

lelanthran wrote: post #519
williamoforange wrote: post #507

Earlier quoted context omitted.

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.

> even with Valgrind and similar tools, you are still going to run into weird destructor issues with inheritance.

I love these folklore comments. Post an example.

Re: C Is Best (2025)

#553

Post by sylware »

alexpadula wrote: post #11
sylware wrote: post #4

WRONG! Plain and simple C is, by far, one of the current _LESS WORSE_ performant alternatives which can be used, actually, from low level to large applications. C syntax is already waaaaay to rich and complex (and ISO is a bit too much pushing feature creep over 5/10 years cycles).

Interesting! Let’s start this debate! I love C, when I wrote my first programs in it as a teenager, I loved the simplicity, I love procedural code. Large languages like C++ and or Rust are just too much for ME. Too much package. I like writing code in a simple way, if I can do that with a small amount of tools, I will. You can learn C and be efficient in it within a couple weeks. C systems are just built better, fast…

It is a complex matter. But it narrows down to one thing: the number of real-life alternative compilers, which is in direct relation to this benchmark: can a small team of average devs, or an individual average dev, develop with reasonable effort and time and near 0 technical dependence, a real-life alternative of a compiler. It is a protection of developer/vendor lock-in, in the SDK realm.

Most honnest software developers know the answer: for any computer language with an ultra-complex syntax(c++,etc) or which requires an intrusive and tricky runtime (java,etc), the answer is obvsiously "nope". But we all know, for plain and simple C, the answer is "yes" (have a look at cproc and QBE, or scc, tinycc, etc). The new C I am talking about should reduce the effort related to such compiler developement and "fix" all C implicit stuff hiding too much things, kind of error prone.

There is a huge pitfall though: linux is not coded in plain and simple C, but in GCC C... which is VERY different, a GCC C alternative, is clancg/llvm, those are not to be called reasonable in any capacity.

If linux code would care about having clean assembly source files on top of plain and simple C code, unfortunately it would be slower. BUT, you guess what, for the ability to compile linux with an _REAL ALTERNATIVE_ C compiler (and a small assembler), I will happily accept to have a "slower" kernel.

Re: C Is Best (2025)

#554

Post by torstenvl »

titzer wrote: post #125
runjake wrote: post #116

Earlier quoted context omitted.

Context: Along with the never ending pressure to migrate a project to new shiny, there is a lot of momentum against C and other memory-unsafe languages. The US government recently called on everyone to stop using them and move to memory-safe languages. Regardless, there are practices and tools that significantly help produce safe C code and I feel like more effort should be spent teaching C programmers those. Edit: T…

C was my first language, more than thirty years ago. I've heard (and probably myself made) the same arguments over and over and over. But those arguments are lame and wrong. C cannot be made safe (at scale). It's like asbestos. In fact, C is a hazardous material in exactly the same way as asbestos. Naturally occurring, but over industrialized and deployed far too widely before its dangers were known. Still has its us…

HN is not for flamebait.

Re: C Is Best (2025)

#555

Post by torstenvl »

wewtyflakes wrote: post #417
lelanthran wrote: post #235

Earlier quoted context omitted.

> When C code is run in machines capable of failing with gruesome death, its unsafeness may indeed result in gruesome death. And yet, it never does. It's been powering those types of machines likely longer than you have been alive, and the one exception I can think of where lives were lost, the experts found that the development process was at fault, not the language. If it was as bad as you make out, we'd have many…

https://en.wikipedia.org/wiki/Therac-25#Root_causes

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

Re: C Is Best (2025)

#556

Post by wewtyflakes »

torstenvl wrote: post #555
wewtyflakes wrote: post #417

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Therac-25#Root_causes

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!). Though, even allowing the "well ackuacally" cop-out argument, it is trivial to find examples of code in C causing failures due to out-of-bounds usage of memory; these bugs are found constantly (and reported here, on HN!). Now, you would need to argue, "well _none_ of those programs are used in life-saving tech" or "well _none_ of those failures would, could, or did cause injury", to which I call shenanigans. The link drop was meant to do just that.

Re: C Is Best (2025)

#557

Post by uecker »

IshKebab wrote: post #520
uecker wrote: post #504

Earlier quoted context omitted.

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

I program C a lot and I do not have to spent any noticeable time on debugging memory issues. I think all these arguments are essentially a strawman based on a very bad worst-case old-style C code - ignoring useful tooling and modern style can change the picture a lot.

Re: C Is Best (2025)

#558

Post by nilslindemann »

dwdz wrote: post #523
nilslindemann wrote: post #289

Earlier quoted context omitted.

Off topic: This CSS improves the usability of that page: ul.threadlist li:hover > a { color: red; } ul.threadlist li.origin > a { display: block; background: rgb(205, 216, 216); font-weight: normal; padding: 1px 6px; margin: 1px -6px; }

Should be: ul.threadlist li.origin a { display: block; background: rgb(205, 216, 216); font-weight: normal; padding: 1px 6px; margin: 1px -6px; }

Good point.

Re: C Is Best (2025)

#559

Post by Ygg2 »

josephg wrote: post #361
Ygg2 wrote: post #320

Earlier quoted context omitted.

> This is a fundamental limitation Not really. Yeah you need to reach into unsafe to make a doubly linked list that passes borrow checker. Guess what. You need unsafe implementation to print to console. Doesn't mean printing out is unsafe in Rust. That's the whole point of safe abstraction.

I love rust, but C does make it a lot easier to make certain kinds of container types. Eg, intrusive lists are trivial in C but very awkward in rust. Even if you use unsafe, rust’s noalias requirement can make a lot of code much harder to implement correctly. I’ve concluded for myself (after a writing a lot of code and a lot of soul searching) that the best way to implement certain data structures is quite different…

> I love rust, but C does make it a lot easier to make certain kinds of container types.

Ok. But making it easier or harder isn't the same as making it impossible.

To quote GP:

> 2) I believe the problem was related to the fact that Rust can't implement a doubly-linked list in safe code.

Rust can implement doubly linked list in safe code. It can. It wraps the unsafe parts in an abstract manner.

Re: C Is Best (2025)

#560

Post by josephg »

Ygg2 wrote: post #559
josephg wrote: post #361

Earlier quoted context omitted.

I love rust, but C does make it a lot easier to make certain kinds of container types. Eg, intrusive lists are trivial in C but very awkward in rust. Even if you use unsafe, rust’s noalias requirement can make a lot of code much harder to implement correctly. I’ve concluded for myself (after a writing a lot of code and a lot of soul searching) that the best way to implement certain data structures is quite different…

> I love rust, but C does make it a lot easier to make certain kinds of container types. Ok. But making it easier or harder isn't the same as making it impossible. To quote GP: > 2) I believe the problem was related to the fact that Rust can't implement a doubly-linked list in safe code. Rust can implement doubly linked list in safe code. It can. It wraps the unsafe parts in an abstract manner.

> Rust can implement doubly linked list in safe code. It can. It wraps the unsafe parts in an abstract manner.

As far as I know, only with Rc / RefCell. But that has a significant performance cost.

Am I wrong? I'd love to see an example / benchmarks.

Post reply on HN