4 ms·

I am serious, but as you observed I also did not quite address your specific use case. Rust as-is with it's LLVM backend and lack of runtime has a clear path fo

by brson 11y ago

I am serious, but as you observed I also did not quite address your specific use case. Rust as-is with it's LLVM backend and lack of runtime has a clear path forward for anything LLVM can target (which is a lot now, and will be more in the future). This should get us into many platforms. The compile-to-C case is the most straightforward of the three you mention, but also the one I'm most skeptical of. I do understand that there are some venerable old and/or small platforms where C is the only option. I don't know any specific examples of what people want to do by transpiling to C though. The only thing I know with any certainty is '8-bit microcontrollers', and this is one case that Rust is likely to be a tough fit for (largely because it wants pointer-sized things to be 'big enough', as well as other reasons I've forgotten). Still, if it's necessary, it can be done with great effort (see the perennially broken LLVM C backend), but it's very low priority as of now. I'm not sure yet the role of a JVM/.NET backend for Rust (besides the coolness factor) and I don't think people have put a great deal of thought into it. What we will have though is easy ways to bridge between the managed runtimes and Rust for accelerating your managed code or binding to system APIs. This will be necessary for creating decent Android/Windows environments. (On the .NET topic a MSIL backend would also get us non-asm.js JS via [JSIL](http://www.jsil.org/ http://www.jsil.org/) which would give Rust access to the DOM. This is quite a flight of fancy though).

yazaddaruvala 11y ago
I think more than a C backend, LLVM needs "C as an IR". Which LLVM can internally use to "trivially" add support for embedded-type platforms that only have a C compiler. That is what most people want it for anyways.
- mackwic 11y ago
  Backend is the correct term: C is by no mean an IR which means "intermediate representation", from which you can more or less easily understand the thing behind the code (eg: types, control flow, variable bindings). An IR is a data-structure that obey some rules, a C file is flat text that needs parsing. Not the same. If C is the output of the compiler, then we speak of a C Backend, which means the part that transform the final IR in the other language we want to translate to (eg: x86, arm6, sparc, ... C :) As a final note, it's likely that platforms so conservatives that they only provide a C ansi compiler, will not be aroused by Rust.
  - ectoplasm 11y ago
    You could reasonably do some for loop stuff using a C AST as your IR if you wanted. Not really sure why you would do this if coming from another language, but you could.

by brson 11y ago

yazaddaruvala 11y ago

I think more than a C backend, LLVM needs "C as an IR". Which LLVM can internally use to "trivially" add support for embedded-type platforms that only have a C compiler. That is what most people want it for anyways.

mackwic 11y ago
Backend is the correct term: C is by no mean an IR which means "intermediate representation", from which you can more or less easily understand the thing behind the code (eg: types, control flow, variable bindings). An IR is a data-structure that obey some rules, a C file is flat text that needs parsing. Not the same. If C is the output of the compiler, then we speak of a C Backend, which means the part that transform the final IR in the other language we want to translate to (eg: x86, arm6, sparc, ... C :) As a final note, it's likely that platforms so conservatives that they only provide a C ansi compiler, will not be aroused by Rust.
- ectoplasm 11y ago
  You could reasonably do some for loop stuff using a C AST as your IR if you wanted. Not really sure why you would do this if coming from another language, but you could.