Rust compiles to LLVM IR. I'm pretty surprised that building this transpiler was considered a better use of time than writing an LLVM backend for whatever "weird embedded target" might need this.
Sometimes you may need to deal with odd proprietary processors with limited and flawed knowledge about them.
For example, in the 37c3 talk "Breaking "DRM" in Polish trains" by the folks from Dragon Sector (I highly recommend watching it), they needed to reverse-engineer Tricore binaries, however they found the Ghidra implementation had bugs.
As for the PLCs, the IEC 61131-3 functional block diagrams transpile to C code which then compiles to Tricore binaries using an obscure GCC fork. Not saying that anyone would want to write Rust code for PLCs, but this is not uncommon in the world of embedded.
In fact there used to be a C backend for LLVM, but it was removed in LLVM 3.1 [0]. JuliaHub has resurrected it as a third-party backend [1], though I have no idea if there is any interest in upstreaming the work from either end.
If you write a library in Rust and want to make that library available to other language ecosystems, not requiring a Rust compiler toolchain for using the library is a pretty big plus - instead create a C source distribution of the library, basically using C as the cross-platform intermediate format.
The project itself is cool and useful but the motivating example of crypto (primitives?) isn't great.
Cryptography is already difficult to write in high level languages without introducing side channels via timing, branch predictor, caches etc.
Cryptography while going through two high level compilers, especially when the code was not designed and written to do so is an exercise fraught with peril.
Tbf, this is just nitpicking about the article, not the project itself
Correct me if I am wrong, but C is the “greatest common denominator” for several decades already. Java, .NET, go, Rust are very much ecosystems-in-themselves. From the practical standpoint, they can not use each other’s code, but they all can use C libs.
Technically it's only the C API that's important, the implementation behind the C API can be written in any language. The downside is though that you still need a language toolchains X, Y, Z to compile the implementations. Transpiling everything to C removes that one dimension from the build process.
Until specific industry standards like POSIX, all Khronos APIs, UNIX like systems get rewriten into something else, it is going to stay around.
Hence why it should be a priority for WG14 to actually improve C's safety as well, unfortunately most members don't care, otherwise we would at least already have either fat pointers, or libraries like SDS on the standard by now.
In 1983, AT&T released the fifth version of Unix, called "System V". Part of the release was an ABI specification for how the different parts of the system would talk to one another. Notably, the main portion of the spec described portable things like the file-format of executables, and the details for each supported platform were described in appendixes.
The SysV ABI is still used to this day, although the specification itself has withered until only two chapters remain[1], and CPU vendors still publish "System V ABI appendix" documents for platforms that System V's authors could not have dreamed of[2].
C as an interface is going to be around for a very long time, like POSIX and OpenGL and the SysV ABI standard. C as an actual language might not - it might wind up as a set of variable types that other languages can map into and out of, like what happened to the rest of the SysV ABI specification.
You mean everywhere. It's just hidden behind abstraction layers or Fortran libraries like BLAS/LAPACK, which are used by NumPy, R, Julia, MATLAB, Excel, TensorFlow, PyTorch (for some backends), and basically anything that involves linear algebra.
> I currently have no reason to believe C won't outlive it, by a lot.
My reaction is kind of: "So what?" I really don't care about the relative lives of languages and don't really understand why anyone would. Unless I am wrong, there is still lots of COBOL we wish wasn't COBOL? And that reality doesn't sound like a celebration of COBOL?
IMHO it would be completely amazing if magically something 10x better than Rust came along tomorrow, and I'd bet most Rust people would agree. Death should be welcomed after a well lived life.
To me, the more interesting question is -- what if efforts like c2rust, Eurydice, TRACTOR and/or LLMs make translations more automatic and idiomatic? Maybe C will exist, but no one will be "writing" C in 20 years? Perhaps C persists like the COBOL zombie? Perhaps this zombification is a fate worse than death? Perhaps C becomes like Latin. Something students loath and are completely bored with, but are forced to learn simply as the ancient interface language for the next millennia.
Is that winning? I'd much rather people were excited about tech/a language/a business/vibrant community, than, whatever it is, simply persisted, and sometimes I wish certain C people could see that.
I plan to be writing C for the next decades even for new projects, because I think it is a great language, and I appreciate its simplicity, fast compilation times, stability, and portability.
I am happy if people are excited about Rust, but I do not like it too much myself. Although I acknowledge that it contains good ideas, it also has many aspects I find problematic and which why I do not think we should all switch to it as a replacement for C.
Mostly the advantages a listed for C: stability, portability, simplicity, fast compilation times could all in reverse also be considered disadvantages of Rust. I am also not a fan of monomorphization, not of static linking, and not of having many dependencies out of a large uncurated pile of many projects. I also think Rust is not pragmatic enough. Overall though, my main issue is complexity of the language which I think goes in the wrong direction. At the same time I think the advantages of Rust are exaggerated. I still agree memory safety is important, I just think Rust is not an ideal approach.
C will end when our entire technological civilization collapses and has to start over from scratch and even then after a century of progress they will invent C again.
> COBOL has enough business money around to get new tools and ISO standards[0], so it is unlikley to think otherwise regarding C.
I don't think you understand my point. I am explicitly saying "C will definitely survive (like COBOL)". I am asking is that the kind of life people want for C?
Ideally we would have moved on into some Assembly glue + compiled managed high level languages by now, like Xerox PARC when then moved away from BCPL into Smalltalk, Interlisp-D, Mesa and Mesa/Cedar, but some folks and industry standards cannot let go of C, and those have to contend with that kind of life for C, exactly.
Honestly I'd be a bit disappointed if something better came along tomorrow. Just as we as an industry spent all this effort moving to Rust something better comes along? Lame. Obviously I want better languages to come out, but I'd either want a bit of warning or a slower pace so we as an industry don't totally "waste" tons of time on transitioning between short-lived languages. Thankfully languages need about 10 years to mature from 0.1 to production readiness, and industry happily ignores marginally (and moderately) better languages than what they're using, so this is not a realistic issue.
> Honestly I'd be a bit disappointed if something better came along tomorrow.
You'd be disappointed if something 10x better came along tomorrow? I suppose you would you also be disappointed if magically we had economical fusion power, because you own utility stocks? Or we invented 10x better new car, because you already own an old car?
Of course the world wouldn't immediately move to one thing or the other, etc., and we'd still have a 10x better thing?
> Obviously I want better languages to come out, but I'd either want a bit of warning or a slower pace
The purpose of this thought experiment is to say -- it's perfectly fine for things to live and die, if they must. We've had a second Cambrian period for PLs. It's perfectly alright if some don't live forever, including Rust, which I really like.
In my thought experiment, Rust and C could also accept this new paradigm, and adapt, and perhaps become 10x better themselves. Though this is something heretofore C/C++ haven't done very well. IMHO new things don't preclude old things, and there mustn't be only one winner.
> Thankfully languages need about 10 years to mature from 0.1 to production readiness, and industry happily ignores marginally (and moderately) better languages
Which my thought experiment did as well? Read: This is a 10x improvement!
Oops, skipped the 10x part. If it's really 10x better that would indeed be amazing. That's basically the leap from C to Rust in domains that C is not good at.
Neither needs to outlive the other to be individually useful.
The way I see it, the longer something is actively used, the greater the chance it’s going to stick around. I’m bullish on rust but I’m equally bullish that C will last a long, long time.
But it’s not an either-or here. Both are good at certain things and can coexist. Like they’re coexisting in the Linux kernel for example.
You can use both Nix and Cargo at the same time, and they accomplish different things. Nix's purpose is more like rustup, except it works for each program on your computer
By default, this is only in debug mode. I recently forgot to add it to release mode on a project, and was surprised when I broke the CI (tests run in debug, I only tested in release mode).
In a world where Crabs are trying to rewrite everything in their favourite Crab Speak its nice to see the Reverse. I wonder if it coulkd be used to translate Rust compiler itself to C :-D
They want to use rust but can't, because they need C compatibility, e.g. because they're providing a library or wants to support platforms that rust don't.
It's at least a less bad idea than I expected originally – I've mainly seen people try to use transpilers to sneakily start using the language they prefer as part of a larger code base, with all the obvious problems.
It's still not great as you now have an additional translation step to deal with. You will at some point need to look for bugs in the generated C layer, which will really suck. Users of the C library can't read your source to understand what it does internally without an extra step to figure out what rust code the thing they use corresponds to, etc.
If you want to provide a C library, write C. If rust isn't an option because it doesn't work for your customers who use C, don't use rust.
You can write a C-compatible binary library in Rust (see the cdylib target) and cbindgen can then generate proper C header files for any C-ABI interfaces exposed in Rust code. A full Rust-to-C compiler should only be needed for targets that have some C compiler available but are just not supported by the current Rust toolchain.
When you think about it, Perseus did use Medusa's head to transform things into stone.
In fact he turned king Polydectes and all of his followers into stone when he went back to Sephiros.
Perseus defeated Medusa by not looking at her in the eyes.
Rust in a sense, allow you to solve problems without having to look directly at memory unsafe behavior.
I would have called this project "Medusa".
Rust compiles to LLVM IR. I'm pretty surprised that building this transpiler was considered a better use of time than writing an LLVM backend for whatever "weird embedded target" might need this.
Sometimes you may need to deal with odd proprietary processors with limited and flawed knowledge about them.
For example, in the 37c3 talk "Breaking "DRM" in Polish trains" by the folks from Dragon Sector (I highly recommend watching it), they needed to reverse-engineer Tricore binaries, however they found the Ghidra implementation had bugs.
As for the PLCs, the IEC 61131-3 functional block diagrams transpile to C code which then compiles to Tricore binaries using an obscure GCC fork. Not saying that anyone would want to write Rust code for PLCs, but this is not uncommon in the world of embedded.
In fact there used to be a C backend for LLVM, but it was removed in LLVM 3.1 [0]. JuliaHub has resurrected it as a third-party backend [1], though I have no idea if there is any interest in upstreaming the work from either end.
[0]: https://releases.llvm.org/3.1/docs/ReleaseNotes.html
[1]: https://releases.llvm.org/3.1/docs/ReleaseNotes.html
If you write a library in Rust and want to make that library available to other language ecosystems, not requiring a Rust compiler toolchain for using the library is a pretty big plus - instead create a C source distribution of the library, basically using C as the cross-platform intermediate format.
Rustc supports backends other than LLVM btw
This would cover many different weird embedded targets, and a lot of those targets can be an utter pain to target with a compiler.
The project itself is cool and useful but the motivating example of crypto (primitives?) isn't great.
Cryptography is already difficult to write in high level languages without introducing side channels via timing, branch predictor, caches etc.
Cryptography while going through two high level compilers, especially when the code was not designed and written to do so is an exercise fraught with peril.
Tbf, this is just nitpicking about the article, not the project itself
I use Rust and C at work. I quite enjoy Rust, but I currently have no reason to believe C won't outlive it, by a lot.
Correct me if I am wrong, but C is the “greatest common denominator” for several decades already. Java, .NET, go, Rust are very much ecosystems-in-themselves. From the practical standpoint, they can not use each other’s code, but they all can use C libs.
Technically it's only the C API that's important, the implementation behind the C API can be written in any language. The downside is though that you still need a language toolchains X, Y, Z to compile the implementations. Transpiling everything to C removes that one dimension from the build process.
Until specific industry standards like POSIX, all Khronos APIs, UNIX like systems get rewriten into something else, it is going to stay around.
Hence why it should be a priority for WG14 to actually improve C's safety as well, unfortunately most members don't care, otherwise we would at least already have either fat pointers, or libraries like SDS on the standard by now.
In 1983, AT&T released the fifth version of Unix, called "System V". Part of the release was an ABI specification for how the different parts of the system would talk to one another. Notably, the main portion of the spec described portable things like the file-format of executables, and the details for each supported platform were described in appendixes.
The SysV ABI is still used to this day, although the specification itself has withered until only two chapters remain[1], and CPU vendors still publish "System V ABI appendix" documents for platforms that System V's authors could not have dreamed of[2].
C as an interface is going to be around for a very long time, like POSIX and OpenGL and the SysV ABI standard. C as an actual language might not - it might wind up as a set of variable types that other languages can map into and out of, like what happened to the rest of the SysV ABI specification.
[1]: https://www.sco.com/developers/gabi/latest/contents.html
[2]: https://wiki.osdev.org/System_V_ABI#Documents
The C ABI will definitely stick around. That doesn't necessarily mean C will. (Though it probably will have a very drawn-out death.)
And I think Zig will gradually eat a large piece of the C pie that would otherwise be eaten by Rust.
Jai is also on the que
¿Que jai?
I doubt it, unless it sorts out its use after free issues, embraces binary distribution used in commercial world, and gets adoption by an OS vendor.
Well, Fortran is still used somewhere too
You mean everywhere. It's just hidden behind abstraction layers or Fortran libraries like BLAS/LAPACK, which are used by NumPy, R, Julia, MATLAB, Excel, TensorFlow, PyTorch (for some backends), and basically anything that involves linear algebra.
> I currently have no reason to believe C won't outlive it, by a lot.
My reaction is kind of: "So what?" I really don't care about the relative lives of languages and don't really understand why anyone would. Unless I am wrong, there is still lots of COBOL we wish wasn't COBOL? And that reality doesn't sound like a celebration of COBOL?
IMHO it would be completely amazing if magically something 10x better than Rust came along tomorrow, and I'd bet most Rust people would agree. Death should be welcomed after a well lived life.
To me, the more interesting question is -- what if efforts like c2rust, Eurydice, TRACTOR and/or LLMs make translations more automatic and idiomatic? Maybe C will exist, but no one will be "writing" C in 20 years? Perhaps C persists like the COBOL zombie? Perhaps this zombification is a fate worse than death? Perhaps C becomes like Latin. Something students loath and are completely bored with, but are forced to learn simply as the ancient interface language for the next millennia.
Is that winning? I'd much rather people were excited about tech/a language/a business/vibrant community, than, whatever it is, simply persisted, and sometimes I wish certain C people could see that.
I plan to be writing C for the next decades even for new projects, because I think it is a great language, and I appreciate its simplicity, fast compilation times, stability, and portability.
I am happy if people are excited about Rust, but I do not like it too much myself. Although I acknowledge that it contains good ideas, it also has many aspects I find problematic and which why I do not think we should all switch to it as a replacement for C.
>it also has many aspects I find problematic
Could you share those?
Not trying to argue, just curious on the perspective of a C veteran, as someone who’s just starting with lower level languages.
Mostly the advantages a listed for C: stability, portability, simplicity, fast compilation times could all in reverse also be considered disadvantages of Rust. I am also not a fan of monomorphization, not of static linking, and not of having many dependencies out of a large uncurated pile of many projects. I also think Rust is not pragmatic enough. Overall though, my main issue is complexity of the language which I think goes in the wrong direction. At the same time I think the advantages of Rust are exaggerated. I still agree memory safety is important, I just think Rust is not an ideal approach.
I bet that C won't just be around for legacy projects, but also for writing new code for at least the next 30 years.
C will end when our entire technological civilization collapses and has to start over from scratch and even then after a century of progress they will invent C again.
Hopefully not. C is a bad language even for the standard of the times it was invented in.
COBOL has enough business money around to get new tools and ISO standards[0], so it is unlikley to think otherwise regarding C.
https://www.rocketsoftware.com/en-us/products/cobol/visual-c...
[0] ISO COBOL 2023 - https://www.iso.org/standard/74527.html
> COBOL has enough business money around to get new tools and ISO standards[0], so it is unlikley to think otherwise regarding C.
I don't think you understand my point. I am explicitly saying "C will definitely survive (like COBOL)". I am asking is that the kind of life people want for C?
Ideally we would have moved on into some Assembly glue + compiled managed high level languages by now, like Xerox PARC when then moved away from BCPL into Smalltalk, Interlisp-D, Mesa and Mesa/Cedar, but some folks and industry standards cannot let go of C, and those have to contend with that kind of life for C, exactly.
Honestly I'd be a bit disappointed if something better came along tomorrow. Just as we as an industry spent all this effort moving to Rust something better comes along? Lame. Obviously I want better languages to come out, but I'd either want a bit of warning or a slower pace so we as an industry don't totally "waste" tons of time on transitioning between short-lived languages. Thankfully languages need about 10 years to mature from 0.1 to production readiness, and industry happily ignores marginally (and moderately) better languages than what they're using, so this is not a realistic issue.
> Honestly I'd be a bit disappointed if something better came along tomorrow.
You'd be disappointed if something 10x better came along tomorrow? I suppose you would you also be disappointed if magically we had economical fusion power, because you own utility stocks? Or we invented 10x better new car, because you already own an old car?
Of course the world wouldn't immediately move to one thing or the other, etc., and we'd still have a 10x better thing?
> Obviously I want better languages to come out, but I'd either want a bit of warning or a slower pace
The purpose of this thought experiment is to say -- it's perfectly fine for things to live and die, if they must. We've had a second Cambrian period for PLs. It's perfectly alright if some don't live forever, including Rust, which I really like.
In my thought experiment, Rust and C could also accept this new paradigm, and adapt, and perhaps become 10x better themselves. Though this is something heretofore C/C++ haven't done very well. IMHO new things don't preclude old things, and there mustn't be only one winner.
> Thankfully languages need about 10 years to mature from 0.1 to production readiness, and industry happily ignores marginally (and moderately) better languages
Which my thought experiment did as well? Read: This is a 10x improvement!
Oops, skipped the 10x part. If it's really 10x better that would indeed be amazing. That's basically the leap from C to Rust in domains that C is not good at.
Neither needs to outlive the other to be individually useful.
The way I see it, the longer something is actively used, the greater the chance it’s going to stick around. I’m bullish on rust but I’m equally bullish that C will last a long, long time.
But it’s not an either-or here. Both are good at certain things and can coexist. Like they’re coexisting in the Linux kernel for example.
Cool. One should perhaps mention some prior art:
[0]: https://github.com/FractalFir/rustc_codegen_clr> We recommend using Nix to easily ensure you are running the right versions of the tools and libraries.
Ooof I remember when everything used to be like this. Cargo has really spoiled me.
You can use both Nix and Cargo at the same time, and they accomplish different things. Nix's purpose is more like rustup, except it works for each program on your computer
Can Cargo install deployment tools like Ansible? I find myself using nix for those kind of tools despite how good $lang package manager is.
Using nix to install Ansible, oof you're hurting me..
> for instance, Rust panics on integer overflow
By default, this is only in debug mode. I recently forgot to add it to release mode on a project, and was surprised when I broke the CI (tests run in debug, I only tested in release mode).
In a world where Crabs are trying to rewrite everything in their favourite Crab Speak its nice to see the Reverse. I wonder if it coulkd be used to translate Rust compiler itself to C :-D
https://github.com/Rust-GCC/gccrs/tree/master/gcc/rust
There's a Rust compiler in C++ in case that's any good to you
Github: https://github.com/AeneasVerif/eurydice
Cool, loved this! These tools would be needed in the near future to manage the tech debt safe rust is compounding.
Not saying it isn’t neat, but WHY?
Seems like the kind of thing that happens before a language is natively supported by a compiler.
They want to use rust but can't, because they need C compatibility, e.g. because they're providing a library or wants to support platforms that rust don't.
It's at least a less bad idea than I expected originally – I've mainly seen people try to use transpilers to sneakily start using the language they prefer as part of a larger code base, with all the obvious problems.
It's still not great as you now have an additional translation step to deal with. You will at some point need to look for bugs in the generated C layer, which will really suck. Users of the C library can't read your source to understand what it does internally without an extra step to figure out what rust code the thing they use corresponds to, etc.
If you want to provide a C library, write C. If rust isn't an option because it doesn't work for your customers who use C, don't use rust.
You can write a C-compatible binary library in Rust (see the cdylib target) and cbindgen can then generate proper C header files for any C-ABI interfaces exposed in Rust code. A full Rust-to-C compiler should only be needed for targets that have some C compiler available but are just not supported by the current Rust toolchain.
If you have an existing build system for your C project, you sure as hell don't want to bring another compiler toolchain (like Rust) into the mix.
If only the article started with an explanation...
There's literally a section named "Why?" in the article.
Rust compiler can be easily bootstrapped.
Another Rust compiler with a C backend:
https://github.com/thepowersgang/mrustc
The perfect headline to bring the anti-Rust luddites out of the woodwork...
So this means I can completely get rid of rust. Yay