[camgunz]

> How about we start the retirement of C as it is a liability more than an asset at this day and age

There's really only one replacement for C right now and it's Rust. If you don't like or can't use Rust (for whatever reason) you're gonna stick with C, and when you consider how much work has gone into making Rust a viable C alternative, it's clear we're a long way away from having a healthy ecosystem of C replacements.

[_ph_]

C (and C++, who inherited most problems with memory insecurity from C) are still used for a very wide variety of programs. There are plenty of alternatives to C other than Rust. Which of them is appropriate depends on the task at hand. In no particular order, all the following languages can replace C with greater memory safety:

Rust, Go, Oberon, Common Lisp, Scheme, D, Java

[camgunz]

Rust/D:

- Lack of library and platform support

- Lack of tooling

- Lack of standardization

Go:

- Lack of tooling

- Lack of standardization

- GC

- Slower

- Higher memory usage

Oberon (Ada, RTS, etc.):

- Lack of library and platform support

- Lack of tooling

- Lack of standardization

- Obscure

Common Lisp/Scheme:

- Lack of library and platform support

- Lack of tooling

- Lack of standardization

- GC

- Slower

- Higher memory usage

- Obscure

- Can't access arbitrary memory locations (?)

Java:

- GC

- Slower

- Higher memory usage

- Can't access arbitrary memory locations

I'm not really a C apologist, but I am pretty irritated with the near-constant calls for C deprecation. It's a lot easier to say, "C sucks!" than it is to do something about it, and I think we should at least internalize how difficult replacing C will be before we go around castigating people for continuing to use it.

[littlestymaar]

To be fair, C also has drawbacks

C:

- error prone

- Lack of modern typing (generics vs void pointer)

- Lack of dependency management

- no high level constructs

- unintuitive semantics (undefined behaviors)

[camgunz]

Oh absolutely! But those are merely drawbacks, not limitations. In contrast, there are many machines that simply can't host a JVM, or many platforms Rust just doesn't run on.

And that's just the "this is impossible" level. Sure you can build a database in Python, but it'll be slow and a memory hog, so if your requirements are "database, fast, low memory profile", then you can't use Python. Importantly, if you think those ever will be your requirements, you can't use Python.

I say this a lot but, engineering is about tradeoffs. There are still plenty of valid reasons to use C/C++. I'm tired of the knee-jerk "BOOOOO C" on HN these days, and while I certainly think we need to dispel the myth that you can write a meaningfully large, memory-safe program in C, I don't think we need to go as far as "you should never use C ever again". In fact, I think we need to be honest about the current state of the art in order to fully replace C -- which I wholeheartedly support.

[littlestymaar]

> In contrast, there are many machines that simply can't host a JVM

Well, if you're thinking in term of available resources, not really : most (if not every) chip on payment cards or SIM cards run Java[1] despite being incredibly limited in term of resources.

There are other (niche) example of Java running directly on bare metal, see Jazelle[2] for instance.

> or many platforms Rust just doesn't run on

Right now, absolutely but there is no technical limitation whatsoever that prevents Rust from running on these platforms. It might come, in the next decade or so if Rust gets enough traction, only time can tell.

I totally agree with the rest of your comment though.

[1]: https://en.wikipedia.org/wiki/Java_Card

[2]: https://en.wikipedia.org/wiki/Jazelle

[camgunz]

Yeah and that Java stuff is super cool; didn't Sun float a CPU with support for Java bytecode a long time ago? But they don't run a "full" JVM; I more or less mean "can run Apache Commons".

And yeah most of the platforms Rust doesn't support are either legacy or very niche. It's an interesting topic though; platform developers and manufacturers seem to have no problem shipping tweaked C compilers (usually some awful old GCC fork), but I've yet to see them use LLVM. I think Rust is hamstrung a little by having only the one compiler, but it's an entirely unfair expectation of such a young and ambitious project. Plus, it's hard to outdo LLVM.

We'll see how it goes. Maybe we'll see a lot less platform proliferation as mindshare moves away from C, but it's also possible that LLVM will just grow its platform support.

I also wonder if we'll see industry become a little more relaxed in its requirements. Like requiring multiple implementations, language standardization, or security/development standardization and verification. Most of this stuff grew out of C's instability, but with a more stable language maybe it doesn't matter? Or there are parallels in the web world too, like multiple browser vendors have to be on board with a feature for it to eventually become a standard, whereas with Rust it's pretty much whatever the Rust community decides and LLVM supports. Do we still care about standards and multiple implementations? Are the roadblocks worth it? I feel like on one hand I think they are, but also that if we accept them then we're kind of implicitly accepting C forever.