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

121–130 of 388 posts

Re: The case against a C alternative

#121

Post by didgetmaster »

Like any other technology that wishes to supplant the status-quo, a new programming language cannot be just 'a little bit better'. It has to be substantially better in order to overcome the inertia that the entrenched technology has established.

This is true for both software and hardware. There have been plenty of leaps and bounds such as SSD speeds compared to HDD speeds; but even there, SSDs will not supplant HDDs until there is price parity between the two technologies. Until then, data will be stored on SSD when fast access is critical and on HDD when there is too much of it to justify the cost.

Getting a company to switch operating systems, database vendors, or cloud providers is likewise an uphill battle. They don't call them 'walled gardens' for nothing.

I am building a new data management system that I think is much better than file systems at storing and managing unstructured data and better than RDBMS at managing structured data; but I wouldn't have even dreamed of starting the project if I wasn't confident that it was at least 2x better at a minimum.

Re: The case against a C alternative

#122

Post by jamesfinlayson »

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 seems to as well, though I haven't looked closely enough at any of them to see if the support goes beyond x86/x64 (or even ARM).

Re: The case against a C alternative

#123

Post by cogman10 »

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?

C3: Currently being looked into https://github.com/c3lang/c3c#current-status

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

Odin: Looks like it's a dead language, but it was on the docket. https://github.com/odin-lang/Odin/blob/master/misc/roadmap.m...

Jai: https://github.com/Jai-Community/Jai-Community-Library/wiki/...

eC: No clue. Not a great name for googling.

Re: The case against a C alternative

#124

Post by dralley »

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.

Possibly true, but bugs can be fixed. The potential is still there.

Re: The case against a C alternative

#125

Post by GuB-42 »

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…

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 regarded as slower is that C++ programmers tend to create objects on the heap all the time because constructors and destructors make it easy. Modern C++ also discourages raw pointers and so you get references counters all over the place, essentially turning C++ into a garbage collected language. I am not saying it is bad, but it certainly impacts performance.

But if you manage your memory in C++ just as you do in C, keeping track of all your buffers reusing them, and not using more than necessary, I can easily see C++ beat C.

Re: The case against a C alternative

#126

Post by aerxes »

cmeacham98 wrote: post #101
aerxes wrote: post #96

Earlier quoted context omitted.

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…

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.

Re: The case against a C alternative

#127

Post by returningfory2 »

> any safety checks put into the competing language will have a runtime cost, which often is unacceptable.

Suppose you have bounds checks on array accesses, but your program is 100% correct and the panic case is never hit. Doesn't the branch predictor essentially make the bounds check free? Or very low cost at least?

Re: The case against a C alternative

#128

Post by dralley »

didip wrote: post #112

Jai is not real. It should not be mentioned even on the same sentence as Zig.

It's real but without public access it's largely useless. I understand why Jonathan might want to avoid dealing with a peanut gallery trying to argue with him about what his language should be like, and that's fine, his language his rules and all of that. But until this situation changes it's impossible for anyone to really care about Jai.

Re: The case against a C alternative

#129

Post by II2II »

lisper wrote: post #72
ryandrake wrote: post #54

Earlier quoted context omitted.

> I would much rather have my computer run slower than have to continuously deal with security vulnerabilities. My time is much more valuable than CPU time. To be devil’s advocate and take the other side of this argument: I would rather the CPU I paid for spend its cycles performing actual application logic. Every cycle spent executing all this “safety code” overhead feels like me having to pay for a developer’s slop…

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…

I'm not here to defend C, but to point out a problem that many advocates make when they cherry pick examples of how their language is both safer and more performant than C. Simply put, that example is irrelevant when the size of the array is not known at compile time. The moment that you have a dynamically allocated array, you are either dropping safety (e.g. expecting the developer to perform bounds checks when necessary) or performance (e.g. the compiler inserts bounds checks at runtime).

It is also worth considering that there is nothing preventing C compilers from inserting compile time checks to address examples such as yours. I just tried to compile a similar example in gcc and it does catch the unsafe code with warnings and the optimizer turned on.

Re: The case against a C alternative

#130

Post by User23 »

cogman10 wrote: post #90
jhatemyjob wrote: post #71

Earlier quoted context omitted.

Good eye. I might add: the blind praise of garbage collection, and the "symbol not found xyz" bit raised an eyebrow for me. You can't trust HN comments. Most of them sound good to laymen. But to a trained eye, it's a comment tree of cards.

> i might add the blind praise of garbage collection raised an eyebrow for me. Like it or not, a problem C has is that it's pretty much impossible to determine why a piece of memory is currently being retained. Tools like valgrind and jemalloc can give you good starting points but really can't point to issues where "This memory is being retained because of this linked list over here" Languages with GCs can, at any po…

You’re not wrong that aliasing presents serious practical problems for building an efficient object graph. The thing is the defining characteristic of a C-like is that it has an ultra lightweight runtime[1]. The way I look at it, every C program has a bespoke garbage collector of variable quality. It’s fair to say the median is pretty dismal sure, but tooling does exist to tame that beast.

I think there’s a wide open research space to work on taming the aliasing problem. There are PhDs to be had, and maybe even Turing awards.

[1] C gets to cheat a little bit here because Unix and friends are its runtime.

Post reply on HN