Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The case against a C alternative (2022)

c3.handmade.network

Post reply on HN
Print view View original

71–80 of 84 posts

Re: The case against a C alternative (2022)

#71

Post by [deleted] »

tialaramex wrote: post #24
epolanski wrote: post #13

Earlier quoted context omitted.

As some respectable C developer I know says: the issue with the C "killers" is that the people that already know C, have years, decades and experiences they are unwilling to let go. They can jump across any major systems programming project out there and feel at home. So to win these people you need to have a killer feature that can win them, Rust offers it. The Jai, C3, Zig, etc, do not. Sure, they are better Cs, bu…

> Sure, they are better Cs, but that's not enough to switch. It's also not always clear they are "better". The Handmade Community, from which this essay and several of these "better C" languages ultimately spring has some weird ideas about what constitutes "better". Handmade is Casey Muratori's thing. If you understand it as "This one guy did a video essay series and it all got a bit out of hand" it makes more sense.…

[deleted]

Re: The case against a C alternative (2022)

#72

Post by qsera »

kryptiskt wrote: post #19
qsera wrote: post #7

To me the case against a C alternative is simple. C is like Math. It is the fundamental high level language. There can be no alternative.. Rust made the mistake of thinking it can be low level AND safe. It tried to have the cake and eat it too. That will be its downfall.

C isn't an iota more fundamental than say Modula-2. It's just more popular. And C is very bad at being a low level language. There are plenty of things that you can express in assembly that you just can't do in C. And then the platform ABI won't support it, since C can't support it, and it hampers other languages that don't have C's limitations.

I think I didn't make it very clear. I think that by fundamental, I meant that C does not do a lot of management on its own. So there is not a lot that another language could do different that adds a lot of value.

I could be wrong. I haven't worked a lot with it.

Re: The case against a C alternative (2022)

#73

Post by mejutoco »

6P58r3MXJSLi wrote: post #52
mejutoco wrote: post #46

Earlier quoted context omitted.

The claim was runtime cost > the competing language will have a runtime cost, which often is unacceptable. The problem you now mention > at the cost of developing time and workarounds overhead. Also happens with plain c and the "pay attention" method.

> Also happens with plain c and the "pay attention" method. not really there are decades of well known practices to basically cover every possible scenario the point is Rust doesn't allow to write certain kinds of code or use certain patterns it's the cost of the boilerplate it's not that it is hard, it's that it is tedious and if we throw LLM at the problem, well, we're not talking about 100% safety anymore

> at the cost of developing time and workarounds overhead.

Let me rephrase: you are saying that tedious following of best practices (using or not certain kinds of code or use or certain patterns) does not take extra time in c, but rust (compiler) not allowing to write certain kinds of code or use certain patterns does take extra time.

Re: The case against a C alternative (2022)

#74

Post by tialaramex »

designuki wrote: post #67
tialaramex wrote: post #29

Earlier quoted context omitted.

Also C isn't well suited to a modern multi-core computer. The "fix" in C11 is to just say we have the C++ 11 Memory Ordering Model and here are some built-ins for the ordered atomic operations that implies. Having any model at all is probably most of the value and only one part of the model (consume ordering) is unimplementable fantasy so it could have been much worse, but it's hardly a triumph for a "fundamental" la…

> The "fix" in C11 is to just say we have the C++ 11 Memory Ordering Model and here are some built-ins for the ordered atomic operations that implies. Isn't Rust's solution mostly the same, just with C++20? https://doc.rust-lang.org/nomicon/atomics.html > Rust pretty blatantly just inherits the memory model for atomics from C++20.

Rust does have the same Memory Ordering idea (minus the ill-fated "Consume" ordering) but provides richer tools for a modern world than C does. The C standard library provides nothing to actually do concurrency, such as making more threads, nor to synchronize them, such as with a mutex whereas of course Rust provides std::thread::spawn and std::sync::Mutex

In C this is a platform specific problem, for Unix systems you want pthreads for example while Windows provides a different arrangement.

Rust does not provide out-of-the-box structured concurrency - which I would like - but it's a lot closer to what I'd prefer here.

Re: The case against a C alternative (2022)

#75

Post by BigTTYGothGF »

inigyou wrote: post #50
qsera wrote: post #7

To me the case against a C alternative is simple. C is like Math. It is the fundamental high level language. There can be no alternative.. Rust made the mistake of thinking it can be low level AND safe. It tried to have the cake and eat it too. That will be its downfall.

C has a high level assembly language at its roots - almost every other language does not. That's what makes it fundamental. But someone else could design a different high level assembly language.

> C has a high level assembly language at its roots

People who say this know neither C nor assembly.

Re: The case against a C alternative (2022)

#76

Post by Paul_Clayton »

xnorswap wrote: post #65
Paul_Clayton wrote: post #62

Earlier quoted context omitted.

If a language can produce the same machine code (including dynamic patching) as a second language, that second language can at best only equal the runtime characteristics of the first. The development and maintenance costs can be very different. I am not certain if C (apart from inline assembly) can generate all possible machine code, and some translations can be fragile (autovectorization, e.g.).

Well indeed, which is why I don't really like talking about the "speed" of a language at all. What really matters is the characteristics of the idiomatic usage.

I would guess that rate of benefit relative to divergence from idiomatic purity might also be significant. If a little clutter gains a 50% improvement with language A but only a 10% improvement with language B, language B having a 15% advantage under idiomatic expression may not be that significant.

But, yes, terms like "the speed of C" do not seem especially useful.

Even "equal effort" ignores the complexity of the effort-to-benefit function as well as maintainability issues and other considerations like finding good programmers who want to use the language.

Reality seems to be very complex.

Re: The case against a C alternative (2022)

#77

Post by fanf2 »

tialaramex wrote: post #74
designuki wrote: post #67

Earlier quoted context omitted.

> The "fix" in C11 is to just say we have the C++ 11 Memory Ordering Model and here are some built-ins for the ordered atomic operations that implies. Isn't Rust's solution mostly the same, just with C++20? https://doc.rust-lang.org/nomicon/atomics.html > Rust pretty blatantly just inherits the memory model for atomics from C++20.

Rust does have the same Memory Ordering idea (minus the ill-fated "Consume" ordering) but provides richer tools for a modern world than C does. The C standard library provides nothing to actually do concurrency, such as making more threads, nor to synchronize them, such as with a mutex whereas of course Rust provides std::thread::spawn and std::sync::Mutex In C this is a platform specific problem, for Unix systems yo…

The C standard library has had since C11 https://www.cppreference.com/c/thread and there are now a nonzero number of systems that support it! (glibc, musl, maybe others?)

Re: The case against a C alternative (2022)

#78

Post by AyeyeBrazorf »

qsera wrote: post #7

To me the case against a C alternative is simple. C is like Math. It is the fundamental high level language. There can be no alternative.. Rust made the mistake of thinking it can be low level AND safe. It tried to have the cake and eat it too. That will be its downfall.

Thank you I needed a reason to get out of bed this morning, and rolling on the floor laughing was by far the best!

Re: The case against a C alternative (2022)

#79

Post by inigyou »

BigTTYGothGF wrote: post #75
inigyou wrote: post #50

Earlier quoted context omitted.

C has a high level assembly language at its roots - almost every other language does not. That's what makes it fundamental. But someone else could design a different high level assembly language.

> C has a high level assembly language at its roots People who say this know neither C nor assembly.

People who comment like this don't know what they're talking about. C was literally invented to be a portable alternative to assembly.

Re: The case against a C alternative (2022)

#80

Post by inigyou »

tialaramex wrote: post #68
inigyou wrote: post #50

Earlier quoted context omitted.

C has a high level assembly language at its roots - almost every other language does not. That's what makes it fundamental. But someone else could design a different high level assembly language.

C doesn't provide an assembler at all. So if your C implementation provide an assembler that's a non-standard extension. What do you get? It depends, can you use it with a different compiler for the same target? It depends. So probably you're instead thinking "C is like an assembly language" and that's entirely wrong. The C abstract machine is very weird . No machines exactly like that have ever existed or will ever…

Actually, the PDP-11, on which C was designed, literally has that instruction.
Post reply on HN