- 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.
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.
I think you may not be familiar with how embedded development works.
Most teams who write code for embedded devices (especially the weird devices at issue here) don't have the hardware knowledge, time, or contractual ability to write their own compiler backend. They're almost always stuck with the compiler the manufacturer decided to give them.
You're right. But I'm also surprised any device manufacturer would think it's a better use of their time to ship a bespoke C compiler rather than an LLVM backend that would allow a lot more languages to be built against their ISA, making it more valuable.
But ya, I believe this project exists for a meaningful purpose, I'm just surprised.
> But I'm also surprised any device manufacturer would think it's a better use of their time to ship a bespoke C compiler rather than an LLVM backend that would allow a lot more languages to be built against their ISA, making it more valuable.
They aren't usually building a compiler from scratch; they modify their existing compiler[1] for their new hardware, which is fractions of effort required compared to building a new compiler or modifying the LLVM backend.
Unless it's a completely new ISA, they'll spend an hour or less just adding in the new emit code for only the changes in the ISA.
----------------------------------
[1] Usually just the previous gcc that they used, which is why in 2022 I was working on brand new devices that came with a customised gcc 4.something
I think the approach would not be to alter the manufacturer's compiler directly, but to run your Rust code through a separate Rust-to-C compiler then feed that output into the compiler the manufacturer gave you.
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.
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.
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 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.
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"?
> 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.
This is fantastic, if you're still excited about C. However, the question I am asking also has to do with the social relational aspects of programming. Here, significantly, when we are talking about the lives of programming languages/decades, I think we should ask whether other people, and, importantly, industry, will be equally jazzed about yours and others C code, in the future. Are people still going to be happy to deal with all of C's problems when, perhaps, alternatives exist, and if, say, memory safety becomes cheaper, etc.?
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.
With LLMs becoming so good at coding, "just never make any mistake" is also becoming easier. I usually write my own code because I don't like the coding style of LLMs, but on more than one occasion now they have proven very useful as code reviewers and bug hunters.
We were talking about Rust issues. But yes, C should have a proper string type. But as long as it does not have a better standardized string type, it is possible to define your own (or use a library).
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.
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.
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.
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.
C is much closer to any other high level language than it is to assembly. 'Portable assembly' might have been true with trivial C compilers of the 70s and 80s, but not with compilers like gcc or clang.
> 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.
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.
> And to reiterate: C should finally be a real assembly language, something we not need to worry about.
Assembly is used quite a lot and if you're a programmer Assembly is very valuable to know _at least_ how to understand it.
I disagree, also, that C should go away. Saying it was never a good language is a bit harsh. It's a great language. One that industries are built on. I'd rather read/write C code than, say, Rust.
Edit:
There are, of course, languages coming up that can absolutely compete with C. Zig could be one when it's mature, for instance.
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.
If all Rust accomplishes is ushering some other better project, it would have been worth it.
I think it would take a while for that to happen, purely due to momentum' the same thing that makes some people think that Rust isn't being used will affect any younger language just as much, if not more.
I think that there's an easier language than Rust struggling to come out of it, but if Rust had been that easier language with different compromises, I doubt it would have gained critical mass that allowed it to get where it is today. Being fast and safe meant it carved a niche in a "free square" that drove it to have a clear differentiator that allowed it to gain an initial audience. I also suspect that it is easier toale a language fast and then evolve it to make it easier to use, than it is to make it easy to use first and then make it fast.
Note I ignored the 10x part. I'd find it a bit lame if a language came out that's 1.1x better than Rust because we're now in the awkward position of having rewritten lots of stuff in the second best language. However, should a 10x language come out you'll just have to swallow all that bitterness and start over because 10x is 10x.
Obviously a 1.1x language will come out - we don't just jump directly to 10x - and that's fine, fantastic even, but a little bit annoying when you're a language enthusiast and you've personally spent lots of time advocating for the now next-best language.
> 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.
Unfortunately, I really doubt long rust's "forever" will last in the wake of the `time` crate controversy. I can't see like a lot of good options in that place from the perspectives of the rust-std maintainers, but it might've just been worth it to wait for a new edition or similar.
There SO MUCH C++ out there that it won't ever be replaced. For one, Rust (or plain C) isn't a good choice for big applications (GUI, video games, web browsers, and many others) where classic OOP is so useful.
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 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
Cargo does not attempt to solve the same problems as Nix (if you depend on any software not written in Rust). A checked in Nix shell is genuinely great documentation on the expected system environment.
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.
IIRC C can do the same things with correct usage of `restrict`, but that's extremely difficult by hand. So difficult that LLVM's `restrict` support was very buggy when Rust first started using the capabilities. Those bugs got fixed, but it's still impractical to use in handwritten C.
C still has lifetime rules. It just has no syntax for them. What people are bitten with is that they violate the lifetime rules, but their compiler doesn't tell them.
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
Thanks
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 is some humor in the string
"Breaking "DRM" in Polish trains"
Why?
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.
I think you may not be familiar with how embedded development works.
Most teams who write code for embedded devices (especially the weird devices at issue here) don't have the hardware knowledge, time, or contractual ability to write their own compiler backend. They're almost always stuck with the compiler the manufacturer decided to give them.
You're right. But I'm also surprised any device manufacturer would think it's a better use of their time to ship a bespoke C compiler rather than an LLVM backend that would allow a lot more languages to be built against their ISA, making it more valuable.
But ya, I believe this project exists for a meaningful purpose, I'm just surprised.
> But I'm also surprised any device manufacturer would think it's a better use of their time to ship a bespoke C compiler rather than an LLVM backend that would allow a lot more languages to be built against their ISA, making it more valuable.
They aren't usually building a compiler from scratch; they modify their existing compiler[1] for their new hardware, which is fractions of effort required compared to building a new compiler or modifying the LLVM backend.
Unless it's a completely new ISA, they'll spend an hour or less just adding in the new emit code for only the changes in the ISA.
----------------------------------
[1] Usually just the previous gcc that they used, which is why in 2022 I was working on brand new devices that came with a customised gcc 4.something
I think the approach would not be to alter the manufacturer's compiler directly, but to run your Rust code through a separate Rust-to-C compiler then feed that output into the compiler the manufacturer gave you.
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).
this effectively writes a backend for all the weird targets at once, since pretty much everything out there has c compiler support
I have never seen any guides or blogs about writing LLVM backend
and considering how long compiling LLVM takes... it's reasonable to go for other options
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.
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.
It hardly makes a difference, regarding C's safety.
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.
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.
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.
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?
quec
Any moment now…
> 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.
> I plan to be writing C for the next decades
This is fantastic, if you're still excited about C. However, the question I am asking also has to do with the social relational aspects of programming. Here, significantly, when we are talking about the lives of programming languages/decades, I think we should ask whether other people, and, importantly, industry, will be equally jazzed about yours and others C code, in the future. Are people still going to be happy to deal with all of C's problems when, perhaps, alternatives exist, and if, say, memory safety becomes cheaper, etc.?
>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.
With LLMs becoming so good at coding, "just never make any mistake" is also becoming easier. I usually write my own code because I don't like the coding style of LLMs, but on more than one occasion now they have proven very useful as code reviewers and bug hunters.
We were talking about Rust issues. But yes, C should have a proper string type. But as long as it does not have a better standardized string type, it is possible to define your own (or use a library).
Absolutely. Even when I preferred C over C++ (a long time ago), it was "but with a string library".
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 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.
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 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.
> Portable assembly still has its uses obviously
C is much closer to any other high level language than it is to assembly. 'Portable assembly' might have been true with trivial C compilers of the 70s and 80s, but not with compilers like gcc or clang.
> Computers are multiple orders of magnitude faster, have multiple orders of magnitude more memory and storage
And C is still the best way to talk to the hardware in a portable way.
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.
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.
> And to reiterate: C should finally be a real assembly language, something we not need to worry about.
Assembly is used quite a lot and if you're a programmer Assembly is very valuable to know _at least_ how to understand it.
I disagree, also, that C should go away. Saying it was never a good language is a bit harsh. It's a great language. One that industries are built on. I'd rather read/write C code than, say, Rust.
Edit: There are, of course, languages coming up that can absolutely compete with C. Zig could be one when it's mature, for instance.
In my timeline, something 10x better than Rust came along in 1995.
Java? Delphi? Better at what?
Ada
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.
Manual memory management for anything beyond RAII.
I’d guess that’s a reference to Ada 95.
Yes
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.
If all Rust accomplishes is ushering some other better project, it would have been worth it.
I think it would take a while for that to happen, purely due to momentum' the same thing that makes some people think that Rust isn't being used will affect any younger language just as much, if not more.
I think that there's an easier language than Rust struggling to come out of it, but if Rust had been that easier language with different compromises, I doubt it would have gained critical mass that allowed it to get where it is today. Being fast and safe meant it carved a niche in a "free square" that drove it to have a clear differentiator that allowed it to gain an initial audience. I also suspect that it is easier toale a language fast and then evolve it to make it easier to use, than it is to make it easy to use first and then make it fast.
Note I ignored the 10x part. I'd find it a bit lame if a language came out that's 1.1x better than Rust because we're now in the awkward position of having rewritten lots of stuff in the second best language. However, should a 10x language come out you'll just have to swallow all that bitterness and start over because 10x is 10x.
Obviously a 1.1x language will come out - we don't just jump directly to 10x - and that's fine, fantastic even, but a little bit annoying when you're a language enthusiast and you've personally spent lots of time advocating for the now next-best language.
> 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.
COBOL is actively developed and maintained. It's far from being dead. Its working flawlessly and will be for the next few decades :)
I bet you never wrote single program in Cobol...
> COBOL is actively developed and maintained. It's far from being dead.
Who said it was dead? I was clear that I thought it was very much undead, like a zombie.
Unless something similar to but better than Rust comes along soon, I expect both Rust and C to live "forever".
Unfortunately, I really doubt long rust's "forever" will last in the wake of the `time` crate controversy. I can't see like a lot of good options in that place from the perspectives of the rust-std maintainers, but it might've just been worth it to wait for a new edition or similar.
Why do you believe that's going to have some sort of lasting effect on Rust?
I don't believe it'll have "lasting" effect on rust, but I think it rather shows what rust maintainers will do, if put into a similar situation again.
It also feels to me like Rust is trying to replace C++ more-so than C.
There SO MUCH C++ out there that it won't ever be replaced. For one, Rust (or plain C) isn't a good choice for big applications (GUI, video games, web browsers, and many others) where classic OOP is so useful.
Maybe "replace" was the wrong word. What I mean is that Rust is "a better C++" to a much greater extent than it is "a better C".
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.
> 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
Cargo does not attempt to solve the same problems as Nix (if you depend on any software not written in Rust). A checked in Nix shell is genuinely great documentation on the expected system environment.
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..
Cargo isn't intended for that. If there was something like Ansible implemented in Rust, then you could use Cargo to install it.
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".
author here; thanks for the suggestion, that'll be a cool name for my next project :-)
Github: https://github.com/AeneasVerif/eurydice
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.
IIRC C can do the same things with correct usage of `restrict`, but that's extremely difficult by hand. So difficult that LLVM's `restrict` support was very buggy when Rust first started using the capabilities. Those bugs got fixed, but it's still impractical to use in handwritten C.
C still has lifetime rules. It just has no syntax for them. What people are bitten with is that they violate the lifetime rules, but their compiler doesn't tell them.
There are multiple stages of IR in the compiler, basically
> 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.
Another Rust compiler with a C backend:
https://github.com/thepowersgang/mrustc
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.
[flagged]
The perfect headline to bring the anti-Rust luddites out of the woodwork...