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

111–120 of 388 posts

Re: The case against a C alternative

#111

Post by astrange »

jsnell wrote: post #95
lisper wrote: post #72

Earlier quoted context omitted.

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…

Bad example. There's nothing[0] you could put in the ellipsis to make that code valid, and both gcc and clang will warn about it (clang on defaults, gcc with -Wall). [0] Ok, I guess you could #define x something, but that's not interesting from a static analysis perspective.

Warning is one thing, but crashing is better. That's possible to do in a C compiler too of course, because in this example the array hasn't decayed to a pointer and its size can be recovered.

The issue is when you pass the array to another function, it can't track the size without changing the ABI.

Re: The case against a C alternative

#113

Post by DoctorOW »

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…

> Please take a few days to review John Regehr’s excellent blog. I’m certain that you’ll find dispelling your ignorance rewarding.

Just a heads up, this reads to me as condescending.

Re: The case against a C alternative

#114

Post by david2ndaccount »

jitl wrote: post #80

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

zig cc has enough bugs in it that I just went back to using clang on each platform.

Re: The case against a C alternative

#115

Post by joeldo »

gregoryc_ wrote: post #29

Has anyone checked out this? You can use C, but with better syntax. https://cboard.cprogramming.com/c-programming/181160-hi-i-ha... I'm looking for contributors. :)

Just some advice, I think you'll struggle to gain traction without putting the source onto Github, as that is generally how people contribute :)

Re: The case against a C alternative

#116

Post by tempest_ »

sitkack wrote: post #89
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.

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.

A lot of people make perfect the enemy of good.

Re: The case against a C alternative

#117

Post by didip »

pkrumins wrote: post #92

I will never use any other language for server apps than C. C is a language for getting things done. It's finished and final. It will not change. There will be no new surprises, no new operators, and no unpublished packages. There are just source files. Write, compile, ship, repeat. You used it in 1990 to ship, you used it in 2000 to ship, you used it in 2010 to ship, you used in 2020 to ship, and you will use it in…

Wait… really? Not even considering C++ Boost, Go, or Rust?

Re: The case against a C alternative

#118

Post by Jtsummers »

astrange wrote: post #109
mardifoufs wrote: post #88

Earlier quoted context omitted.

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

Rob Pike tried to create a distinction here: https://go.dev/talks/2012/waza.slide#1

Using his distinction, concurrency isn't about IO-boundedness (though that's a common use-case for it), but instead is about composing multiple processes (generic sense). They may or may not be running in parallel (truly running at the same time).

On a unix shell this would be an example of concurrency, which may or may not be parallel:

  $ cat a-file | sort | uniq | wc
Each process may run at the literal same time (parallelism), but they don't have to, and on a single core machine would not be executing simultaneously.

This hasn't fully caught on, though.

Re: The case against a C alternative

#119

Post by Cyberdog »

nkurz wrote: post #108
cogman10 wrote: post #37

Earlier quoted context omitted.

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?

Zig: https://ziglang.org/documentation/master/#Assembly

Re: The case against a C alternative

#120

Post by dawnbreez »

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.

...in a lot of the cases I ran into early on, the rust compiler literally told me what to change.
Post reply on HN