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

241–250 of 388 posts

Re: The case against a C alternative

#241

Post by camel-cdr »

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…

"void* and function pointers" behaves essentially the same as templates, assuming the compiler inlines or function clones the function called with constant expression arguments.

Re: The case against a C alternative

#242

Post by pjmlp »

flohofwoe wrote: post #164
pjmlp wrote: post #151

Earlier quoted context omitted.

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

That is why it is called a subset, duh!

Re: The case against a C alternative

#243

Post by jstimpfle »

AndyKelley wrote: post #210
flohofwoe wrote: post #162

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

This person is actively trying to make a "better C" so it's no surprise his arguments against his own project are lukewarm. "It is difficult to get a man to understand something, when his salary depends on his not understanding it."

Why do you put that quote? I'm not sure anybody "tried to get him understand it". I suppose the post comes mostly because of what the author learned or concluded from his own project. There might be other motivations. I think the post has some genuinely good points that need to get more mindshare.

Re: The case against a C alternative

#244

Post by camel-cdr »

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…

qsort only isn't inline, because libcs don't supply an inline definition. If you write your own qsort, then you'll see it getting inlined and/or function cloned for different types.

Re: The case against a C alternative

#245

Post by temac »

enqk wrote: post #180
planede wrote: post #176

Earlier quoted context omitted.

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

Interesting but I'm not sure about the relevancy to the above comment.

On a sidenote, it has weird claims:

> obviating the need for ownership type systems or other compiler approaches to fixing the type-safety of use-after-frees. This means that we need one heap per type, and be 100% strict about it.

Re: The case against a C alternative

#246

Post by mort96 »

bregma wrote: post #237
mort96 wrote: post #171

Earlier quoted context omitted.

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

This is not my experience. Most developers are just not very good at what they do, and the go-to smart pointers for not-very-good C++ developers is std:shared_ptr .

Hmm, that might be. Most of the C++ I've seen has been in LLVM, Google projects, projects where I'm the only developer or projects where I laid the groundwork which other people build upon, so I'm probably not mainly looking at the kind of code bases you're talking about.

Re: The case against a C alternative

#247

Post by steeleduncan »

Kukumber wrote: post #105

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

I have a similar list, but I think part the difficulty with C replacements is that the sort of people who want to go out and write a new language generally do so because they have something more radical in mind.

I have pondered forking tinycc and using that as a startpoint for a more conservative set of changes like you describe. It would limit the amount of work to be done and lead to something useable quite quickly.

Re: The case against a C alternative

#248

Post by brhsagain »

> First of all, pretty much all languages ever will make vacuous claims of "higher programmer productivity". The problem is that for a business this usually doesn't matter. Why? Because the actual programming is not the main time sink. In a business, what takes time is to actually figure out what the task really is. So something like a 10% or 20% "productivity boost" won't even register. A 100% increase in productivity might show, but even that isn't guaranteed.

I stopped reading here. This is like saying typing speed doesn't matter because most of your time is spent thinking about what to type. If your argument basically evaluates to saying that it doesn't matter how productive you are while doing the actual activity of your job itself... at some point it's like, I dunno, do you actually believe what you're saying?

Also, not to go off on too unrelated/unhinged a tangent, but, I've also started noticing in the last five years this widespread fear of actually sitting down and programming. There's a weird meta-culture where people want to do anything but sit down and write code, because it's hard and scary. I hear arguments made all the time for how important everything is — aligning stakeholders, scoping tasks, communication, mentoring juniors, soft skills, whatever. Everything except writing the actual code, which is somehow a mere technical triviality that anyone can do, or something.

Re: The case against a C alternative

#249

Post by camel-cdr »

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…

The only real difference between qsort and std::sort in terms of code generation, is that for std::sort the default assumption is to function clone and for qsort it is to generate the full slow function. Now the compiler will in most cases detect that qsort can be cloned or inlined, but sometimes it might decide not to and the fallback is, in most cases slower then the C++ fallback.

PS.: I'm just annoyed that my generic C hashtable that is written in a qsort style doesn't get function copied/inlined when it's used for more than one type.

Re: The case against a C alternative

#250

Post by lupire »

bregma wrote: post #237
mort96 wrote: post #171

Earlier quoted context omitted.

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

This is not my experience. Most developers are just not very good at what they do, and the go-to smart pointers for not-very-good C++ developers is std:shared_ptr .

OK but those people aren't going to magically write safe performant C either.
Post reply on HN