Live data from Hacker News

The case against a C alternative

c3.handmade.network

1–10 of 388 posts

Re: The case against a C alternative

#4
(5) is pretty irrelevant, ABI isn't language.

You can strap basically any language on top of the C ABI. Many contender languages either use it natively or offer low-cost/no-cost C ABI bindings, specifically as its the lingua franca ABI.

You can check (5) off your list if your choice of replacement language has easy C ABI interop.

[edit]

(1) isn't particularly relevant either. These days the tooling for detecting memory leaks, data races, bugs, etc, operates at the debug info (DAWRF/dSYM) level. It doesn't matter what compiler or input language generated the debugging information, the tools should work just fine. You can run valgrind on your Rust binary for instance. [1] Is there any such tooling that specifically depends on the input source being C? I guess some static analysis tools?

[1] https://nnethercote.github.io/2022/01/05/rust-and-valgrind.h...

Re: The case against a C alternative

#6
the only better c that will count is if c add some features that are critical like a standard library that is more powerful i know c++ 17 have some improvements but need alternatives for most things is not good for the ecosystem, and the old only if you want, is 2022 most embedded system use this tools, we need c to have a reasonable standard library, the whole world depend on it.

Re: The case against a C alternative

#7

(4) is extremely important. Labor pool is smaller and there won't be a wealth of soft documentation and people that can provide immediate support for common questions.

It is, on the other hand it's a lot of easier to write correct code in, well, almost every language other than C.

To give a concrete example, I was able to write production-ready code with 2 weeks of Rust experience and nobody to provide support for questions (beyond reading StackOverflow), and that code was more reliable and less buggy then the Python/JavaScript code our company was otherwise writing, even though we were collectively much more experienced in those stacks. I doubt we'd have gotten that with C, even though we had a bunch of developers who were experienced with C.

Re: The case against a C alternative

#9
Ive been thinking about this topic for years and OP was finally able to put it in writing. I dont think anyone would claim english is the best, but it just so happens that the most powerful empire on earth (until recently?) uses it as its primary language. Its good enough at what it does, and has a lot of history backing it up

With this knowledge I choose to align myself with languages and platforms that respect C and complement it (Lua, Objective-C, etc) instead of languages and platforms that try to supplant it (c++, java, swift, rust, etc)

Re: The case against a C alternative

#10
"Any C alternative will be expected to be on par with C in performance. The problem is that C have practically no checks, so any safety checks put into the competing language will have a runtime cost, which often is unacceptable. This leads to a strategy of only having checks in "safe" mode. Where the "fast" mode is just as "unsafe" as C."

This one is the main point. Highest possible speed while consuming as little resource as possible. Put in checks, and most of those checks will run redundantly compromising performance.

Post reply on HN