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

211–220 of 388 posts

Re: The case against a C alternative

#211

Post by mwcampbell »

jcelerier wrote: post #208
aerxes wrote: post #195

Earlier quoted context omitted.

I don’t know dude, if you want to write software for the worst performers instead of commodity hardware that’s up to you Just that single core systems are dying and probably won’t come back. Even Raspberry Pi’s are quad core now.

> I don’t know dude, if you want to write software for the worst performers instead of commodity hardware that’s up to you I want to write software that people, most people, not only those with SV salaries able to buy a computer every year, can use. Here's the current best seller laptop in Amazon in my country: https://www.amazon.fr/Dell-Inspiron-i5-1135G7-Ordinateur-por... It's half past 2022 and the most sold lapto…

Thank you! Please keep pushing such certifications until they become regulations that, like GDPR, even we American developers cannot ignore. Then I can make a strong business case to move away from Electron in the product I'm currently working on.

Edit to add:

Related to your links to best-selling computers, I've been thinking about downgrading to a low-spec PC as my daily driver, and using a remote machine for the times that I truly need something powerful for a big compile or the like. That would force me to feel the users' pain. But how far should I go? Taken to the extreme, I could use a machine with a spinning rust hard drive (not SSD) and the bare minimum system requirements for Windows 10 or 11, and keep all the crapware on it to more accurately reflect the typical user's environment. But then, maybe I'd just be hurting myself for no benefit, since the pressure to value developer productivity over runtime efficiency would not actually go away in the absence of regulations.

Re: The case against a C alternative

#212

Post by ChrisRR »

krater23 wrote: post #196
pshc wrote: post #41

This article is just apologism for the status quo. Nothing new here. > Memory allocation, array and string handling are often tricky, but with the right libraries and a sound memory strategy, it can be minimized. Such a handwavy deflection. Parsing strings in C is a joke and also a minefield bursting with vulnerabilities. And if you use null terminated strings (which you are, let’s face it) it’s slow.

Ok, but there exists a sulotion for this. Using C++ with STL. Why we exactly need a new language?

There is A solution. Is it the best solution? Are there other solutions which may offer better performance or safety.

I don't we should stop trying to improve just because an existing solution exists, especially in the space of systems programming which has barely moved in decades

Re: The case against a C alternative

#213

Post by tick_tock_tick »

Ygg2 wrote: post #192
woodruffw wrote: post #68

Earlier quoted context omitted.

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.

Interesting. Can you list an example of C++ type system allowing optimization Rust system doesn't?

template struct example { int e[n]; };

Re: The case against a C alternative

#214

Post by markdestouches »

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…

The real overhead is not safety code but inefficient design and unnecessary (and often detrimental to the user) features. The added 10% of safety checks is nothing compared to orders of magnitude of bloat modern software has. Moreover, a lot of C codebases have the same safety checks manually implemented into them, sacrificing performance in order to have less bugs. And when it comes to designing a modern C alternative, it's not just a performance/safety tradeoff, the are parts of C that are simply bad, like null-terminated strings, and are long due to be replaced with something better.

Re: The case against a C alternative

#215

Post by smitty1e »

woodruffw wrote: post #68
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…

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.

One cannot imagine C++ failing to emulate Rust's borrow checker by the end of the decade, even if compiler support is required.

Has C++ ever failed to snarf a feature?

Re: The case against a C alternative

#216

Post by rowanG077 »

aerxes wrote: post #195
jcelerier wrote: post #186

Earlier quoted context omitted.

Gaming is very much not representative. There's roughly 120M active steam users, vs. ~1.4 billion windows installs. If I look around me, for instance in my whole family we're two with Steam installed but ever household has a desktop or a laptop (and generally a 7-8 years old cheap entry-level 350€ one, you'd be hard-pressed to find even a quad-core in there)

I don’t know dude, if you want to write software for the worst performers instead of commodity hardware that’s up to you Just that single core systems are dying and probably won’t come back. Even Raspberry Pi’s are quad core now.

You should always write software for the worst performers. Unless you have a very good reason not to. Writing for the top performers is how we got into the silly mess where computers from 30 years ago have much higher ux then now.

Re: The case against a C alternative

#217

Post by GoblinSlayer »

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…

>I would rather the CPU I paid for spend its cycles performing actual application logic.

The problem is that for CPU programming errors are application logic too and they are run, cf. protected memory. You don't run everything in ring0 do you?

Re: The case against a C alternative

#218

Post by jcelerier »

mwcampbell wrote: post #211
jcelerier wrote: post #208

Earlier quoted context omitted.

> I don’t know dude, if you want to write software for the worst performers instead of commodity hardware that’s up to you I want to write software that people, most people, not only those with SV salaries able to buy a computer every year, can use. Here's the current best seller laptop in Amazon in my country: https://www.amazon.fr/Dell-Inspiron-i5-1135G7-Ordinateur-por... It's half past 2022 and the most sold lapto…

Thank you! Please keep pushing such certifications until they become regulations that, like GDPR, even we American developers cannot ignore. Then I can make a strong business case to move away from Electron in the product I'm currently working on. Edit to add: Related to your links to best-selling computers, I've been thinking about downgrading to a low-spec PC as my daily driver, and using a remote machine for the t…

> Related to your links to best-selling computers, I've been thinking about downgrading to a low-spec PC as my daily driver,

my rule of thumb for the software I develop is - on my desktop computer (2016 intel 6900k, still plenty powerful) - there mustn't be any slowness / lag in any user interaction when built at -O0 with -fsanitize=address. This has ensured so far that said software had correct performance on optimized builds on a Raspberry Pi 3 in ARMv7 mode.

Re: The case against a C alternative

#219

Post by tialaramex »

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.

So, let's take the most extreme example of pursuing safety, WUFFS.

Unlike general purpose languages WUFFS has a very specific purpose (Wrangling Untrusted File Formats Safely) so it doesn't need to worry that it can't solve some of your problems, which frees it to completely refuse to do stuff that's unsafe, while going real, real fast.

WUFFS gets to completely omit bounds checks, which you probably wouldn't have dared try in C because it's so obviously unsafe, but WUFFS already proved at compile time that it can't ever have bounds misses so it needn't do these checks. WUFFS gets to also omit integer overflow checks, because again it proved at compile time that your code is correct and cannot overflow for any input. And since WUFFS knows how big the data is at all times it gets to automatically generate loop unrolling and suchlike accelerations.

WUFFS isn't a general purpose language, it doesn't have strings, it doesn't have growable arrays (what C++ calls "vectors"), it doesn't have any dynamic memory allocation, but then we weren't talking about how much you love general purpose features, we were talking about safety preventing security bugs. Which is exactly what WUFFS does.

Post reply on HN