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

171–180 of 388 posts

Re: The case against a C alternative

#171

Post by mort96 »

GuB-42 wrote: post #125
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 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…

> Modern C++ also discourages raw pointers and so you get references counters all over the place, essentially turning C++ into a garbage collected language.

This doesn't match my experience. It's true that modern C++ discourages owning raw pointers, but the solution is usually unique_ptr, not shared_ptr. Truly shared ownership is actually pretty uncommon IME, usually you can have one entity which obviously "owns" the object and then any other reference to it can be non-owning.

It's also worth noting that with std::move, actually changing the refcount of a share_ptr can be pretty rare even if you do have shared ownership.

Re: The case against a C alternative

#172

Post by naniwaduni »

sicp-enjoyer wrote: post #102
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.

It's frankly harder and/or less fun to generate C and integrate with whatever locally support C infrastructure you have than it is to BYO.

Re: The case against a C alternative

#173

Post by rcarmo »

I still occasionally write C (and C++), but have come to appreciate the sparseness of Go (although not the intricate abstractions of Rust) and keep wondering if Zig (which does cross-compilation almost as effortlessly as Go) shouldn’t be more popular.

In the end, though, you can accomplish the same (from an outcome perspective, not necessarily from a satisfactory one) in all of them, so I try not to be overly biased, although convenience vs correctness seem to be the main issues at play here.

(Edit: why the downvotes? Is Zig out of favor? Is it because this may read as a slight on Rust?)

Re: The case against a C alternative

#174

Post by intelVISA »

pjmlp wrote: post #155
ducktective wrote: post #143

Earlier quoted context omitted.

>The only reason C doesn't (often) have similar supply chain attacks is because pulling in dependencies is so hard that you aren't likely to end up with a 10k dependency project. Or the lack of canonical package manager means the developer has to actually spend time to inspect the quality of each dependency instead of `npm install is-odd`ing like there is no tomorrow. It also acts as a "filter" to prevent adding comp…

They will do `apt-get install is-odd` instead, or yum, pacman, or...

I do most of my heavy lifting with Git commit hashes via FetchContent and it's been pretty good to be fair, surprising number of well written CMakeLists in popular lib repos.

Re: The case against a C alternative

#176

Post by planede »

flohofwoe wrote: post #161
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…

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

inlining only goes so far. You won't get full of qsort to be inlined, and if it's not inlined, it needs to be at least cloned to be on par with std::sort, so the comparator function could get const-propagated.

AFAIK out of the major compilers, gcc has the most aggressive cloning, but it's still nowhere near to const propagate the comparator from qsort. With std::sort with a stateless comparator function object (such as std::less, which is the default), you get this for free*.

* of course this is not entirely free, as this is more prone to code bloat. But, you can always type-erase the comparator, and use a function pointer, or std::function, if this ever becomes a problem. But you can't convince a C compiler to const propagate the comparator in qsort all the way through, if the optimizer chooses that it doesn't worth it.

Re: The case against a C alternative

#177

Post by naniwaduni »

An oft-overlooked pain point is that when interacting with C interfaces, it's not good enough to implement a C ABI FFI. There's a world of software out there where the supporrted interface is a C API, at the source level. Compatibility across different versions, or across different implementations, is assured only to programs which interact with the interfaces in ways that correspond particular C source patterns.

The biggest culprit I've met on this front is the POSIX stat family of functions.

Re: The case against a C alternative

#178

Post by WalterBright »

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…

C has a huge performance burden from 0 terminated strings. Programs are constantly running strlen() or equivalent to get the length. Length-delineated strings, like what D has, are an order of magnitude faster.

Re: The case against a C alternative

#179

Post by rob74 »

aerxes wrote: post #126
cmeacham98 wrote: post #101

Earlier quoted context omitted.

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…

The data that it presents shows that >50% of PCs surveyed have 6 cores or more.

>50% of PCs which have Steam installed, i.e. are used for gaming. So the statistic is not really representative of all PCs out there...

Re: The case against a C alternative

#180

Post by enqk »

planede wrote: post #176
flohofwoe wrote: post #161

Earlier quoted context omitted.

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

inlining only goes so far. You won't get full of qsort to be inlined, and if it's not inlined, it needs to be at least cloned to be on par with std::sort, so the comparator function could get const-propagated. AFAIK out of the major compilers, gcc has the most aggressive cloning, but it's still nowhere near to const propagate the comparator from qsort. With std::sort with a stateless comparator function object (such…

check this out: https://github.com/WebKit/WebKit/blob/main/Source/bmalloc/li...
Post reply on HN