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

151–160 of 388 posts

Re: The case against a C alternative

#151

Post by pjmlp »

GuB-42 wrote: post #125
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 don't know Rust but I know C++. And C++ has the potential to be faster than C, mostly thanks to metaprogramming (templates, ...). It is horrible if you have to do it, but if you are just using the standard library, you don't have to feel the pain but still take advantage of it. That's how algorithms are implemented. Because so much is known at compile time, optimizers can do a lot. The reason C++ is generally regar…

As of C++17 not so horrible, and C++2x versions even less so, unless one has some strange fetisch for SFINAE and tag dispatch.

Since 1993, I never saw any need to keep bothering with C other than having it imposed on me, C++ had enough C89 subset on it, if I ever miss coding like C and its warts.

Nowadays that compatibility is up to C11 subset.

Re: The case against a C alternative

#152

Post by pjmlp »

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 the latest trend, producing C Machines with hardware memory tagging, because none of those mitigations are actually working preventing all those CVE to take place.

Re: The case against a C alternative

#153

Post by pjmlp »

mcpherrinm wrote: post #75
TylerE wrote: post #63

Earlier quoted context omitted.

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.

> The Chromium project finds that around 70% of our serious security bugs are memory safety problems. > ~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues Memory safety is a leading source of serious bugs in a big group of operating systems, browsers, image and file parsers, and more. It does seem likely we can stop this, and it doesn’t seem likely to me we can fix it in…

Solaris SPARC is the first that has suceeded at it, and now others follow it, how?

Hardware memory tagging, the language itself is beyond hope.

Re: The case against a C alternative

#154

Post by pjmlp »

dist1ll wrote: post #83
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…

This is why I hope unikernels & Rust will eventually replace docker & linux for high-performance, high-security production deployments.

You already see this in PaaS and serverless for managed runtimes, I don't care if my Java and .NET code runs on bare metal, micro-kernel, unikernel, or whatever.

Re: The case against a C alternative

#155

Post by pjmlp »

ducktective wrote: post #143
cogman10 wrote: post #62

Earlier quoted context omitted.

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

>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. Or the lack of canonical package manager means the developer has to actually spend time to inspect the quality of each dependency instead of `npm install is-odd`ing like there is no tomorrow. It also acts as a "filter" to prevent adding comp…

They will do `apt-get install is-odd` instead, or yum, pacman, or...

Re: The case against a C alternative

#156

Post by BenFrantzDale »

jimbob45 wrote: post #131
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…

What did you mean when you said C hashtables can’t be generic? Is the (void*) not an adequate solution?

Using void* means the compiler (almost certainly?) can’t see through it to optimize. More importantly, it looses you type safety and the self-documentation that flat_hash_map gives you.

Re: The case against a C alternative

#157

Post by jiggawatts »

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?

My laptop has 8 cores and 16 threads.

I'm about to buy a PC with 16 cores and 32 threads for "normal" money.

The AMD EPYC server CPUs scale to dual sockets with 64-cores each, for a whopping 256 hardware threads in a single box. That's not some sort of esoteric hyper-scale configuration, but completely ordinary off-the-shelf stuff you can get in large quantities from mainstream vendors.

A single-threaded application on a server like that will use between 0.5% to about 50% of the total available performance, depending on where its bottleneck is. It will never reach 100%!

This matters to things like CLI tools, batch jobs, and the like, many of which are written in C, especially in the Linux world. A case-in-point that demonstrates how much performance has been left on the table is ripgrep, which is a multi-threaded Rust replacement for grep.

Re: The case against a C alternative

#158

Post by zozbot234 »

chaeronanaut wrote: post #56
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…

this pretty much summarises my opinion - one nitpick - i assume you meant " omit bounds and other checks", not "emit bounds and other checks" which seems to mean the opposite of what you're intending

Rust does emit bounds and other checks, though. Optimization passes can usually clear some of them away, but you'd need to check the assembly output to be sure.

Re: The case against a C alternative

#159

Post by zozbot234 »

elihu wrote: post #141
dist1ll wrote: post #83

Earlier quoted context omitted.

This is why I hope unikernels & Rust will eventually replace docker & linux for high-performance, high-security production deployments.

I agree. I think of address space context switching overhead as the performance price we pay for not being able to run all our programs in a single address space, which we could safely do if we knew all the programs were emitted by a trusted compiler that disallows unsafe memory access. Imagine if system calls were just ordinary functions that can be called with no more than the normal function call overhead? What if…

> I think of address space context switching overhead as the performance price we pay for not being able to run all our programs in a single address space, which we could safely do if we knew all the programs were emitted by a trusted compiler that disallows unsafe memory access. Imagine if system calls were just ordinary functions that can be called with no more than the normal function call overhead?

That's pretty much how the Amiga worked, and that level of technology achievement is still unsurpassed today.

Re: The case against a C alternative

#160

Post by nicoburns »

FpUser wrote: post #84
nicoburns wrote: post #7

Earlier quoted context omitted.

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…

And I wrote a firmware in C for 4-quadrant torque control in about the same time. I do not have any formal proof on how buggy/or not it is but the thing runs properly for 10 years already. If that is not "production code" I do not know what is. I am not inexperienced programmer. Rather quite opposite. But this was after I did not touch C and any microcontrollers for like 10 years.

I feel like C is somewhat manageable on microcontrollers. Programs tend to be smaller (micro!), you can often do static allocation which mitigates a lot of the memory management issues, and you're also often dealing with simple types and bit manipulation which is where C shines.

In larger programs on full-fat operating systems, programs tend to be much larger (esp. if you include libraries - dealing with libraries being one of the most complex things in C), and you have to deal with sophisticated allocation patterns, and complex types (webs of pointers), abstractions and business logic which is where C basically leaves you on your own and provides very little in terms of structure or guard rails.

Post reply on HN