Comment by mustache_kimono | Hacker News Reader

Comment by mustache_kimono | Hacker News Reader

Parent Full thread

mustache_kimono

Wow, this blog entry's reasoning is a leaky ship.

1. C language toolchain -- No specifics (save static analyzers, ... because C needs static analyzers to catch C specific bugs...). What do you actually feel you're missing? Most of these "new C" languages use the same backend as a C compiler. What can't you use?

2., 3., and 4. -- Just chicken and egg FUD.

Not to mention it's "'Better X' doesn't matter" fundamentally doesn't understand the competition.

A sample quote: "That's not just one but eight(!) killer features (re: Java). How many of those unique selling points do the C alternatives have? Less than Java did at least!" WTF?! "But Java had 8!" is laughable.

Another: "[A]ny safety checks put into the competing language will have a runtime cost, which often is unacceptable". We can also produce a car without windows, doors or a chassis that will survive a crash, and it may be faster too. We may even get lucky and live to tell the tale.

Again: "Aside from Jai, is anyone C alternative really looking to pursue having killer features?" Aside from Jai?! Jai. Really? Oh, I remember you just discounted safety and correctness as killer features. ... But Jai. And nothing against Jai. But a language which hasn't been, which may never be, released to the general public. Just, eyes wide open, wow.

I hope this is the peak of anti-Rust/pro-C silliness, but I know it's not.

I would reread the first paragraph. In context, this is clearly not an "anti-Rust/pro-C" essay. It's not a championing of C nor a resignation to its perpetual dominance.

It's a position paper meant to sketch out the negative space that a viable C replacement can't meaningfully compete in, so that its designers can focus attention on things that actually add value. If you don't acknowledge your enemy's strengths, you'll never really be able to fight them.

> It's a position paper meant to sketch out the negative space that a viable C replacement can't meaningfully compete in

Yeah, I get it and I'm not sure it does that job well enough to be taken seriously.

> What do you actually feel you're missing?

It explicitly says in the post... for example static analyzers. What is the "Frama-C" equivalent of any language that bills itself as a replacement / competitor of C?

> Most of these "new C" languages use the same backend as a C compiler.

Most of them use LLVM as far as I know, which does not target plenty of obscure platforms.

So the argument is we need the bug finders we've developed for C (because our C is full of bugs)?

> Most of them use LLVM as far as I know, which does not target plenty of obscure platforms.

Yeah, writing software in the old language is more convenient on obscure, rare, niche platforms, because it's older than dirt. More chicken and egg nonsense. It's not impossible to have LLVM add additional targets, right?

> Yeah, writing software in the old language is more convenient because it's older than dirt. More chicken and egg nonsense. It's not impossible to have LLVM add additional targets, right?

It seems like you're being needlessly hostile. There is nothing personal about this discussion, and it's not nonsense. I write embedded software that needs to run on PIC18 microcontrollers. Support for that in LLVM was dropped about 8 years ago. Do you think it's reasonable to say to someone "just add a new LLVM target, it's not literally impossible"?

> It seems like you're being needlessly hostile.

I'm profoundly disappointed. This article's reasoning is not good.

> Do you think it's reasonable to say to someone "just add a new LLVM target, it's not literally impossible"?

No, but that C is already pervasive because it's been around 50 years isn't a case "against an alternative to C" as much as it is a headwind. That's fair. C has a massive head start and no one should discount that. But I'm not exactly certain that was the argument he was making.

This conversation is about general use of C vs alternatives such as Rust.

If you can't use Rust because of your specific circumstances that's ok - use C! But don't use "my current circumstances prevent me from using Rust" as an argument as an argument against Rust in general - which is what you're doing.

> But don't use "my current circumstances prevent me from using Rust" as an argument as an argument against Rust in general - which is what you're doing.

First of all I'm just summarizing the article, I'm in no way arguing against people using Rust. The article itself argues against C alternatives, and explicitly describes Rust as a C++ alternative. So the article is not even arguing against Rust! If we can't agree on such a basic reading of the article, it just seems like we're going to pointlessly talk past each other in the comments.

This is just trolling, you obviously were previously engaging in this thread under the premise that Rust is a C alternative.

Can you quote where I did that? Because I have no idea what you're talking about.

GCC 13 will support Rust.

I think what he's saying for (1) is that the toolchain is good compared to other languages (lots of existing tools.)

I don't know why you say 2-4 is FUD.

Reply on news.ycombinator.com