Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The case against a C alternative

c3.handmade.network

Post reply on HN
Print view View original

31–40 of 388 posts

Re: The case against a C alternative

#31

Post by zik »

imglorp wrote: post #16
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.

The valgrind suite is a very effective answer to these needs and it's used by most C programmers. Helgrind for data races. Memcheck for memory ownership. Not to mention sophisticated tools for cache profiling, call graph analysis and heap profiling. No, they're not static tools but being dynamic has a host of advantages too.

Re: The case against a C alternative

#32

Post by bee_rider »

woodruffw wrote: post #26
bee_rider wrote: post #24

Earlier quoted context omitted.

You are the security engineer, so you certainly know better than me, but aren't those runtime mitigations aimed at malicious programs? Which is to say, even if a better-C was written that didn't allow people to write a program that would bump into those mitigations, the bad guys could still write their programs in assembly or C or whatever, right?

They're aimed at protecting innocent programs from exploitation. If we knew which programs were actually malicious, our lives would be much easier!

But the presence of a better language to write innocent programs in wouldn't protect the innocent programs from malicious programs written in C and assembly...

Re: The case against a C alternative

#33

Post by gregoryc_ »

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

Check out https://cboard.cprogramming.com/c-programming/181160-hi-i-ha...

I posted this less than 24 hours ago.

This might be what you want, and there's no overhead at all.

It might actually speed up your code. 15x faster regex

I just made this. I'm looking for contributors :)

Re: The case against a C alternative

#34

Post by mustache_kimono »

defen wrote: post #19
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.

So the argument is we need the bug finders we've developed for C (because our C is full of bugs)?

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

Yeah, writing software in the old language is more convenient on obscure, rare, niche platforms, because it's older than dirt. More chicken and egg nonsense. It's not impossible to have LLVM add additional targets, right?

Re: The case against a C alternative

#35

Post by AceJohnny2 »

AceJohnny2 wrote: post #30

> 3. Programmer productivity > [...] Why? Because the actual programming is not the main time sink. In a business, what takes time is to actually figure out what the task really is. So something like a 10% or 20% "productivity boost" won't even register. This reminds me of Amdahl's Law [1], about how a performance optimization (parallelism) has small returns because the performance improvement only affects a small po…

Counterpoint is that a language that allows rapid iteration/prototyping (and thus, increases "programmer productivity") is useful precisely because it helps figuring out what the task really is.

Re: The case against a C alternative

#36

Post by yazzku »

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…

Why is this down-voted? C does not have a standard ABI, this guy here is right?

Re: The case against a C alternative

#37

Post by cogman10 »

nkurz wrote: post #20

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

Pretty much all of them at this point.

Rust: https://doc.rust-lang.org/nightly/reference/inline-assembly....

D: https://dlang.org/spec/iasm.html

Ada: https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ug...

Cobol: https://www.ibm.com/docs/en/cobol-zos/6.2?topic=appendixes-a...

Pascal: https://wiki.freepascal.org/Asm

Python: https://pypi.org/project/il/

You can almost name a language and find a route to inline assembly :D

Re: The case against a C alternative

#38

Post by gregoryc_ »

The simplest solution is a preprocessor. The original founders of C made one, probably because they needed it. But adding another lightweight one is simple. C++ has bloat. Compilation time can be slow.

I realize that this is radical, but if people could work with me on this, this could solve all your problems, no really, it could solve all your problems. And if it can't solve all your problems yet, then modify it to

https://cboard.cprogramming.com/c-programming/181160-hi-i-ha...

There is no need for another language. Just use this

Gregory

Re: The case against a C alternative

#39

Post by sanxiyn »

arcticbull wrote: post #11
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.

"We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine."

-- Fran Allen, from Coders at Work

Re: The case against a C alternative

#40

Post by woodruffw »

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

I don't think this is true, in the general case: Rust has shown that languages can be safe in ways that improve runtime performance.

In particular, languages like Rust allow programmers to express stronger compile-time constraints on runtime behavior, meaning that the compiler can safely omit bounds and other checks that an ordinary C program would require for safety. Similarly, Rust's (lack of) mutable aliasing opens up entire classes of optimizations that are extremely difficult on C programs (to the extent that Rust regularly exposes bugs in LLVM's alias analysis, due to a lack of exercise on C/C++ inputs).

Edit: Other examples include ergonomic static dispatch (Rust makes things like `foo: impl Trait` look dynamic, but they're really static under the hood) and the entire notion of a "zero-cost abstraction" (Rust's abstractions are no worse than their "as if" equivalent, meaning that the programmer is restricted in their ability to create suboptimal implementations).

Post reply on HN