4 ms·

A rust -> C compiler would be really nice for those custom/slow updating environments, but I can understand if that just too much of a distraction.

• steveklabnik 10y ago
  Since I got two replies with basically the same thing at the same time, I'll pick one at random and it'll serve as a reply to both. You won the coin flip :) This is feasible in a sense, but C is a fairly tricky target to compile to: you have to make sure that you don't accidentally include UB in the code you generate. I know pcwalton has lots of feels here... The easiest way to do it would be if LLVM had a C backend; I know that it did, but it was removed a few years back, and I haven't heard anything about it coming back into tree yet. MIR might also in theory enable new backends, but then you'd have to re-implement all of the optimizations that we currently rely on LLVM supplying.
  • ihnorton 10y ago
    > I know that it did, but it was removed a few years back, and I haven't heard anything about it coming back into tree yet. (out-of-tree) fork(s) have been kept alive by several groups. The most current one I'm aware of is: https://github.com/JuliaComputing/llvm-cbe https://github.com/JuliaComputing/llvm-cbe
  • ArkyBeagle 10y ago
    I'll just say - I've generated A Great Deal of 'C' code. It's not hard to avoid UB at all. You only use a very concise subset of the language. YMMV. This sounds more like generating 'C' is a distraction rather than a goal.
    • steveklabnik 10y ago
      It is certainly not impossible. I think it's just presented as a bit more trivial than it is. You can generate C, but is it easy to generate good C? That's what I was trying to get at with the LLVM comments. Rust relies a lot on a good optimizer; a straightforward transformation might be significantly slower.
      • ArkyBeagle 10y ago
        Agreed. I did not mean to minimize the effort involved.