Comment by drnick1
8 hours ago
Every system under the Sun has a C compiler. This isn't remotely true for Rust. Rust is more modern than C, but has it's own issues, among others very slow compilation times. My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative.
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 (with a degree of asterisks on the last two). 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. Leaving this set of mandatory languages is difficult (I think Fortran, and BASIC-with-an-asterisk, are the only languages to really have done so), and Perl is the only one I would risk money on departing in my lifetime.
I do firmly expect that we're less than a decade out from seeing some reference algorithm be implemented in Rust rather than C, probably a cryptographic algorithm or a media codec. Although you might argue that the egg library for e-graphs already qualifies.
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.
A C compiler is also relatively easy to implement (compared to a Rust compiler) if you're making your own hobby OS with its own C compiler and libc.
> 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.
> 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?
From my experience of building LFS it appears to be needed to built as part of the tool chain.
https://linuxfromscratch.org/lfs/view/development/chapter07/...
It's extremely hard to build any unixly userspace without perl dependencies.
1 reply →
critical at build time, not runtime
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.
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 am yet to find one without it, unless you include Windows, consoles, or table/phone OSes, embedded RTOS, which aren't anyway proper UNIX derivatives.
2 replies →
What other newfangled alternative to C was ever adopted in the Linux kernel?
I have no doubt C will be around for a long time, but I think Rust also has a lot of staying power and won’t soon be replaced.
I wouldn't be surprised to see zig in the kernel at some point
I would be. Mostly because while Zig is better than C, it doesn't really provide all that much benefit, if you already have Rust.
IMHO Zig doesn't bring enough value of its own to be worth bearing the cost of another language in the kernel.
Rust is different because it both:
- significantly improve the security of the kernel by removing the nastiest class of security vulnerabilities.
- And reduce cognitive burden for contributors by allowing to encode in thr typesystem the invariants that must be upheld.
That doesn't mean Zig is a bad language for a particular project, just that it's not worth adding to an already massive project like the Linux kernel. (Especially a project that already have two languages, C and now Rust).
8 replies →
As mentioned in another thread, POSIX requires the presence of a C compiler,
https://pubs.opengroup.org/onlinepubs/9799919799/utilities/c...
Though to be fair, POSIX is increasingly outdated.
GNU/Linux isn't the only system out there, POSIX last update was in 2024 (when C requirement got upgraded to C17), and yes some parts of it are outdated in modern platforms, especially Apple, Google, Microsoft OSes and Cloud infrastructure.
Still, who supports POSIX is expected to have a C compiler available if applying for the OpenGroup stamp.
I can’t think of many real world production systems which don’t have a rust target. Also I’m hopeful the GCC backend for rustc makes some progress and can become an option for the more esoteric ones
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.
There’s also I believe an effort to target C as the mid level although I don’t know the state / how well it’ll work in an embedded space anyway where performance really matters and these compilers have super old optimizers that haven’t been updated in 3 decades.
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.
Those don’t really support C in any real stretch, talking about general experience with microcontrollers and closed vendor toolchains; it’s a frozen dialect of C from decades ago which isn’t what people think of when they say C (usually people mean at least the 26 year old C99 standard but these often at best support C89 or even come with their own limitations)
1 reply →
Commercial embedded OSes, game consoles, for example.
Seems like game consoles for example has been accomplished by at least one dedicated team even if the vendor nor upstream provide official support: https://www.reddit.com/r/rust/comments/78bowa/hey_this_is_ky...
I’m sure if Rust becomes more popular in the game dev community, game consoles support will be a solved problem since these consoles are generally just running stock PC architectures with a normal OS and there’s probably almost nothing wrong with the stock toolchain in terms of generating working binaries: PlayStation and Switch are FreeBSD (x86 vs ARM respectively) and Xbox is x86 Windows, all of which are supported platforms.
2 replies →
> very slow compilation times
That isn't always the case. Slow compilations are usually because of procedural macros and/or heavy use of generics. And even then compile times are often comparable to languages like typescript and scala.
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.
Runtime memory issues probably have a significantly higher total cost.
But of course that doesn't negate this cost, but building can always be done on another machine as a way to circumvent the problem.
typescript transpilation to js is nearly instant, it's not comparable
Good to know, my $DAYJOB project unfortunately isn’t as well informed and we have to use esbuild just to survive.
Doesn’t rustc emit LLVM IR? Are there a lot of systems that LLVM doesn’t support?
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.
Using LLVM somewhere in the build doesn't require that you compile everything with LLVM. It generates object files, just like GCC, and you can link together object files compiled with each compiler, as long as they don't use compiler-specific runtime libraries (like the C++ standard library, or a polyfill compiler-rt library).
`clang-cl` does this with `cl.exe` on Windows.
If you're developing, you generally have control over the development environment (+/-) and you can install things. Plus that already reduces the audience: set of people with oddball hardware (as someone here put it) intersected with the set of people with locked down development environments.
Let alone the fact that conceptually people with locked down environments are precisely those would really want the extra safety offered by Rust.
I know that real life is messy but if we don't keep pressing, nothing improves.
> My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative.
if only due to the Lindy Effect
https://en.wikipedia.org/wiki/Lindy_effect
> Every system under the Sun has a C compiler... My guess is that C will be around long after people will have moved on from Rust to another newfangled alternative.
This is still the worst possible argument for C. If C persists in places no one uses, then who cares?
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 :/
> C will continue to be used because it always has been and always will be available everywhere
Yes, you can use it everywhere. Is that what you consider a success?
2 replies →
> it always has been and always will be available everywhere
"Always has been" is pushing it. Half of C's history is written with outdated, proprietary compilers that died alongside their architecture. It's easy to take modern tech like LLVM for granted.
1 reply →
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.
> You almost certainly have a bunch of devices containing a microcontroller that runs an architecture not targeted by LLVM.
This is exactly what I'm saying. Do you think HW drives SW or the other way around? When Rust is in the Linux kernel, my guess is it will be very hard to find new HW worth using, which doesn't have some Rust support.
1 reply →