6 ms·

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 comp

by drnick1 11mo 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.

vlovich123 11mo ago
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
- MobiusHorizons 11mo ago
  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.
  - vlovich123 11mo ago
    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)
    - MobiusHorizons 11mo ago
      It’s still C though, and rust is not an option. What else would you call it? Lots of c libraries for embedded target C89 syntax for exactly these reasons. Also for what it’s worth, SDCC seems to support very modern versions of C (up to C23), so I also don’t think that critique is very valid for the 8051 or stm8. I would argue that c was built with targets like this in mind and it is where many of its quirks that seem so anachronistic today come from (for example int being different sizes on different targets)
- phire 11mo ago
  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.
  - vlovich123 11mo ago
    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.
- pjmlp 11mo ago
  Commercial embedded OSes, game consoles, for example.
  - vlovich123 11mo ago
    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_kyren_from_chucklefish_we_make_and/ 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.
    - pjmlp 11mo ago
      Being supported on a games console means that you can produce binaries that are able to go through the whole approval process, and there is day 1 support for anything that is provided by the console vendor. Otherwise is yak shaving instead of working on the actual game code. Some people like to do that, that is how new languages like Rust get adoption, however they are usually not the majority, hence why mainstream adoption without backing from killer projects or companies support is so hard, and very few make it. Also you will seldom see anyone throw away the confort of Unreal, Unity or even Godot tooling, to use Rust instead, unless they are more focused on proving the point the game can be made in Rust, than the actual game design experience.
    - bob1029 11mo ago
      > Switch Good luck shipping arbitrary binaries to this target. The most productive way for an indie to ship to Nintendo in 2025 is to create the game Unity and build via the special Nintendo version of the toolchain. How long do we think it would take to fully penetrate all of these pipeline stages with rust? Particularly Nintendo, who famously adopts the latest technology trends on day 1. Do we think it's even worthwhile to create, locate, awaken and then fight this dragon? C# with incremental GC seems to be more than sufficient for a vast majority of titles today.
brokencode 11mo ago
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.
- ottah 11mo ago
  I wouldn't be surprised to see zig in the kernel at some point
  - littlestymaar 11mo ago
    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).
    - sayamqazi 11mo ago
      Pardon my ignorance but I find the claim "removing the nastiest cla ss of security vulnerabilities" to be a bold claim. Is there ZERO use of "unsafe" rust in kernel code??
      - littlestymaar 11mo ago
        Not zero, but Rust-based kernels (see redox, hubris, asterinas, or blog_os) have demonstrated that you only need a small fraction of unsafe code to make a kernel (3-10%) and it's also the least likely places to make a memory-related error in a C-based kernel in the first place (you're more likely to make a memory-related error when working on the implementation of an otherwise challenging algorithm that has nothing to do with memory management itself, than you are when you are explicitly focused on the memory-management part). So while there could definitely be an exploitable memory bug in the unsafe part of the kernel, expect those to be at least two orders of magnitude less frequent than with C (as an anecdotal evidence, the Android team found memory defects to be between 3 and 4 orders of magnitude less in practice over the past few years).
thayne 11mo ago
> 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.
- Yiin 11mo ago
  typescript transpilation to js is nearly instant, it's not comparable
  - baq 11mo ago
    Good to know, my $DAYJOB project unfortunately isn’t as well informed and we have to use esbuild just to survive.
  - thayne 11mo ago
    Rust compilation is also almost instant, if you have a relatively small project. It's only when you get very large projects that compilation time becomes a problem. If typescript compilation speed wasn't a problem, then why would Microsoft put resources into rewriting the tyescript compiler in Go to make it faster[1]? [1]: https://github.com/microsoft/typescript-go https://github.com/microsoft/typescript-go
- timow1337 11mo ago
  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.
  - gf000 11mo ago
    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.
  - 11mo ago
jcranmer 11mo ago
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.
- qalmakka 11mo ago
  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.
- tormeh 11mo ago
  A system only needs one programming language to be useful, and when there's only one it's basically always C.
  - trinix912 11mo ago
    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.
  - deleted 11mo ago
    [deleted]
- teruakohatu 11mo ago
  > 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?
blintz 11mo ago
Doesn’t rustc emit LLVM IR? Are there a lot of systems that LLVM doesn’t support?
- aw1621107 11mo ago
  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)
- loeg 11mo ago
  There are a number of oddball platforms LLVM doesn't support, yeah.
- einpoklum 11mo ago
  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.
  - simonask 11mo ago
    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.
  - oblio 11mo ago
    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.
mustache_kimono 11mo ago
> 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?
- jazzyjackson 11mo ago
  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 :/
  - mustache_kimono 11mo ago
    > 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?
    - AceJohnny2 11mo ago
      ... yes?
      - mustache_kimono 11mo ago
        >> Yes, you can use it everywhere. Is that what you consider a success? > ... yes? Then perhaps you and I define success differently? As I've said in other comments above, C persisting or really standing still is not what I would think of as a winning and vibrant community. And the moving embedded and kernel development from what was previously a monoculture to something more diverse could be a big win for developers. My hope is that competition from Rust makes using C better/easier/more productive, but I have my doubts as to whether it will move C to make changes.
        qwm 11mo ago
        Sometimes it's nice to know that something will run and compile reliably far into the future. That's a nice thing to have, and wide support for the language and its relatively unchanging nature make it reliable.
AceJohnny2 11mo ago
> 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 https://en.wikipedia.org/wiki/Lindy_effect
- qwm 11mo ago
  Sure, but the reason tends to be that if you want something to run everywhere, C is your best bet.
pjmlp 11mo ago
As mentioned in another thread, POSIX requires the presence of a C compiler, https://pubs.opengroup.org/onlinepubs/9799919799/utilities/c17.html https://pubs.opengroup.org/onlinepubs/9799919799/utilities/c...
- eru 11mo ago
  Though to be fair, POSIX is increasingly outdated.
  - pjmlp 11mo ago
    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.
    - eru 11mo ago
      > GNU/Linux isn't the only system out there, [...] Yes? I'm especially keen on the project to make just 'Linux' without any Gnu components. Jokes aside, yes, other operating systems exist. > [...] and yes some parts of it are outdated in modern platforms, especially Apple, Google, Microsoft OSes and Cloud infrastructure. Well, also on modern hardware in general. POSIX's idea about storage abstractions don't gel well with modern hardware. Well, not just modern hardware: atime has been cast aside since time immemorial. But lots of the other ideas are also dropping by the wayside. In practice, we get something like 'POSIX-y' or 'close-enough-to-POSIX', which doesn't get a stamp from OpenGroup. I think Linux largely falls in that boat. But regardless of that distinction, a C compiler is very much part of the informal 'close-enough-to-POSIX' class. It's a bit of a shame that Unix has retarded operating system research for so long. Fortunately, the proliferation of virtual machines and hypervisors have re-invigorated the field. Just pretend that your hypervisor is your nano-kernel and your VMs are your processes. No need to run a full on Linux kernel in your VM, you can just have enough code running for your webserver or database etc, no general kernel needed. See eg https://mirage.io/ https://mirage.io/
archargelod 11mo ago
One problem of Rust vs C, I rarely see mentioned is that Rust code is hard to work with from other languages. If someone writes a popular C library, you can relatively easily use it in your Java, D, Nim, Rust, Go, Python, Julia, C#, Ruby, ... program. If someone writes a popular Rust library, it's only going to be useful to Rust projects. With Rust I don’t even know if it’s possible to make borrow checking work across a language boundary. And Rust doesn't have a stable ABI, so even if you make a DLL, it’ll only work if compiled with the exact same compiler version. *sigh*
- aw1621107 11mo ago
  The reason you rarely hear that mentioned is because basically every programming language is hard to work with from other languages. The usual solution is to "just" expose a C API/ABI. Of course, C API/ABIs aren't able to make full use of Rust features, but again, that also applies to basically every other language.
- sophacles 11mo ago
  Perhaps we can finally stop defining abis in terms of c structs!
  - qwm 11mo ago
    If only Rust had a spec to do that with
    - sophacles 11mo ago
      I don't think they should be defined in terms of any programming language. They should be defined in terms of the architecture - bits, bytes, words and instructions, along with semantics of use. Like we do with networking protocols and file formats.
    - steveklabnik 11mo ago
      It's being worked on! https://github.com/rust-lang/rfcs/pull/3470 https://github.com/rust-lang/rfcs/pull/3470

by drnick1 11mo ago

vlovich123 11mo ago

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

MobiusHorizons 11mo ago
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.
- vlovich123 11mo ago
  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)
  - MobiusHorizons 11mo ago
    It’s still C though, and rust is not an option. What else would you call it? Lots of c libraries for embedded target C89 syntax for exactly these reasons. Also for what it’s worth, SDCC seems to support very modern versions of C (up to C23), so I also don’t think that critique is very valid for the 8051 or stm8. I would argue that c was built with targets like this in mind and it is where many of its quirks that seem so anachronistic today come from (for example int being different sizes on different targets)
phire 11mo ago
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.
- vlovich123 11mo ago
  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.
pjmlp 11mo ago
Commercial embedded OSes, game consoles, for example.
- vlovich123 11mo ago
  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_kyren_from_chucklefish_we_make_and/ 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.
  - pjmlp 11mo ago
    Being supported on a games console means that you can produce binaries that are able to go through the whole approval process, and there is day 1 support for anything that is provided by the console vendor. Otherwise is yak shaving instead of working on the actual game code. Some people like to do that, that is how new languages like Rust get adoption, however they are usually not the majority, hence why mainstream adoption without backing from killer projects or companies support is so hard, and very few make it. Also you will seldom see anyone throw away the confort of Unreal, Unity or even Godot tooling, to use Rust instead, unless they are more focused on proving the point the game can be made in Rust, than the actual game design experience.
  - bob1029 11mo ago
    > Switch Good luck shipping arbitrary binaries to this target. The most productive way for an indie to ship to Nintendo in 2025 is to create the game Unity and build via the special Nintendo version of the toolchain. How long do we think it would take to fully penetrate all of these pipeline stages with rust? Particularly Nintendo, who famously adopts the latest technology trends on day 1. Do we think it's even worthwhile to create, locate, awaken and then fight this dragon? C# with incremental GC seems to be more than sufficient for a vast majority of titles today.

brokencode 11mo ago

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.

ottah 11mo ago
I wouldn't be surprised to see zig in the kernel at some point
- littlestymaar 11mo ago
  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).
  - sayamqazi 11mo ago
    Pardon my ignorance but I find the claim "removing the nastiest cla ss of security vulnerabilities" to be a bold claim. Is there ZERO use of "unsafe" rust in kernel code??
    - littlestymaar 11mo ago
      Not zero, but Rust-based kernels (see redox, hubris, asterinas, or blog_os) have demonstrated that you only need a small fraction of unsafe code to make a kernel (3-10%) and it's also the least likely places to make a memory-related error in a C-based kernel in the first place (you're more likely to make a memory-related error when working on the implementation of an otherwise challenging algorithm that has nothing to do with memory management itself, than you are when you are explicitly focused on the memory-management part). So while there could definitely be an exploitable memory bug in the unsafe part of the kernel, expect those to be at least two orders of magnitude less frequent than with C (as an anecdotal evidence, the Android team found memory defects to be between 3 and 4 orders of magnitude less in practice over the past few years).

thayne 11mo ago

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

Yiin 11mo ago
typescript transpilation to js is nearly instant, it's not comparable
- baq 11mo ago
  Good to know, my $DAYJOB project unfortunately isn’t as well informed and we have to use esbuild just to survive.
- thayne 11mo ago
  Rust compilation is also almost instant, if you have a relatively small project. It's only when you get very large projects that compilation time becomes a problem. If typescript compilation speed wasn't a problem, then why would Microsoft put resources into rewriting the tyescript compiler in Go to make it faster[1]? [1]: https://github.com/microsoft/typescript-go https://github.com/microsoft/typescript-go
timow1337 11mo ago
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.
- gf000 11mo ago
  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.
- 11mo ago

jcranmer 11mo ago

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.

qalmakka 11mo ago
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.
tormeh 11mo ago
A system only needs one programming language to be useful, and when there's only one it's basically always C.
- trinix912 11mo ago
  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.
- deleted 11mo ago
  [deleted]
teruakohatu 11mo ago
> 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?

blintz 11mo ago

Doesn’t rustc emit LLVM IR? Are there a lot of systems that LLVM doesn’t support?

aw1621107 11mo ago
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)
loeg 11mo ago
There are a number of oddball platforms LLVM doesn't support, yeah.
einpoklum 11mo ago
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.
- simonask 11mo ago
  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.
- oblio 11mo ago
  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.

mustache_kimono 11mo ago

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

jazzyjackson 11mo ago
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 :/
- mustache_kimono 11mo ago
  > 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?
  - AceJohnny2 11mo ago
    ... yes?
    - mustache_kimono 11mo ago
      >> Yes, you can use it everywhere. Is that what you consider a success? > ... yes? Then perhaps you and I define success differently? As I've said in other comments above, C persisting or really standing still is not what I would think of as a winning and vibrant community. And the moving embedded and kernel development from what was previously a monoculture to something more diverse could be a big win for developers. My hope is that competition from Rust makes using C better/easier/more productive, but I have my doubts as to whether it will move C to make changes.
      - qwm 11mo ago
        Sometimes it's nice to know that something will run and compile reliably far into the future. That's a nice thing to have, and wide support for the language and its relatively unchanging nature make it reliable.

AceJohnny2 11mo ago

> 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 https://en.wikipedia.org/wiki/Lindy_effect

qwm 11mo ago
Sure, but the reason tends to be that if you want something to run everywhere, C is your best bet.

pjmlp 11mo ago

As mentioned in another thread, POSIX requires the presence of a C compiler, https://pubs.opengroup.org/onlinepubs/9799919799/utilities/c17.html https://pubs.opengroup.org/onlinepubs/9799919799/utilities/c...

eru 11mo ago
Though to be fair, POSIX is increasingly outdated.
- pjmlp 11mo ago
  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.
  - eru 11mo ago
    > GNU/Linux isn't the only system out there, [...] Yes? I'm especially keen on the project to make just 'Linux' without any Gnu components. Jokes aside, yes, other operating systems exist. > [...] and yes some parts of it are outdated in modern platforms, especially Apple, Google, Microsoft OSes and Cloud infrastructure. Well, also on modern hardware in general. POSIX's idea about storage abstractions don't gel well with modern hardware. Well, not just modern hardware: atime has been cast aside since time immemorial. But lots of the other ideas are also dropping by the wayside. In practice, we get something like 'POSIX-y' or 'close-enough-to-POSIX', which doesn't get a stamp from OpenGroup. I think Linux largely falls in that boat. But regardless of that distinction, a C compiler is very much part of the informal 'close-enough-to-POSIX' class. It's a bit of a shame that Unix has retarded operating system research for so long. Fortunately, the proliferation of virtual machines and hypervisors have re-invigorated the field. Just pretend that your hypervisor is your nano-kernel and your VMs are your processes. No need to run a full on Linux kernel in your VM, you can just have enough code running for your webserver or database etc, no general kernel needed. See eg https://mirage.io/ https://mirage.io/

archargelod 11mo ago

One problem of Rust vs C, I rarely see mentioned is that Rust code is hard to work with from other languages. If someone writes a popular C library, you can relatively easily use it in your Java, D, Nim, Rust, Go, Python, Julia, C#, Ruby, ... program. If someone writes a popular Rust library, it's only going to be useful to Rust projects. With Rust I don’t even know if it’s possible to make borrow checking work across a language boundary. And Rust doesn't have a stable ABI, so even if you make a DLL, it’ll only work if compiled with the exact same compiler version. *sigh*

aw1621107 11mo ago
The reason you rarely hear that mentioned is because basically every programming language is hard to work with from other languages. The usual solution is to "just" expose a C API/ABI. Of course, C API/ABIs aren't able to make full use of Rust features, but again, that also applies to basically every other language.
sophacles 11mo ago
Perhaps we can finally stop defining abis in terms of c structs!
- qwm 11mo ago
  If only Rust had a spec to do that with
  - sophacles 11mo ago
    I don't think they should be defined in terms of any programming language. They should be defined in terms of the architecture - bits, bytes, words and instructions, along with semantics of use. Like we do with networking protocols and file formats.
  - steveklabnik 11mo ago
    It's being worked on! https://github.com/rust-lang/rfcs/pull/3470 https://github.com/rust-lang/rfcs/pull/3470