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

41–50 of 84 posts

Re: The case against a C alternative (2022)

#41

Post by anthk »

Rust wasn't made to replace C, C is to be there at low level and as a glue code for everything.

Rust was made to replace C++ because the language it's a behemoth, it tries to do everything and the syntax it's a Lovecraftan nightmare, full of legacy incompatibilities. For small games such as Cataclysm:DDA I'd use Go (and for system tools and internet services OFC) and for game engines Rust it's or even GC based languages (not Java) can do it well (C# with AOT).

Even Common Lisp it's fine (just look up Trial/Kandria) with SDL2/3 and/or OpenGL bindings (Vulkan ones should be somewhere). Pick SBCL for speed, learn CL, learn about SIMD and optimizations. It can beat C on performance.

https://www.stylewarning.com/posts/nbody/

EDIT: the bindings are cl-vulkan, of course.

Re: The case against a C alternative (2022)

#42

Post by hanneshdc »

> 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 problem is overstated. There's no safety/performance tradeoff here. Rust has shown that extensive safety checks can be applied at compile time with zero runtime overhead.

For a concrete example, checking that an array access is in bounds at runtime does come with a performance penalty. However it's also possible to prove at compile time that an array index can never escape it's array bounds. And, if it's not possible to prove this statically - you should be heavily questioning the security of that code.

Re: The case against a C alternative (2022)

#43

Post by inigyou »

billforsternz wrote: post #17
netdur wrote: post #6

I am guilty in a sense, I started a new programming language called C+ and one of the pillars I set was that it should not be an alternative to C (or any other language), in fact it uses Clang as its compiler, most of the points in the article still hold, but I hope it doesn’t stop people from coming up with new ideas and actually implementing them in this field, you don't have to be next big thing to be awesome

I like to program in a C++ subset that's basically C plus a sprinkling of ergonomic quality of life C++ features eg references and generic containers. I think of it as C+. (Edit: No disrespect meant. I just thought such completely different language concepts potentially sharing the same name was kind of amusing)

Almost everyone that uses C++ uses a subset of C++ and it's always a different subset. (That's fine, that's because it's a "big tent" language philosophy)

Re: The case against a C alternative (2022)

#45

Post by 6P58r3MXJSLi »

hanneshdc wrote: post #42

> 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 problem is overstated. There's no safety/performance tradeoff here. Rust has shown that extensive safety checks can be applied at compile time with zero runtime overhead. For a concrete example, checking that an array access is in bounds at runtime does c…

> Rust has shown that extensive safety checks can be applied at compile time with zero runtime overhead.

at the cost of developing time and workarounds overhead.

> And, if it's not possible to prove this statically - you should be heavily questioning the security of that code.

or that's exactly the compromise that allows you to develop that software

there is no 100% safety with zero overhead

it is not possible

Re: The case against a C alternative (2022)

#46

Post by mejutoco »

6P58r3MXJSLi wrote: post #45
hanneshdc wrote: post #42

> 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 problem is overstated. There's no safety/performance tradeoff here. Rust has shown that extensive safety checks can be applied at compile time with zero runtime overhead. For a concrete example, checking that an array access is in bounds at runtime does c…

> Rust has shown that extensive safety checks can be applied at compile time with zero runtime overhead. at the cost of developing time and workarounds overhead. > And, if it's not possible to prove this statically - you should be heavily questioning the security of that code. or that's exactly the compromise that allows you to develop that software there is no 100% safety with zero overhead it is not possible

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.

Re: The case against a C alternative (2022)

#47

Post by inigyou »

shevy-java wrote: post #31

Several of the arguments are not compelling. For instance: "The C language is not just the language itself but all the developer tools developed for the language. Do you want to do static analysis on your source code?" This is a finite problem set. For instance, AI could auto-create useful toolings eventually. And even without AI, people can. Even more so if a new language is designed with that in mind from the get g…

> that a language that would be able to replace C, needs to target both the speed issue without compromise AND the efficiency of writing code,

C++ tried this. You can use null-terminated char arrays like in C, or you can use std::string and it works like Python or Ruby. C++'s problem is that by having so many features to please everyone, the interactions between some of the features are less than obvious, and there's always some feature you're encountering for the first time.

Re: The case against a C alternative (2022)

#48

Post by friendzis »

serbuvlad wrote: post #35
friendzis wrote: post #14

The overarching argument in this article seems to be sort of chicken and an egg. > 4. No experienced developers Well, with C you need experienced devs that are also EXPERIENCED IN C. You can write C that compiles but is all kinds of incorrect, usually subtly. Any new language that works with the dev on writing correct code or outright refuses to compile with incorrect code (hinting at Rust here) cracks this egg a bit…

> Any new language that works with the dev on writing correct code or outright refuses to compile with incorrect code (hinting at Rust here) I've started writing Rust in the past year and... honestly... I LOVE it. But what kept me away from Rust for a long time is this talking point of rejecting incorrect code which is so obviously wrong it made proponents of Rust sound very cultish to me. Rust cannot prevent incorre…

> But what kept me away from Rust for a long time is this talking point of rejecting incorrect code which is so obviously wrong it made proponents of Rust sound very cultish to me.

In discussions regarding testing and static vs dynamic languages, I like to emphasize the point that with static languages you get some "tests" for free: the compiler enforcing the contract will "test" that you are not passing in string for integer. With e.g. Python if you want to be defensive and on the correctness side, you need to implement poor-man's type restrictions and tests for the unit so it behaves sensibly with call-site being incorrect.

Does it sound cultish to you to insist on static type checks when e.g. writing Python? There's quite tangible value in that.

> Rust cannot prevent incorrect code, nor is this possible (halting problem).

Yes, nothing will prevent analyst/PO from misunderstanding business requirements, nothing will prevent dev from misunderstanding the technical requirements. Or not thinking things through. Errors on this front will always turnaround.

Correctness in this context refers to programmer's and compiler's understanding of code being aligned. Correct code does what it is supposed to do. Rust takes type safety and elevates it to a next level, ensuring reads, writes and object lifetimes are correct.

Re: The case against a C alternative (2022)

#49

Post by xnorswap »

anthk wrote: post #41

Rust wasn't made to replace C, C is to be there at low level and as a glue code for everything. Rust was made to replace C++ because the language it's a behemoth, it tries to do everything and the syntax it's a Lovecraftan nightmare, full of legacy incompatibilities. For small games such as Cataclysm:DDA I'd use Go (and for system tools and internet services OFC) and for game engines Rust it's or even GC based langua…

There are times that JIT'd C# out-performs AOT C#, so I'd avoid defaulting to recommending AOT. Assuming that AOT is faster is the same trap that C advocates fall into when thinking that other languages can only ever equal C on speed.

Re: The case against a C alternative (2022)

#50

Post by inigyou »

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.
Post reply on HN