- has designed the Mezzo programming language in his Ph.D. thesis and
- has worked on generating user-friendly C automatically. Most tools that generate C output pretty unreadable/unmaintainable code that you won't like to maintain, so this is a much under-researched topic.
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.
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.
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.
There are many kinds of IRs in compilers - I'm not familiar with how Rust works, but for example GCC has an intermediate representation called GENERIC, which is a C-like language that preserves the scoping and loops and branches of the inputted C code.
Lower level representations also exist - since C has goto, you can pretty much turn any SSA IR to C, but the end result won't be readable.
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.
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.
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.
Almost all non-C language offer that feature. The additional thing of the Zig toolchain is that it can also compile C/C++/ObjC projects without requiring a separate compiler toolchain, e.g. the Zig compiler toolchain is also a complete C/C++ compiler toolchain.
Almost all languages provide a method of calling C generated code for sure. But, as I understand it, this is usually a more tortuous path than straight ABI compatibility.
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.
C has never been a particularly good language, and is so good that finally (with tons of pushbacks!) there is an alternative that make the case so strong that is at least considered the possibility that will come the very happy day where C will be our past.
The only, true, real blocker is that C is the ABI. But if we consider the possibility that C can AND should be the past, then the C Abi can finally adds sophisticated things like Strings and such, and maybe dreaming, algebraic types (ie: the C will be improved with the required features so it can evolve the ABI, but not because will be a good language for write it (manually) on it).
And to reiterate: C should finally be a real assembly language, something we not need to worry about.
> 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.
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 - this may be ok if the alternative is C++, but if you prefer C to C++ then Rust is equally unappealing. 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.
Nowadays, not so much. Computers are multiple orders of magnitude faster, have multiple orders of magnitude more memory and storage and do things multiple orders of magnitude more complex than they used to. Portable assembly still has its uses obviously, but safer/easier/faster alternatives exist in all its niches.
I haven't ever had to do anything serious in C but it's hard to imagine getting it 100% right.
A while back I wrote some C code to do the "short-bread" problem (it's a bit of a tradition at work to give it to people as their first task, though in Python it's a lot easier). Implementing a deque using all of the modern guard rails and a single file unit test framework still took me a lot of attempts.
C isn't a bad language per-se, it just doesn't have an opinion on most things and I think that's exactly the reason why it survived many higher level (and more opinionated) languages that also already existed when C was created.
This is exactly right. The trend is towards comprehensive programming frameworks for convenient programming with batteries included. I hope this trend dies and we focus more on integration into the overall ecosystem again.
Sane, easily readable syntax and expressive semantics. Easy to learn. Very scalable. Suitability, by design, for low level systems programming, including microcontrollers. Suitability, by design, for
large, complex real-time applications. Easy to interface with C and other languages. Available as part of GCC. Stable and ongoing language evolution.
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.
Currently Zig has the same issues as Rust in this context, primarily depending on a compiler that's too complex for a single person to maintain if necessary.
But in Zig's case it seems there's a pretty good chance that will change if they're able to drop LLVM in the future.
You can create and link to shared objects and create statically or dynamically linked executables. What more could you want on "embracing binary distribution"?
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
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
It's not possible to correctly implement any cryptographic algorithms in any high-level language with an optimizing backend where timing is not considered an observable/perserved property. Currently this includes anything backed by LLVM or GCC, though there's a proposal to introduce such guarantees through a new builtin in LLVM https://github.com/llvm/llvm-project/pull/166702 though those could still be broken by post-build optimizers, like wasm.
You probably misunderstood. C can represent any program's semantics, since it's Turing-complete (modulo finite memory). C can't encode the lifetimes Rust uses, but those get erased during compilation to MIR. This takes MIR from rustc (where borrow checking has been completed and lifetime annotations erased) and outputs C with the same semantics. LLVM doesn't use tokens not produceable by C, but rustc does.
I think it's a reference to certain optimizations possible due to aliasing rules in Rust that are not possible (or maybe only "not straight forward", I'm not sure) in C. So a transpiled program while keeping its semantics might not still compile to equally optimized assembly.
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.
You'd need the Rust compiler toolchain anyway, just to do the Rust-to-C conversion step instead of compiling to a binary library? What would be the point? The C ABI is quite compatible across toolchains.
> You'd need the Rust compiler toolchain anyway, just to do the Rust-to-C conversion step instead of compiling to a binary library?
The Rust-to-C conversion would be done by the Rust library author (or more likely, some automated CI process) to create a C source code distribution of the Rust library.
The original author of the post also
- has designed the Mezzo programming language in his Ph.D. thesis and
- has worked on generating user-friendly C automatically. Most tools that generate C output pretty unreadable/unmaintainable code that you won't like to maintain, so this is a much under-researched topic.
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.
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
The refs are duplicated.
Ack, my bad. Can't edit the comment any more, unfortunately. Second ref is supposed to be to https://github.com/JuliaHubOSS/llvm-cbe
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.
There are many kinds of IRs in compilers - I'm not familiar with how Rust works, but for example GCC has an intermediate representation called GENERIC, which is a C-like language that preserves the scoping and loops and branches of the inputted C code.
Lower level representations also exist - since C has goto, you can pretty much turn any SSA IR to C, but the end result won't be readable.
Rustc supports backends other than LLVM btw
And someone has made (https://github.com/FractalFir/rustc_codegen_clr) a backend targeting C (alongside .NET/CIL).
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.
This would cover many different weird embedded targets, and a lot of those targets can be an utter pain to target with a compiler.
Cool. One should perhaps mention some prior art:
[0]: https://github.com/FractalFir/rustc_codegen_clrI 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.
Unless something similar to but better than Rust comes along soon, I expect both Rust and C to live "forever".
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
> Hence why it should be a priority for WG14 to actually improve C's safety as well
Sorry should have been more clear. I'm talking specifically about C89, or maybe C99.
The C ABI will definitely stick around. That doesn't necessarily mean C will. (Though it probably will have a very drawn-out death.)
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.
Zig has been in the news a lot recently but I haven't explored it much other than a few tech talks which seemed interesting.
I wonder if this is it's killer feature - compatibility with the C ABI.
> compatibility with the C ABI
Almost all non-C language offer that feature. The additional thing of the Zig toolchain is that it can also compile C/C++/ObjC projects without requiring a separate compiler toolchain, e.g. the Zig compiler toolchain is also a complete C/C++ compiler toolchain.
Almost all languages provide a method of calling C generated code for sure. But, as I understand it, this is usually a more tortuous path than straight ABI compatibility.
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.
yeah, this is the actual good mindset.
C has never been a particularly good language, and is so good that finally (with tons of pushbacks!) there is an alternative that make the case so strong that is at least considered the possibility that will come the very happy day where C will be our past.
The only, true, real blocker is that C is the ABI. But if we consider the possibility that C can AND should be the past, then the C Abi can finally adds sophisticated things like Strings and such, and maybe dreaming, algebraic types (ie: the C will be improved with the required features so it can evolve the ABI, but not because will be a good language for write it (manually) on it).
And to reiterate: C should finally be a real assembly language, something we not need to worry about.
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.
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 - this may be ok if the alternative is C++, but if you prefer C to C++ then Rust is equally unappealing. 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 strings (it's almost an exaggeration to say that C has strings) and "just never make any mistakes bro" based memory management come to mind.
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.
C was great... for the PDP-11.
Nowadays, not so much. Computers are multiple orders of magnitude faster, have multiple orders of magnitude more memory and storage and do things multiple orders of magnitude more complex than they used to. Portable assembly still has its uses obviously, but safer/easier/faster alternatives exist in all its niches.
I haven't ever had to do anything serious in C but it's hard to imagine getting it 100% right.
A while back I wrote some C code to do the "short-bread" problem (it's a bit of a tradition at work to give it to people as their first task, though in Python it's a lot easier). Implementing a deque using all of the modern guard rails and a single file unit test framework still took me a lot of attempts.
C isn't a bad language per-se, it just doesn't have an opinion on most things and I think that's exactly the reason why it survived many higher level (and more opinionated) languages that also already existed when C was created.
This is exactly right. The trend is towards comprehensive programming frameworks for convenient programming with batteries included. I hope this trend dies and we focus more on integration into the overall ecosystem again.
In my timeline, something 10x better than Rust came along in 1995.
Would you mind elaborating…?
Sane, easily readable syntax and expressive semantics. Easy to learn. Very scalable. Suitability, by design, for low level systems programming, including microcontrollers. Suitability, by design, for large, complex real-time applications. Easy to interface with C and other languages. Available as part of GCC. Stable and ongoing language evolution.
I’d guess that’s a reference to Ada 95.
Yes
Java? Delphi? Better at what?
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.
And I think Zig will gradually eat a large piece of the C pie that would otherwise be eaten by Rust.
Currently Zig has the same issues as Rust in this context, primarily depending on a compiler that's too complex for a single person to maintain if necessary.
But in Zig's case it seems there's a pretty good chance that will change if they're able to drop LLVM in the future.
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.
You can create and link to shared objects and create statically or dynamically linked executables. What more could you want on "embracing binary distribution"?
Jai is also on the que
Nowadays, a language without public implementation/documentation isn't going to get any actual adoption.
¿Que jai?
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.
> 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..
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
It's not possible to correctly implement any cryptographic algorithms in any high-level language with an optimizing backend where timing is not considered an observable/perserved property. Currently this includes anything backed by LLVM or GCC, though there's a proposal to introduce such guarantees through a new builtin in LLVM https://github.com/llvm/llvm-project/pull/166702 though those could still be broken by post-build optimizers, like wasm.
I was always told rust uses llvm tokens not produceable by c code to do its magic. Was I informed wrong?
You probably misunderstood. C can represent any program's semantics, since it's Turing-complete (modulo finite memory). C can't encode the lifetimes Rust uses, but those get erased during compilation to MIR. This takes MIR from rustc (where borrow checking has been completed and lifetime annotations erased) and outputs C with the same semantics. LLVM doesn't use tokens not produceable by C, but rustc does.
I think it's a reference to certain optimizations possible due to aliasing rules in Rust that are not possible (or maybe only "not straight forward", I'm not sure) in C. So a transpiled program while keeping its semantics might not still compile to equally optimized assembly.
There are multiple stages of IR in the compiler, basically
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".
Github: https://github.com/AeneasVerif/eurydice
> 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
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.
You'd need the Rust compiler toolchain anyway, just to do the Rust-to-C conversion step instead of compiling to a binary library? What would be the point? The C ABI is quite compatible across toolchains.
> You'd need the Rust compiler toolchain anyway, just to do the Rust-to-C conversion step instead of compiling to a binary library?
The Rust-to-C conversion would be done by the Rust library author (or more likely, some automated CI process) to create a C source code distribution of the Rust library.
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