The case against a C alternative • Hacker News Board

Re: The case against a C alternative

#11

Post by arcticbull » Mon, Aug 08, 2022, 11:56 PM UTC

habibur wrote: post #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 r…

While true, its lack of restrictions is also a hinderance in terms of performance. As pointers can overlap by default (unless you throw a __restrict on them), a whole class of optimizations cannot be performed. That's why Fortran and Rust can in theory beat C from a performance perspective even though they do more checking as a rule. That's just one example, but it's a pretty big one.

Re: The case against a C alternative

#12

Post by Bayart » Mon, Aug 08, 2022, 11:58 PM UTC

If anything, "replacing C" is a good excuse to stimulate creativity. The scope is known, the land well trodden. I like seeing new things in programming languages and OS design. I like nerds having fun and giving me interesting stuff to wrap my three neurons around in the process. That's why I love computing to begin with. Not increasing productivity, not disrupting who knows what. Just cool, smart shit.

Re: The case against a C alternative

#13

Post by clysm » Mon, Aug 08, 2022, 11:59 PM UTC

> any safety checks put into the competing language will have a runtime cost, which often is unacceptable.

And what is the runtime cost of all the mitigations put in place because we don't use a memory safe language? Stack canaries, safe stacks, ASLR, control flow integrity, code pointer integrity, runtime attestation, library re-linking and randomization. Not to mention sandboxing techniques and other system level mitigations.

I suppose I should thank the C language for job security as a security engineer.

Re: The case against a C alternative

#14

Post by AceJohnny2 » Tue, Aug 09, 2022, 12:00 AM UTC

arcticbull wrote: post #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 memo…

Yeah, I'm also confused by this.

A platform will define an ABI which, as I understand it, explains how parameters are passed to and returned from a "function", what types are supported and how they're encoded, at the processor register and stack level.

C, being the "portable assembler" [1] that it is, maps its types and functions pretty easily to that platform ABI, but I've been seeing a fair amount of confusion about that ABI being about C rather than any language that can link through that platform ABI. Couldn't it just as easily be called, I dunno, the Ada ABI?

[1] not really, except for the sake of this argument

Re: The case against a C alternative

#15

Post by mustache_kimono » Tue, Aug 09, 2022, 12:00 AM UTC

Wow, this blog entry's reasoning is a leaky ship.

1. C language toolchain -- No specifics (save static analyzers, ... because C needs static analyzers to catch C specific bugs...). What do you actually feel you're missing? Most of these "new C" languages use the same backend as a C compiler. What can't you use?

2., 3., and 4. -- Just chicken and egg FUD.

Not to mention it's "'Better X' doesn't matter" fundamentally doesn't understand the competition.

A sample quote: "That's not just one but eight(!) killer features (re: Java). How many of those unique selling points do the C alternatives have? Less than Java did at least!" WTF?! "But Java had 8!" is laughable.

Another: "[A]ny safety checks put into the competing language will have a runtime cost, which often is unacceptable". We can also produce a car without windows, doors or a chassis that will survive a crash, and it may be faster too. We may even get lucky and live to tell the tale.

Again: "Aside from Jai, is anyone C alternative really looking to pursue having killer features?" Aside from Jai?! Jai. Really? Oh, I remember you just discounted safety and correctness as killer features. ... But Jai. And nothing against Jai. But a language which hasn't been, which may never be, released to the general public. Just, eyes wide open, wow.

I hope this is the peak of anti-Rust/pro-C silliness, but I know it's not.

Re: The case against a C alternative

#16

Post by imglorp » Tue, Aug 09, 2022, 12:06 AM UTC

habibur wrote: post #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 r…

> any safety checks put into the competing language will have a runtime cost

How about all guarantees static analysis brings to data races, memory ownership, etc? No runtime cost. C tools do not bring this.

Re: The case against a C alternative

#17

Post by swatcoder » Tue, Aug 09, 2022, 12:06 AM UTC

habibur wrote: post #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 r…

I think the main point is that a good alternative C doesn't compete directly with C's strongest points.

Here, you can of course make a more safe language without runtime penalty just by supporting richer build-time/static checks, but the modest and meaningful gains you make within that constraint will never be enough to displace C.

You need to be providing something meaningfully more in areas where C hasn't already squeezed out most gains. The OP tastefully avoided making this article directly about C3, but if you go and look at the summary of features, you can see how this philosophy connects with what they're working to build.

Re: The case against a C alternative

#18

Post by yazzku » Tue, Aug 09, 2022, 12:07 AM UTC

mustache_kimono wrote: post #15

Wow, this blog entry's reasoning is a leaky ship. 1. C language toolchain -- No specifics (save static analyzers, ... because C needs static analyzers to catch C specific bugs...). What do you actually feel you're missing? Most of these "new C" languages use the same backend as a C compiler. What can't you use? 2., 3., and 4. -- Just chicken and egg FUD. Not to mention it's "'Better X' doesn't matter" fundamentally d…

I think what he's saying for (1) is that the toolchain is good compared to other languages (lots of existing tools.)

I don't know why you say 2-4 is FUD.

Re: The case against a C alternative

#19

Post by defen » Tue, Aug 09, 2022, 12:07 AM UTC

mustache_kimono wrote: post #15

Wow, this blog entry's reasoning is a leaky ship. 1. C language toolchain -- No specifics (save static analyzers, ... because C needs static analyzers to catch C specific bugs...). What do you actually feel you're missing? Most of these "new C" languages use the same backend as a C compiler. What can't you use? 2., 3., and 4. -- Just chicken and egg FUD. Not to mention it's "'Better X' doesn't matter" fundamentally d…

> What do you actually feel you're missing?

It explicitly says in the post... for example static analyzers. What is the "Frama-C" equivalent of any language that bills itself as a replacement / competitor of C?

> Most of these "new C" languages use the same backend as a C compiler.

Most of them use LLVM as far as I know, which does not target plenty of obscure platforms.

Re: The case against a C alternative

#20

Post by nkurz » Tue, Aug 09, 2022, 12:08 AM UTC

> And worse, what if the language omits crucial features that are present in C? Features that C advanced programmers rely on?

Seems like this might be a good place to ask: which of the C replacement languages mentioned (or not mentioned) support inline assembly? Do any of them do it better than GCC/Clang? For me, I feel like the ability to drop to assembly in a pinch is a necessary feature. I'm sure I could technically get by linking an external file, but I'd be more interested in a language with inline ASM support than one that doesn't allow it. Thanks!