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

61–70 of 388 posts

Re: The case against a C alternative

#61

Post by cmeacham98 »

defen wrote: post #42
mustache_kimono wrote: post #34

Earlier quoted context omitted.

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?

> Yeah, writing software in the old language is more convenient because it's older than dirt. More chicken and egg nonsense. It's not impossible to have LLVM add additional targets, right? It seems like you're being needlessly hostile. There is nothing personal about this discussion, and it's not nonsense. I write embedded software that needs to run on PIC18 microcontrollers. Support for that in LLVM was dropped abou…

This conversation is about general use of C vs alternatives such as Rust.

If you can't use Rust because of your specific circumstances that's ok - use C! But don't use "my current circumstances prevent me from using Rust" as an argument as an argument against Rust in general - which is what you're doing.

Re: The case against a C alternative

#62

Post by cogman10 »

User23 wrote: post #45
cogman10 wrote: post #25

> C language toolchain I'm sorry, but the C language toolchain is not great. The only part of the C language toolchain that is good is it's platform support. Every platform has a C compiler. However, that's hardly something most devs will care about. At this point, we are pretty much all targeting Arm or x86 (Sorry PIC and MIPS devs). And every new language that's cropped up at a minimum supports both those platforms…

> I'm sorry, but the C language toolchain is not great. The only part of the C language toolchain that is good is it's platform support. Every platform has a C compiler. Please take a few days to review John Regehr’s excellent blog. I’m certain that you’ll find dispelling your ignorance rewarding. > How do you grab dependencies for and build javascript? npm install, npm build. Npm is the poster child for supply chain…

> Please take a few days to review John Regehr’s excellent blog.

Haven't heard of him but will certainly give a read. Thanks for the heads up.

> Npm is the poster child for supply chain attacks.

The only reason C doesn't (often) have similar supply chain attacks is because pulling in dependencies is so hard that you aren't likely to end up with a 10k dependency project.

Hard to say that's really a plus.

Other ecosystems have their own problems and certainly aren't perfect. However, the toolchains are generally leaps and bounds ahead of what C currently has.

Re: The case against a C alternative

#63

Post by TylerE »

lisper wrote: post #22
clysm wrote: post #13

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

And who says that faster runtime trumps all other considerations? I would much rather have my computer run slower than have to continuously deal with security vulnerabilities. My time is much more valuable than CPU time.

You're assuming that safety features will prevent security bugs. I think that is...optimistic at best.

Yes, they can defeat a few classes of exploits, but generally not the ones that lead to really bad outcomes.

Re: The case against a C alternative

#64

Post by msbarnett »

> The status of C as the lingua franca of today's computing makes it worthwhile to write tools for it, so there are many tools being written.

The vast, vast majority of programmers aren’t doing their computing by writing C anymore. It’s been the better part of 20 years since you could plausibly call it the Lingua Franca of computing.

Re: The case against a C alternative

#65

Post by speed_spread »

cogman10 wrote: post #25

> C language toolchain I'm sorry, but the C language toolchain is not great. The only part of the C language toolchain that is good is it's platform support. Every platform has a C compiler. However, that's hardly something most devs will care about. At this point, we are pretty much all targeting Arm or x86 (Sorry PIC and MIPS devs). And every new language that's cropped up at a minimum supports both those platforms…

> trying to write new code for IBM RPG servers

Hey, I know that! Challenge accep... Eeeeh, nevermind.

Re: The case against a C alternative

#66

Post by woodruffw »

zik wrote: post #31
imglorp wrote: post #16

Earlier quoted context omitted.

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

Valgrind's memcheck is great for exercising known paths in a program, and determining whether they're likely to contain memory errors. It doesn't help you discover those paths, which is what attackers are doing when they research and then exploit your program.

We've known for decades that compiler mitigations, fuzz testing, and dynamic instrumentation are excellent and necessary components of writing more secure C. But they don't secure C programs, because C itself is fundamentally unsafe.

> No, they're not static tools but being dynamic has a host of advantages too.

Advantages that any compiled binary can enjoy.

Re: The case against a C alternative

#67

Post by cmeacham98 »

jiggawatts wrote: post #60
woodruffw wrote: post #40

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

Not to mention that both C++ and Rust can specialise algorithms and containers for specific types, whereas in C most developers resort to void* and function pointers. It's not unusual to see C programs written in a "typical" C style become dramatically faster when rewritten in a more modern language. For example, typical C programs also don't use hashtables even when this makes the most sense, causing weird performan…

I totally agree with you, but are we really expecting "a typical PC" to have 10+ threads?

Re: The case against a C alternative

#68

Post by woodruffw »

jiggawatts wrote: post #60
woodruffw wrote: post #40

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

Not to mention that both C++ and Rust can specialise algorithms and containers for specific types, whereas in C most developers resort to void* and function pointers. It's not unusual to see C programs written in a "typical" C style become dramatically faster when rewritten in a more modern language. For example, typical C programs also don't use hashtables even when this makes the most sense, causing weird performan…

Precisely. This is perhaps the strangest part of the original post: C++ has the same performance advantages as Rust! It has them not because it's more safe (although it is, in some regards), but because it allows programmers to express behaviors that the compiler can reason about statically.

Re: The case against a C alternative

#69

Post by jollybean »

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…

C is used because it has to be used, i.e. low level environments etc. not because 'performance' most of the time.

If you could pay in performance a little bit, but have a clean, portable, beautiful debugger experience, nice libraries like 'Java' with a 'stable ABI' ... nobody would use C. We'd all use 'that new thing'. And we would just buy slightly faster hardware for the IoT whatever.

We use C++ smart pointers all over the place, and they come with a 'cost'. We mostly 'happily pay the price' because it's worth it most scenarios.

Engineers obsession with performance is a bit of a curse. Rarely do we really need that much. Kernel code, sure, IoT and remotely controlled toy cars, mostly not.

Re: The case against a C alternative

#70

Post by woodruffw »

cmeacham98 wrote: post #67
jiggawatts wrote: post #60

Earlier quoted context omitted.

Not to mention that both C++ and Rust can specialise algorithms and containers for specific types, whereas in C most developers resort to void* and function pointers. It's not unusual to see C programs written in a "typical" C style become dramatically faster when rewritten in a more modern language. For example, typical C programs also don't use hashtables even when this makes the most sense, causing weird performan…

I totally agree with you, but are we really expecting "a typical PC" to have 10+ threads?

Why not? I just opened htop on my desktop, and I have 789 threads running over 117 processes, with 12 logical cores.
Post reply on HN