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

81–90 of 388 posts

Re: The case against a C alternative

#81

Post by nickysielicki »

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?

If not today, definitely tomorrow.

Re: The case against a C alternative

#82

Post by quickthrower2 »

ryandrake wrote: post #54
lisper wrote: post #22

Earlier quoted context omitted.

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.

> 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. To be devil’s advocate and take the other side of this argument: I would rather the CPU I paid for spend its cycles performing actual application logic. Every cycle spent executing all this “safety code” overhead feels like me having to pay for a developer’s slop…

Is Rust slower then C in general though? And how much are you paying? Probably in true terms it costs less if there are fewer bugs and vulns.

Re: The case against a C alternative

#83

Post by dist1ll »

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.

Re: The case against a C alternative

#84

Post by FpUser »

nicoburns wrote: post #7
TAForObvReasons wrote: post #3

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

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.

Re: The case against a C alternative

#85

Post by carey »

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

All the modern AS/400 servers can run unmodified AIX programs these days anyway.

Re: The case against a C alternative

#86

Post by sitkack »

elcomet wrote: post #49
lisper wrote: post #22

Earlier quoted context omitted.

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.

That's not the point. The point the parent is making is that yes, languages that include safety features are slower, but you will actually need those safety features in C as well, in the code. So your program will also be slower in C.

What does slower actually mean? Slower in the face of safety, while computers continue to get faster and or cheaper (depending on how you spend your transistors/cost) is a fools paradise. Don't be baited into their flawed logic.

If your transistor/cost curve has a doubling time of 3 years, 156 weeks. A 5% difference is approximately 11 weeks.

If your transistor/cost curve has a doubling time of 2 years, a 5% difference is approximately 8 weeks.

How fast do we have to get before safety is table stakes? Focusing on raw unsafe speed wouldn't be a normalized metric in any other industry. I'll spend 8-11 weeks of performance gains on correctness.

C was an inside job.

Re: The case against a C alternative

#87

Post by aldanor »

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?

Given that many phones these days have half a dozen cores...

Re: The case against a C alternative

#88

Post by mardifoufs »

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?

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

I think you are mixing hyperthreading, or SMT with regular "software" threading

Re: The case against a C alternative

#89

Post by sitkack »

TylerE wrote: post #63
lisper wrote: post #22

Earlier quoted context omitted.

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.

If you remove the mechanically preventable bugs from being a consideration, by definition the only one you now need to focus on are the ones NOT prevented by mechanism.

How is this not a win? We only have so many decisions we can make per day.

Re: The case against a C alternative

#90

Post by cogman10 »

jhatemyjob wrote: post #71
User23 wrote: post #45

Earlier quoted context omitted.

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

Good eye. I might add: the blind praise of garbage collection, and the "symbol not found xyz" bit raised an eyebrow for me. You can't trust HN comments. Most of them sound good to laymen. But to a trained eye, it's a comment tree of cards.

> i might add the blind praise of garbage collection raised an eyebrow for me.

Like it or not, a problem C has is that it's pretty much impossible to determine why a piece of memory is currently being retained. Tools like valgrind and jemalloc can give you good starting points but really can't point to issues where "This memory is being retained because of this linked list over here"

Languages with GCs can, at any point, dump the heap and provide tools for analyzing that heap to point to the exact reason why a bit of memory is currently being retained.

That's not really "blind" praise of GCed languages, simply a fact of how they operate.

Post reply on HN