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.

[0]: https://releases.llvm.org/3.1/docs/ReleaseNotes.html

[1]: https://releases.llvm.org/3.1/docs/ReleaseNotes.html

    rustc_codegen_clr is an experimental Rust compiler backend(plugin), which allows you to transpile Rust into .NET assemblies, or C source files.[0]

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

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.

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

I wonder if this is it's killer feature - compatibility with the C ABI.

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

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.

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.

https://www.rocketsoftware.com/en-us/products/cobol/visual-c...

[0] ISO COBOL 2023 - https://www.iso.org/standard/74527.html

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?

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!

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.

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

Ooof I remember when everything used to be like this. Cargo has really spoiled me.

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

There's a Rust compiler in C++ in case that's any good to you

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.

https://github.com/thepowersgang/mrustc