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

251–260 of 388 posts

Re: The case against a C alternative

#251

Post by pjmlp »

camel-cdr wrote: post #241
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…

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

Without the related typechecking.

Re: The case against a C alternative

#252

Post by voidhorse »

bruce343434 wrote: post #236
jokoon wrote: post #193

Finally an article I can agree with. C is great mostly because it's easy to learn, and it has many other advantages. I dislike all those new languages because they have too many features, and they're non trivial to learn. I've looked at some rust codebases and I don't think there will be a lot of people who will want to maintain them. Rust is difficult, even though it's an awesome language. A language that could comp…

Go?

Actually, yes. Go does a lot of the things everyone seems to want in these C replacements, the problem is that it has GC which, to a lot of people, automatically disqualifies it as an option for writing certain kinds of software you can write with manual memory management. A lot of people also tend to think they need manual memory management for $reasons when GC is actually fine.

Re: The case against a C alternative

#253

Post by jstimpfle »

returningfory2 wrote: post #127

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

If what comes after the check is a write or any other destructive operation, then the check is not so easy to mask away. I don't have actual numbers, but my gut is a strong 'no'.

That said, a lot of pedestrian code that isn't running particularly hot would probably be better off including runtime checks by default.

Re: The case against a C alternative

#254

Post by pjmlp »

jstimpfle wrote: post #238
pshc wrote: post #41

This article is just apologism for the status quo. Nothing new here. > Memory allocation, array and string handling are often tricky, but with the right libraries and a sound memory strategy, it can be minimized. Such a handwavy deflection. Parsing strings in C is a joke and also a minefield bursting with vulnerabilities. And if you use null terminated strings (which you are, let’s face it) it’s slow.

Typical statement coming from people lacking experience in this field (no offense meant). The truth is, parsing strings in C is as easy as in any other language. You have a string array and a length field, and you scrub through it from left to right with a cursor. Done. What you do not get in C is creating lots of string objects willy-nilly, and concatenating them with a plus sign, like you do in scripting languages.

Now Object Pascal and Modula-2 are scripting languages....

Re: The case against a C alternative

#255

Post by afiori »

Ygg2 wrote: post #192
woodruffw wrote: post #68

Earlier quoted context omitted.

Precisely. This is perhaps the strangest part of the original post: C++ has the same performance advantages as Rust! It has them not because it's more safe (although it is, in some regards), but because it allows programmers to express behaviors that the compiler can reason about statically.

Interesting. Can you list an example of C++ type system allowing optimization Rust system doesn't?

I don't think you could do [0] in Rust, but would be very interested in finding out otherwise.

[0] https://capnproto.org/news/2015-03-02-security-advisory-and-...

Re: The case against a C alternative

#256

Post by jstimpfle »

bowsamic wrote: post #200
qayxc wrote: post #197

Earlier quoted context omitted.

That's a weird analogy considering humans used base-12 (and base-20 and base-60) number systems for most of history.

Really? Wikipedia says it is historically uncommon EDIT: What language uses base-60??

Minutes in an hour, seconds in a minute, and something about degrees.

Re: The case against a C alternative

#257

Post by pjmlp »

ChrisRR wrote: post #212
krater23 wrote: post #196

Earlier quoted context omitted.

Ok, but there exists a sulotion for this. Using C++ with STL. Why we exactly need a new language?

There is A solution. Is it the best solution? Are there other solutions which may offer better performance or safety. I don't we should stop trying to improve just because an existing solution exists, especially in the space of systems programming which has barely moved in decades

The only way to real achieve progress in systems programming is through generation change, one person at a time, the problem isn't technical.

Re: The case against a C alternative

#258

Post by voidhorse »

rcarmo wrote: post #173

I still occasionally write C (and C++), but have come to appreciate the sparseness of Go (although not the intricate abstractions of Rust) and keep wondering if Zig (which does cross-compilation almost as effortlessly as Go) shouldn’t be more popular. In the end, though, you can accomplish the same (from an outcome perspective, not necessarily from a satisfactory one) in all of them, so I try not to be overly biased,…

I like Zig a lot and think it hits precisely the right niche for a C replacement. Rust is a great language, but it’s definitely not C like when it comes to the overall UI and philosophy.

I’d like to use Zig a bit more, but the standard library is still going through some significant changes (it seems) which makes it slightly harder to commit to at the moment.

In general I wonder if some of these languages would actually benefit from Jai’s approach of deferring availability until the language is ready. While getting early adopters is great for getting feedback early, it can also disuade potential users that try the language before its ready and decide to leave it alone as a result.

Re: The case against a C alternative

#259

Post by jstimpfle »

brhsagain wrote: post #248

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

The point is "marginal costs from switching languages may outweigh any benefits in plain programming productivity".

Re: The case against a C alternative

#260

Post by pjmlp »

cogman10 wrote: post #123
nkurz wrote: post #108

Earlier quoted context omitted.

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.

Odin is pretty much alive to JangaFX customers,

https://jangafx.com/

Post reply on HN