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

161–170 of 388 posts

Re: The case against a C alternative

#161

Post by flohofwoe »

jiggawatts wrote: post #60
woodruffw wrote: post #40

> 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. I don't think this is true, in the general case: Rust has shown that languages…

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…

> become dramatically faster when rewritten in a more modern language

IME that's mostly a myth though. A C compiler will stamp out a specialized version just as well if it can see all the relevant function bodies (either via inlining or LTO).

"Zero cost abstraction" isn't just a C++ thing, it happens mostly in the language agnostic optimizer passes. For instance the reason why std::sort() shows up faster in benchmarks than C's qsort() is simply because std::sort() implementation is all inline template code, not because of some magic performance-enhancing qualities of the C++ template system.

Re: The case against a C alternative

#162

Post by flohofwoe »

What a defeatist take :/

A "better C" language doesn't have to "win the popularity race" to be useful, it just needs to (a) be easy to learn coming from C, (b) integrate well into the existing C/C++/ObjC ecosystem, and (c) easy to install and across all supported platforms.

A "better C" cannot and should not replace C for all use cases, but it should at least augment C by fixing its design wart.

The actually depressing thing is the "winner takes all" mentality though that seems to be prelevant in the programming world.

Re: The case against a C alternative

#163

Post by flohofwoe »

david2ndaccount wrote: post #114
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.

What you're seeing is most likely not bugs (it is clang after all), but the result of the much stricter default compilation settings in "zig cc" which tends to break a lot of C code that hasn't been checked against a static analyzer or ASAN before.

Re: The case against a C alternative

#164

Post by flohofwoe »

pjmlp wrote: post #151
GuB-42 wrote: post #125

Earlier quoted context omitted.

I don't know Rust but I know C++. And C++ has the potential to be faster than C, mostly thanks to metaprogramming (templates, ...). It is horrible if you have to do it, but if you are just using the standard library, you don't have to feel the pain but still take advantage of it. That's how algorithms are implemented. Because so much is known at compile time, optimizers can do a lot. The reason C++ is generally regar…

As of C++17 not so horrible, and C++2x versions even less so, unless one has some strange fetisch for SFINAE and tag dispatch. Since 1993, I never saw any need to keep bothering with C other than having it imposed on me, C++ had enough C89 subset on it, if I ever miss coding like C and its warts. Nowadays that compatibility is up to C11 subset.

> Nowadays that compatibility is up to C11 subset.

Not true unfortunately, the "C subset" is still stuck at something that can at best be called a fork of "C95" which was then developed into a "bastard language" that resembled C on the surface, but isn't actually C (e.g. the incomplete designated init support in C++20 is the best example of this half-assed "looks like C, but isn't actually C" philosophy).

Re: The case against a C alternative

#165

Post by dang »

pkrumins wrote: post #94
woodruffw wrote: post #40

> 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. I don't think this is true, in the general case: Rust has shown that languages…

Quoted post unavailable.

Would you please stop trolling HN? You've been here for 15 years. You have a distinguished history of writing good articles. You didn't use to post crap comments like this or https://news.ycombinator.com/item?id=32387218 and we need you to stop it. If you don't we will have to ban you, which I would hate to do.

If you have some substantive critique to make about Rust in appropriate contexts, that's fine of course. But this sort of programming language flamewar is definitely not fine. It leads to lame, dumb threads that we're trying to avoid here.

https://news.ycombinator.com/newsguidelines.html

Re: The case against a C alternative

#166

Post by naniwaduni »

Jtsummers wrote: post #118
astrange wrote: post #109

Earlier quoted context omitted.

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

Yes, not catching on is a common problem when you invent distinctions not borne out by existing practice.

Re: The case against a C alternative

#167

Post by kitd »

zozbot234 wrote: post #158
chaeronanaut wrote: post #56

Earlier quoted context omitted.

this pretty much summarises my opinion - one nitpick - i assume you meant " omit bounds and other checks", not "emit bounds and other checks" which seems to mean the opposite of what you're intending

Rust does emit bounds and other checks, though. Optimization passes can usually clear some of them away, but you'd need to check the assembly output to be sure.

Yes, that's "omit".

"Emit" means "to send out", eg "emit a strange noise", "emit radiation".

Re: The case against a C alternative

#168

Post by naniwaduni »

pshc wrote: post #53
gregoryc_ wrote: post #47

Earlier quoted context omitted.

Depends on the functions used. memcpy is better than strcpy

I’m sure you meant something more along the lines of “strncpy is better than strcpy”.

Nah, strncpy is pretty bad and doesn't do something anyone really expects to want.

(strncpy doesn't 0-terminate when it hit max length, nor stop when it sees its first 0 in the source buffer; it acts almost entirely like memcpy except that it writes zeroes to the full length of the destination upon seeing a zero in the source. This is allegedly useful for populating fixed-sized buffers in historical Unix, and can plausibly be useful for writing out tar headers, but in practice very little code in the wild does anything observably different if you #define strncpy memcpy.)

Re: The case against a C alternative

#169

Post by mlindner »

woodruffw wrote: post #40

> 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. I don't think this is true, in the general case: Rust has shown that languages…

There are in fact ways that idiomatic Rust can be even faster than idiomatic C.

Re: The case against a C alternative

#170

Post by oconnor663 »

> This leads to a strategy of only having checks in "safe" mode. Where the "fast" mode is just as "unsafe" as C.

This is hard to describe without getting deep into Rust details, but I think the ability to encapsulate unsafe code in safe APIs is just as important as what pure safe code can do. (Of course those two things end up being intimately related.)

Post reply on HN