3 ms·

Why not write the code in C# (for example) and extract it to $SYSTEM_PROGRAMMING_LANGUAGE? It wouldn't be much different than what Xamarin are doing now for cre

Why not write the code in C# (for example) and extract it to $SYSTEM_PROGRAMMING_LANGUAGE? It wouldn't be much different than what Xamarin are doing now for creating iOS and Android apps with C#.

est 13y ago
Because if you write that in C#, you have to bundle 54MB common runtime and GC withit.
- profquail 13y ago
  Did you actually read my entire comment, or did you just see "C#" and post a knee-jerk reaction? If you extract code from C# to C, you don't need a GC or any of the .NET class libraries -- you'd just have a standalone C file to use like any other.
  - est 13y ago
    > If you extract code from C# to C, you don't need a GC or any of the .NET class libraries The problem is, you do need them. There's no 1:1 C# -> C extraction. You have to extract at least some part of the CLR along with.
    - scott_s 13y ago
      Perhaps another way of saying this is that you will always need a runtime. And if you reimplement the portions of the runtime that you need in C, you've essentially re-implemented .NET.
pbsd 13y ago
Using C as an output language, backed by guarantees at the higher level, could certainly work. I believe ATS [1] works this way, and can even avoid garbage collection altogether if desired. I understand it is not an easy language, though. Nimrod [2] also generates C, but as I understand it garbage collection is unavoidable. [1] http://www.ats-lang.org/ http://www.ats-lang.org/ [2] http://nimrod-lang.org/ http://nimrod-lang.org/
- comex 13y ago
  This is one reason I'd like to see the removed LLVM C backend brought back and modernized, with Rust as the source language. Rust is safe, has no mandatory garbage collector, and has a much lower impedance mismatch with C or C++ than most higher level languages, so it should work well for libraries that are expected to integrate with C code.
  - stormbrew 13y ago
    > removed LLVM C backend What are you referring to here?
    - Athas 13y ago
      LLVM used to have a backend that could convert its low-level bitcode to portable C.
  - andrewaylett 13y ago
    I'm not clear why you'd want to compile your rust down to C, only to then compile that C again? Surely you're better off with a single compiler invocation, and taking rust straight to object code? I know that historically it's been easier to write a code generator than a compiler backend, but with LLVM you get the backend just as cheaply as the code gen.
    - lmb 13y ago
      Makes it easier to target embedded arches. For example, LLVM doesn't target the MSP430 from TI, but there is a gcc fork for it. Sure, you can write a new backend for LLVM, but that's a whole different ballgame. This way it would be Rust -> LLVM IR -> C -> GCC for MSP430.

Why not write the code in C# (for example) and extract it to $SYSTEM_PROGRAMMING_LANGUAGE? It wouldn't be much different than what Xamarin are doing now for creating iOS and Android apps with C#.

est 13y ago

Because if you write that in C#, you have to bundle 54MB common runtime and GC withit.

profquail 13y ago
Did you actually read my entire comment, or did you just see "C#" and post a knee-jerk reaction? If you extract code from C# to C, you don't need a GC or any of the .NET class libraries -- you'd just have a standalone C file to use like any other.
- est 13y ago
  > If you extract code from C# to C, you don't need a GC or any of the .NET class libraries The problem is, you do need them. There's no 1:1 C# -> C extraction. You have to extract at least some part of the CLR along with.
  - scott_s 13y ago
    Perhaps another way of saying this is that you will always need a runtime. And if you reimplement the portions of the runtime that you need in C, you've essentially re-implemented .NET.

pbsd 13y ago

Using C as an output language, backed by guarantees at the higher level, could certainly work. I believe ATS [1] works this way, and can even avoid garbage collection altogether if desired. I understand it is not an easy language, though. Nimrod [2] also generates C, but as I understand it garbage collection is unavoidable. [1] http://www.ats-lang.org/ http://www.ats-lang.org/ [2] http://nimrod-lang.org/ http://nimrod-lang.org/

comex 13y ago
This is one reason I'd like to see the removed LLVM C backend brought back and modernized, with Rust as the source language. Rust is safe, has no mandatory garbage collector, and has a much lower impedance mismatch with C or C++ than most higher level languages, so it should work well for libraries that are expected to integrate with C code.
- stormbrew 13y ago
  > removed LLVM C backend What are you referring to here?
  - Athas 13y ago
    LLVM used to have a backend that could convert its low-level bitcode to portable C.
- andrewaylett 13y ago
  I'm not clear why you'd want to compile your rust down to C, only to then compile that C again? Surely you're better off with a single compiler invocation, and taking rust straight to object code? I know that historically it's been easier to write a code generator than a compiler backend, but with LLVM you get the backend just as cheaply as the code gen.
  - lmb 13y ago
    Makes it easier to target embedded arches. For example, LLVM doesn't target the MSP430 from TI, but there is a gcc fork for it. Sure, you can write a new backend for LLVM, but that's a whole different ballgame. This way it would be Rust -> LLVM IR -> C -> GCC for MSP430.