Java hasn't ever been essential outside enterprise-y servers and those don't care about "any viable system".

We're already at the point where in order to have a "decent" desktop software experience you _need_ Rust too. For instance, Rust doesn't support some niche architectures because LLVM doesn't support them (those architectures are now exceedingly rare) and this means no Firefox for instance.

A system only needs one programming language to be useful, and when there's only one it's basically always C.

> Rust I don't think has made it through that door yet, but on current trends, it's at the threshold and will almost certainly step through.

I suspect what we are going to see isn't so much Rust making it through that door, but LLVM. Rust and friends will come along for the ride.

Removing Java from my desktop Arch system only prompts to remove two gui apps I barely use. I could do it right now and not notice for months.

> There is a set of languages which are essentially required to be available on any viable system. At present, these are probably C, C++, Perl, Python, Java, and Bash

Java, really? I don’t think Java has been essential for a long time.

Is Perl still critical?

Even Perl... It's not in POSIX (I'm fairly sure) and I can't imagine there is some critical utility written in Perl that can't be rewritten in Python or something else (and probably already has been).

As much as I like Java, Java is also not critical for OS utilities. Bash shouldn't be, per se, but a lot of scripts are actually Bash scripts, not POSIX shell scripts and there usually isn't much appetite for rewriting them.

Debian and Ubuntu enter the chat.....

I don't think Perl comes pre installed on any modern system anymore

I wouldn't be surprised to see zig in the kernel at some point

Though to be fair, POSIX is increasingly outdated.

There aren't really any "systems programming" platforms anywhere near production that doesn't have a workable rust target.

It's "embedded programming" where you often start to run into weird platforms (or sub-platforms) that only have a c compiler, or the rust compiler that does exist is somewhat borderline. We are sometimes talking about devices which don't even have a gcc port (or the port is based on a very old version of gcc). Which is a shame, because IMO, rust actually excels as an embedded programming language.

Linux is a bit marginal, as it crosses the boundary and is often used as a kernel for embedded devices (especially ones that need to do networking). The 68k people have been hit quite hard by this, linux on 68k is still a semi-common usecase, and while there is a prototype rust back end, it's still not production ready.

It's mostly embedded / microcontroller stuff. Things that you would use something like SDCC or a vendor toolchain for. Things like the 8051, stm8, PIC or oddball things like the 4 cent Padauk micros everyone was raving about a few years ago. 8051 especially still seems to come up from time to time in things like the ch554 usb controller, or some NRF 2.4ghz wireless chips.

Commercial embedded OSes, game consoles, for example.

Compared to C, rust compiles much slower. This might not matter on performant systems, but when resources are constrained you definitely notice it. And if the whole world is rewritten in Rust, this will have a non-significant impact on the total build time of a bunch of projects.

typescript transpilation to js is nearly instant, it's not comparable

There are a number of oddball platforms LLVM doesn't support, yeah.

rustc can use a few different backends. By my understanding, the LLVM backend is fully supported, the Cranelift backend is either fully supported or nearly so, and there's a GCC backend in the works. In addition, there's a separate project to create an independent Rust frontend as part of GCC.

Even then, there are still some systems that will support C but won't support Rust any time soon. Systems with old compilers/compiler forks, systems with unusual data types which violate Rust's assumptions (like 8 bit bytes IIRC)

Many organizations and environments will not switch themselves to LLVM to hamfist compiled Rust code. Nor is the fact of LLVM supporting something in principle means that it's installed on the relevant OS distribution.

I think you didn't catch their drift

C will continue to be used because it always has been and always will be available everywhere, not only places no one uses :/

You almost certainly have a bunch of devices containing a microcontroller that runs an architecture not targeted by LLVM. The embedded space is still incredibly fragmented.

That said, only a handful of those architectures are actually so weird that they would be hard to write a LLVM backend for. I understand why the project hasn’t established a stable backend plugin API, but it would help support these ancillary architectures that nobody wants to have to actively maintain as part of the LLVM project. Right now, you usually need to use a fork of the whole LLVM project when using experimental backends.