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

181–190 of 388 posts

Re: The case against a C alternative

#181

Post by alcover »

cesarb wrote: post #100
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…

My favorite example of a safety feature in Rust which also improves runtime performance is string slices, which are implemented as a pair of a pointer to the first character and the length (used for bounds checking). Not only does this avoid having to scan for the NUL terminator to find the string length (that is, O(1) instead of O(N), which can make the difference between an O(N) and O(N^2) algorithm), but also it a…

Made this C lib for exactly the reasons you mention. I love C but got mad at the constant bounds errors and copying.

https://github.com/alcover/buffet

Re: The case against a C alternative

#182

Post by mlindner »

> Looking at C++ alternatives there are languages like D, Rust, Nim, Crystal, Beef, Carbon and others.

Why do people keep lumping Rust into the category of a "C++ alternative". Rust is a C alternative and can be used places that C can but C++ cannot. i.e the linux kernal and baremetal silicon (C++ can be used in the embedded but I've never heard of it being used without modification for that environment).

> My language (C3) is fairly recent, there are others: Zig, Odin, Jai and older languages like eC.

Further he seems to claim that Jai is a C alternative when it's explicitly described by it's creator as a C++ alternative.

Re: The case against a C alternative

#183

Post by robalni »

The problem with making a new language is that it seems like people do it because they want to make a new language. Don't make a new language just to make a new language. Do it because you are solving a problem by doing it, and if you are solving a problem, you already win regardless of how many people will use the language. Have the problem before you make the solution.

> It turns out that people don't always agree on what the pain points with C is.

People have different problems so they should probably use different languages. Don't even try to make a language that will solve everyone's problems.

> Also, while the company has experience recruiting for C developers, it doesn't know how to recruit for this new language.

If the language is so hard that people have to have special knowledge to use it and can't learn it quickly then it's probably not a good language.

> For a business it's whether despite the downsides the language can help the bottom line: "Is this valuable enough to outweigh the downsides?"

Exactly, it's solving real problems that matters.

> The "build it and they will come" idea is tempting to believe in

A better idea is "build it and we will come because we need it. Then maybe other people will come if they need it too."

Re: The case against a C alternative

#184

Post by loup-vaillant »

rob74 wrote: post #179
aerxes wrote: post #126

Earlier quoted context omitted.

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

The fact remains that virtually all systems except perhaps old low-end phones now have more than one thread. Not going multi-thread for anything that makes the user wait leaves significant performance on the table.

Low end systems (4 threads or less) have less potential, but they also have the most need for speed, making multi-threading quite important. And high-end systems have more threads, so going multi-thread makes a bigger difference.

Re: The case against a C alternative

#185

Post by EdSchouten »

WalterBright wrote: post #178
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.

Exactly! And because you can't create a substring without mutating the original value, you see that C code often needs to resort to unnecessary copying as well.

Re: The case against a C alternative

#186

Post by jcelerier »

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…

Gaming is very much not representative. There's roughly 120M active steam users, vs. ~1.4 billion windows installs.

If I look around me, for instance in my whole family we're two with Steam installed but ever household has a desktop or a laptop (and generally a 7-8 years old cheap entry-level 350€ one, you'd be hard-pressed to find even a quad-core in there)

Re: The case against a C alternative

#189

Post by loup-vaillant »

astrange wrote: post #111
jsnell wrote: post #95

Earlier quoted context omitted.

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.

If the choice is between a compile time warning and a runtime crash, I will take the warning every single time: much closer to the actual error. You're probably asking for a compile time error instead.

Indeed the `-Werror` option is often a good thing to have (though I don't set it by default on my free software projects, because other people might use other compilers with different warnings, and I don't want to block them outright).

Re: The case against a C alternative

#190

Post by jjgreen »

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…

This. I know I'll never get SHOUTY DEPRECATION WARNINGS with C.
Post reply on HN