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

71–80 of 388 posts

Re: The case against a C alternative

#71

Post by jhatemyjob »

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…

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.

Re: The case against a C alternative

#72

Post by lisper »

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…

First, not all language safety features have to manifest themselves as run-time checks. A properly designed language will allow many safety checks to be done at compile-time.

And second, would you really rather deal with security holes on an on-going basis?

The problem with C is not that you can write unsafe code in it, it is that the design of the language -- and pointer aliasing in particular -- makes it impossible to perform even basic sanity checks at compile time [EDIT: or even at run-time for that matter]. For example:

int x[10];

...

int y = x[11];

In any sane language, that would be a trivially-checkable compile-time error. But in C it is not because there are all kinds of things that could legally happen where the ellipses are that would make this code not violate any of C's safety constraints. That is the problem with C, and it is a fundamental problem with C's design, that it conflates pointers and arrays. C was designed for a totally different world, and it is broken beyond repair.

Re: The case against a C alternative

#73

Post by midoridensha »

bee_rider wrote: post #32
woodruffw wrote: post #26

Earlier quoted context omitted.

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

You don't seem to understand that those malicious programs have no way of running on someone's computer if they can't exploit some other program to get installed on the machine in the first place. If the system software on the target machine is written in a better language and has no exploits, then it doesn't matter what language the attacker uses for their software.

Re: The case against a C alternative

#74

Post by piperswe »

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 Ryzen 5 3600X (a years-old mid-range CPU) has 6 cores and 12 threads, I wouldn't say that's atypical.

Re: The case against a C alternative

#75

Post by mcpherrinm »

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.

> 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 C. We have tried and failed for years at that.

Re: The case against a C alternative

#76

Post by lisper »

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.

I can't respond to that unless you are more specific about what are "the ones that lead to really bad outcomes". There are a lot of arbitrary-code-execution attacks that are enabled by buffer overflows, and IMHO that's as bad as it gets. There is absolutely no legitimate excuse for a buffer overflow in today's world. Switching to safe(r) language won't prevent all attacks, but it will make a big dent.

Re: The case against a C alternative

#77

Post by josephg »

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.

Yep. A few years ago I implemented a skip list based rope library in C[1], and after learning rust I eventually ported it over[2].

The rust implementation was much less code than the C version. It generated a bigger assembly but it ran 20% faster or so. (I don't know why it ran faster than the C version - this was before the noalias analysis was turned on in the compiler).

Its now about 3x faster than C, thanks to some use of clever layered data structures. I could implement those optimizations in C, but I find rust easier to work with.

C has advantages, but performance is a bad reason to choose C over rust. In my experience, the runtime bounds checks it adds are remarkably cheap from a performance perspective. And its more than offset by the extra optimizations the rust compiler can do thanks to the extra knowledge the compiler has about your program. If my experience is anything to go by, naively porting C programs to rust would result in faster code a lot of the time.

And I find it easier to optimize rust code compared to C code, thanks to generics and the (excellent) crates ecosystem. If I was optimizing for runtime speed, I'd pick rust over C every time.

[1] https://github.com/josephg/librope

[2] https://github.com/josephg/jumprope-rs

Re: The case against a C alternative

#78

Post by monocasa »

msbarnett wrote: post #64

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

Lingua Franca in this case typically refers to the fact that you write a library with at least C ABI support if you want it to have the largest user base. Almost all languages' FFIs support some C ABI for their libraries.

Re: The case against a C alternative

#79

Post by defen »

cmeacham98 wrote: post #61
defen wrote: post #42

Earlier quoted context omitted.

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

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

First of all I'm just summarizing the article, I'm in no way arguing against people using Rust. The article itself argues against C alternatives, and explicitly describes Rust as a C++ alternative. So the article is not even arguing against Rust! If we can't agree on such a basic reading of the article, it just seems like we're going to pointlessly talk past each other in the comments.

Re: The case against a C alternative

#80

Post by jitl »

> But aside from Jai, is anyone C alternative really looking to pursue having killer features? And if it doesn't have one, how does it prove the switch from C is worth it? It can't.

Zig's `zig cc` is a killer feature that doesn't even require using Zig-the-language at all. `zig cc` is an LLVM-based C compiler that gives you trivial cross-compilation for existing C codebases, adds effective caching, and can be easily installed on most operating systems with `tar -xzf`.

https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

Post reply on HN