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

101–110 of 388 posts

Re: The case against a C alternative

#101

Post by cmeacham98 »

aerxes wrote: post #96
cmeacham98 wrote: post #67

Earlier quoted context omitted.

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

Gonna beat a dead horse here, but >50% of PCs that are surveyed by Steam have 12 threads or more. That’s PCs that have steam installed at all. Intel’s bare minimum current-gen i3 processor has 12 threads. That’s the absolute cheapest desktop-level processor you can get. Your phone probably has 6 cores (though not 12 threads). So yes, if you’re writing code for desktop hardware, it’s safe to assume you have at least 8…

This article doesn't say that, what it actually says is "Over 70% of Steam users have a CPU with 4 or more cores."

Steam doesn't even measure publicize information about threads on the survey, which makes it near impossible to check because not that long ago Intel locked out hyperthreading/SMT on their low/mid-grade CPUs.

Additionally, and more importantly: the Steam hardware survey _obviously_ doesn't represent the average consumer PC.

Re: The case against a C alternative

#102

Post by sicp-enjoyer »

xyzsparetimexyz wrote: post #23

You could write a 100-line python script that compiles from your custom language to C code and it's still be better than C. There's lots of ways to re-use existing tooling and the bar really isn't that high for better languages

Why do you think more of these projects don't take this approach? I would be 10x more likely to try one in a professional setting if I knew the portion I was taking chance on was source translation layer, and I could rely on the well tested and supported C infrastructure.

Re: The case against a C alternative

#103

Post by woodruffw »

pkrumins wrote: post #98
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.

Rust will not replace anything because it’s impossible to write code in it. Everything you write is a syntax error that requires an exobrain to figure out.

What's the point of this hyperbole? We have ample evidence that thousands of engineers (and large companies) are successfully applying Rust.

Re: The case against a C alternative

#104

Post by bigDinosaur »

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.

It defeats some extremely important classes of exploits. And I'm not sure how they're not ones that lead to really bad outcomes since they lead to fun ones such as arbitrary code execution all the time. I can create a C program with hideous vulnerabilities in about five minutes without doing anything that isn't totally standard and normal (albeit obviously vulnerable so technically buggy). I'd have to actually look up how to make my code vulnerable in languages with more safety features.

Re: The case against a C alternative

#105

Post by Kukumber »

I just want:

C with:

- bounds checking

- use after free checks

- modules

- sane metaprograming/template

- tagged union built in

without:

- macro

- pre declaration

- split header/source

That's it, no borrow checker, no weird syntax, no nothing

So far D is the answser for me, but i'm worried about its future, will they keep improve the language in that direction? or will they continue with their high level stuff

Zig/Jai/Odin so far are looking interesting, the problem is they all depart from the C syntax, wich is annoying, the only syntax i'd like to change is the primitive type, i32/f32/size/usize, and that's it, no need more

Re: The case against a C alternative

#106

Post by repiret »

midoridensha wrote: post #73
bee_rider wrote: post #32

Earlier quoted context omitted.

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.

Don’t underestimate how exploitable the 1957 edition of mother-in-law is. That’s why I liked the availability of walled gardens.

Re: The case against a C alternative

#107

Post by Jtsummers »

woodruffw wrote: post #103
pkrumins wrote: post #98

Earlier quoted context omitted.

Rust will not replace anything because it’s impossible to write code in it. Everything you write is a syntax error that requires an exobrain to figure out.

What's the point of this hyperbole? We have ample evidence that thousands of engineers (and large companies) are successfully applying Rust.

GP has been posting the same thing in many threads when Rust comes up. Apparently they think it's funny, or they're really bad at writing Rust code and feel like venting.

Re: The case against a C alternative

#108

Post by nkurz »

cogman10 wrote: post #37
nkurz wrote: post #20

> And worse, what if the language omits crucial features that are present in C? Features that C advanced programmers rely on? Seems like this might be a good place to ask: which of the C replacement languages mentioned (or not mentioned) support inline assembly? Do any of them do it better than GCC/Clang? For me, I feel like the ability to drop to assembly in a pinch is a necessary feature. I'm sure I could technical…

Pretty much all of them at this point. Rust: https://doc.rust-lang.org/nightly/reference/inline-assembly.... D: https://dlang.org/spec/iasm.html Ada: https://docs.adacore.com/gnat_ugn-docs/html/gnat_ugn/gnat_ug... Cobol: https://www.ibm.com/docs/en/cobol-zos/6.2?topic=appendixes-a... Pascal: https://wiki.freepascal.org/Asm Python: https://pypi.org/project/il/ You can almost name a language and find a route to inline…

Do you happen to know if is also true for the C replacement languages mentioned in the article: C3, Zig, Odin, Jai and eC?

Re: The case against a C alternative

#109

Post by astrange »

mardifoufs wrote: post #88
cmeacham98 wrote: post #67

Earlier quoted context omitted.

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

They're mixing parallelism and concurrency. (nb: I might be abusing these terms too)

Parallelism aka CPU-bound tasks are limited by the number of cores you have. Concurrency aka IO-bound tasks are not, because they're usually not all runnable at once. It can be faster to go concurrent even on a single core because you can overlap IOs, but it'll use more memory and other resources.

Also, "going faster" isn't always a good thing. If you're a low priority system task, you don't want to consume all the system resources because the user's apps might need them. Or the the user doesn't want the fans to turn on, or it's a passive cooled system that shouldn't get too hot, etc.

And for both of them, it not only makes it easier to write bugs in unsafe languages, but in safe languages you can easily accidentally make things slower instead of faster just because it's complicated.

Re: The case against a C alternative

#110

Post by cmeacham98 »

defen wrote: post #79
cmeacham98 wrote: post #61

Earlier quoted context omitted.

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

This is just trolling, you obviously were previously engaging in this thread under the premise that Rust is a C alternative.
Post reply on HN