4 ms·
This is the sort of opinion that evaporates once you become the victim of what’s happening here. IMO Rust should have a C backend, then the maintainers could d
by CyberRabbi 6y ago
This is the sort of opinion that evaporates once you become the victim of what’s happening here.
IMO Rust should have a C backend, then the maintainers could drop it as a build dependency and not break existing platforms. Though I expect there to be political reasons for Rust’s conspicuous lack of a C backend.
- correct_horse 6y agoLLVM had a C backend which went unmaintained until the Julia folks picked it up and updated it for LLVM 10. I'm not sure about its current state.
- deleted 6y ago[deleted]
- pornel 6y agoThere's mrustc which compiles Rust to C. Rustc itself supports two back-ends now (LLVM and cranelift), so more should be possible if someone wanted to contribute and maintain them. I don't think there's any ideological opposition to having more back-ends. It's just a huge amount of work, and is lacking volunteers, especially for niche platforms.
- CyberRabbi 6y agoThe amount of work doesn’t seem to be the limiting factor. Rewriting large amounts of C code into Rust is a lot of work too but that doesn’t stop Rust justice warriors from doing that.
- pca006132 6y agoI think there are alternative implementations that are (much) less mature than rustc. And I wonder if using those implementations would be good for a project, that requires security...
- moosingin3space 6y agoFor one, respected community member pcwalton has argued against compiling to C, citing the difficulty in producing performant, memory-safe output. For another, from personal experience, I can comment that compiling to C in such a way that doesn't leak abstractions left and right is quite challenging. It's pretty hard to produce memory-safe C, so it's a ton of work, and the payoff is pretty marginal, as the most important platforms already are supported by LLVM.
- CyberRabbi 6y agoAutomatically generating “memory safe” C is no harder than automatically generating “memory safe” LLVM bitcode.
- brundolf 6y agoI think the issue is all of C's undefined behavior
- ghoward 6y agoFor the most part, that can be worked around as well, with careful use of unsigned arithmetic. See https://git.yzena.com/Yzena/Yc/src/branch/master/include/yc/arith.h https://git.yzena.com/Yzena/Yc/src/branch/master/include/yc/... for some examples. All arithmetic is unsigned, but I use it to simulate 2's complement signed.
- CyberRabbi 6y agoThat is not difficult to avoid if you are generating short primitives. You can for the most part just convert the LLVM bitcode that the Rust compiler would output to the equivalent C snippet. Since each snippet is short, you can trivially check if it invokes undefined behavior. LLVM bitcode also can exhibit undefined behavior.
- moosingin3space 6y ago> You can for the most part just convert the LLVM bitcode that the Rust compiler would output to the equivalent C snippet. Sounds like a good argument to resurrect the LLVM C backend. As it stands, the Rust core team has no desire to implement a C backend, as it would be a ton of work for not much gain.
- phkahler 6y ago>> IMO Rust should have a C backend, then the maintainers could drop it as a build dependency and not break existing platforms. That's a lot of work you expect from people developing a language you don't even want to use.
- CyberRabbi 6y agoI expect nothing, it is a casual opinion. You’re projecting.