8 ms·

Portability and interoperability are key in industry. I think all of the new languages are amazing these days. I am learning Rust, Clojure, Haskell, and many m

Portability and interoperability are key in industry. I think all of the new languages are amazing these days. I am learning Rust, Clojure, Haskell, and many more. Buy I can not use any of them at work. I'm in a position to influence teams of smart programmers, but the only language that I would be able to use would be one that fits in to the existing infrastructure, which is natively compiled shared libraries on esoteric unix platforms. So no LLVM. No JVM. No Haskell. I could possibly get away with a lisp or scheme that compiled portable C if I wanted. But that doesn't excite me as much. I would kill for a Rust to human-readable C++ transpiler. I think it could be used immediately by many. I may have to write one.

loup-vaillant 10y ago
Haskell used to have a C back-end. That philosophy could in principle be extended to anything.
- tluyben2 10y ago
  The problem is that usually not very human readable C comes out of it; to use something instead of your company's language of choice, unless you are the CTO or something else high up the ladder, would need to compile to the company's language and do it in a human readable way. Some Javascript 'transpilers' do that (I think Coffeescript?) but usually it really acts as a compiler and the idea is that no-one should need to read / use the source code that is emitted besides for running it.
  - jjnoakes 10y ago
    This is exactly it. This is why I think rust is a winner. I bet most rust code could be compiled to c++ very cleanly. You get rust's compiler with all of the safety checks, and you get the platform support of C++. It would be a dream.
  - loup-vaillant 10y ago
    > The problem is that usually not very human readable C comes out of it The x86 assembly or LLVM intermediate representation that comes out of most compiler is not very human readable, but I don't see anyone having any problem with it whatsoever. Readability of generated code was never the point of C using C as a back-end. The point is portability and tooling. By the way /u/jjnoakes can suggest fancy languages and compilers, if only they can generate native code on obscure platforms (I guess, something other than x86 and ARM). Generating C code (even utterly unreadable C code) would solve his problem.
    - jjnoakes 10y ago
      Remember, it isn't only the architecture. It is also the calling conventions and object/shared library/executable file format. All things that require work if I cross compile, but all things I get for free if I generate C or C++. I would prefer readable C or C++ as much as possible because it gives me debugability if the code generator goes wrong and it gives me an out if I want to move away from the language some day.
      - loup-vaillant 10y ago
        Well, there aren't many solution out of this hole. If you need another language, you might have to write (and control) the compiler yourself. As in, if the code generator (or anything else) goes wrong, you can correct it. <sarcasm> Now this might require a little bit more work. </sarcasm>
        jjnoakes 10y ago
        The solution I mentioned in my original post gets me out if this issue, as does the one in the article that this hn post is all about.
qznc 10y ago
I believe porting LLVM to esoteric Unix platforms would be easier than a C backend. Less fun though.
- jjnoakes 10y ago
  You do the work once for C or C++ and you can use rust anywhere forever. Or you port it every time you need a new platform.
- vmorgulis 10y ago
  Porting nothing is better.
  - jjnoakes 10y ago
    Sure. Port nothing and keep writing in suboptimal languages. It is what we do now. But does it hurt to strive for better? I don't think it does.
    - vmorgulis 10y ago
      Yes it is. For me, C as an intermediate vs LLVM language is a "worse is better" or "good enough" issue. LLVM is far more powerful but more complex. C is simpler and already works everywhere.
kibwen 10y ago
Note that Rust code can interoperate with other languages by exposing a C interface and having the host language call it as though it were C. There's no runtime to start up or anything, so to the host platform there's no discernible difference (though you may need some machinery in your build system). This is how Rust-written libraries have been integrated into Firefox (which is obviously still integrated into Firefox), and there are companies that have been using Rust to extend Ruby for years now.
- jjnoakes 10y ago
  Yep. I understand and this is why I could integrate rust right now into my products, module by module or object file by object file. I just need the compiler to run on my systems. Since it is written in rust, I either need it ported to my systems (too much work) or I need my rust code transpiled to C or C++ so I can build it myself (seems doable).
  - pcwalton 10y ago
    It's not doable. How do you deal with UB from signed overflow? How do you get proper debug info? How do you set the proper EH personality? There are no shortcuts to a proper implementation of Rust. Implement an LLVM backend for your architecture. It doesn't make sense for Rust to maintain a backend that is doomed to be forever broken in various ways.
    - jjnoakes 10y ago
      I answered your ub question elsewhere. Exceptions and debug info come from C++. I don't see the issues there yet, but perhaps I just don't have the right knowledge yet. Rust won't have to maintain the backend. Who said they would? They might choose to if it becomes useful - it would give them things they dint have now (C++ interoperability, and new platform support for almost free), but no one here asked them to maintain anything. I am also not sure what you mean by shortcuts or broken forever in various ways.
      - 10y ago
MustardTiger 10y ago
>I'm in a position to influence teams of smart programmers, but the only language that I would be able to use would be one that fits in to the existing infrastructure, which is natively compiled shared libraries on esoteric unix platforms. So, how does that prevent you from using natively compiled languages like haskell?
- jjnoakes 10y ago
  The Haskell compiler doesn't run on my systems, and it does not generate human readable C or C++ from my Haskell code.
  - MustardTiger 10y ago
    What systems are those? And why do you need "human readable C"? You said you needed it to work in a natively compiled shared library environment. You do not need to compile to C for that. But if you really want to do that for some reason, you can do it.
    - jjnoakes 10y ago
      I'd prefer it to be human readable because it helps in debugability if the code generator is broken (or we misunderstand some subtle semantics and want to look closer), and if I ever want to move away from the language in the future. Ignoring that, if I don't compile to C or C++, then I'm not sure how easy it will be to use. Are you suggesting Haskell can generate object files, shared objects, and binaries for my systems without compiling to C or C++ first? How would it get the file formats and calling conventions right? Can I specify them somehow to Haskell (doubtful)?
      - MustardTiger 10y ago
        >Are you suggesting Haskell can generate object files, shared objects, and binaries for my systems without compiling to C or C++ first? Of course, that's what ghc does by default. >How would it get the file formats and calling conventions right? The same way every other compiler does. What systems are we talking about?
jnbiche 10y ago
Your platform must be pretty esoteric indeed to not be an LLVM target. What are you targeting? Also, Rust is interoperable to the exact same extent C is. Making shared libraries exposing a C ABI is a snap.
- jjnoakes 10y ago
  Rust is interoperable. That's why I could use it. I just need the compiler to generate code I can build with my C or C++ toolchain, since there is no rust toolchain for my platforms.
sn9 10y ago
Have you looked at OCaml? [0] [0] https://en.wikipedia.org/wiki/OCaml#Features https://en.wikipedia.org/wiki/OCaml#Features
- jjnoakes 10y ago
  I am familiar with ocaml at a high level. I have written a few toy interpreters in it. The c code it generates is basically the ocaml bytecode interpreter and the bytecode of my program. Not what I was thinking of.
  - sn9 10y ago
    It also has a native code compiler and a foreign function interface.
    - jjnoakes 10y ago
      It can generate portable and human readable C? Can you link to some information about that?
      - loup-vaillant 10y ago
        Nothing of the sort. But on the platforms it compiles to, Ocaml can generate object files that look like they came from C. I use this feature right now to integrate a compiler in an otherwise C++ project. Here's a link to the FFI documentation: http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html But I run on Debian stable on x86-64. Not exactly an exotic platform.
        jjnoakes 10y ago
        Is this not the bytecode embedded in C which I mentioned above?
        loup-vaillant 10y ago

loup-vaillant 10y ago

Haskell used to have a C back-end. That philosophy could in principle be extended to anything.

tluyben2 10y ago
The problem is that usually not very human readable C comes out of it; to use something instead of your company's language of choice, unless you are the CTO or something else high up the ladder, would need to compile to the company's language and do it in a human readable way. Some Javascript 'transpilers' do that (I think Coffeescript?) but usually it really acts as a compiler and the idea is that no-one should need to read / use the source code that is emitted besides for running it.
- jjnoakes 10y ago
  This is exactly it. This is why I think rust is a winner. I bet most rust code could be compiled to c++ very cleanly. You get rust's compiler with all of the safety checks, and you get the platform support of C++. It would be a dream.
- loup-vaillant 10y ago
  > The problem is that usually not very human readable C comes out of it The x86 assembly or LLVM intermediate representation that comes out of most compiler is not very human readable, but I don't see anyone having any problem with it whatsoever. Readability of generated code was never the point of C using C as a back-end. The point is portability and tooling. By the way /u/jjnoakes can suggest fancy languages and compilers, if only they can generate native code on obscure platforms (I guess, something other than x86 and ARM). Generating C code (even utterly unreadable C code) would solve his problem.
  - jjnoakes 10y ago
    Remember, it isn't only the architecture. It is also the calling conventions and object/shared library/executable file format. All things that require work if I cross compile, but all things I get for free if I generate C or C++. I would prefer readable C or C++ as much as possible because it gives me debugability if the code generator goes wrong and it gives me an out if I want to move away from the language some day.
    - loup-vaillant 10y ago
      Well, there aren't many solution out of this hole. If you need another language, you might have to write (and control) the compiler yourself. As in, if the code generator (or anything else) goes wrong, you can correct it. <sarcasm> Now this might require a little bit more work. </sarcasm>
      - jjnoakes 10y ago
        The solution I mentioned in my original post gets me out if this issue, as does the one in the article that this hn post is all about.

qznc 10y ago

I believe porting LLVM to esoteric Unix platforms would be easier than a C backend. Less fun though.

jjnoakes 10y ago
You do the work once for C or C++ and you can use rust anywhere forever. Or you port it every time you need a new platform.
vmorgulis 10y ago
Porting nothing is better.
- jjnoakes 10y ago
  Sure. Port nothing and keep writing in suboptimal languages. It is what we do now. But does it hurt to strive for better? I don't think it does.
  - vmorgulis 10y ago
    Yes it is. For me, C as an intermediate vs LLVM language is a "worse is better" or "good enough" issue. LLVM is far more powerful but more complex. C is simpler and already works everywhere.

kibwen 10y ago

Note that Rust code can interoperate with other languages by exposing a C interface and having the host language call it as though it were C. There's no runtime to start up or anything, so to the host platform there's no discernible difference (though you may need some machinery in your build system). This is how Rust-written libraries have been integrated into Firefox (which is obviously still integrated into Firefox), and there are companies that have been using Rust to extend Ruby for years now.

jjnoakes 10y ago
Yep. I understand and this is why I could integrate rust right now into my products, module by module or object file by object file. I just need the compiler to run on my systems. Since it is written in rust, I either need it ported to my systems (too much work) or I need my rust code transpiled to C or C++ so I can build it myself (seems doable).
- pcwalton 10y ago
  It's not doable. How do you deal with UB from signed overflow? How do you get proper debug info? How do you set the proper EH personality? There are no shortcuts to a proper implementation of Rust. Implement an LLVM backend for your architecture. It doesn't make sense for Rust to maintain a backend that is doomed to be forever broken in various ways.
  - jjnoakes 10y ago
    I answered your ub question elsewhere. Exceptions and debug info come from C++. I don't see the issues there yet, but perhaps I just don't have the right knowledge yet. Rust won't have to maintain the backend. Who said they would? They might choose to if it becomes useful - it would give them things they dint have now (C++ interoperability, and new platform support for almost free), but no one here asked them to maintain anything. I am also not sure what you mean by shortcuts or broken forever in various ways.
    - 10y ago

MustardTiger 10y ago

>I'm in a position to influence teams of smart programmers, but the only language that I would be able to use would be one that fits in to the existing infrastructure, which is natively compiled shared libraries on esoteric unix platforms. So, how does that prevent you from using natively compiled languages like haskell?

jjnoakes 10y ago
The Haskell compiler doesn't run on my systems, and it does not generate human readable C or C++ from my Haskell code.
- MustardTiger 10y ago
  What systems are those? And why do you need "human readable C"? You said you needed it to work in a natively compiled shared library environment. You do not need to compile to C for that. But if you really want to do that for some reason, you can do it.
  - jjnoakes 10y ago
    I'd prefer it to be human readable because it helps in debugability if the code generator is broken (or we misunderstand some subtle semantics and want to look closer), and if I ever want to move away from the language in the future. Ignoring that, if I don't compile to C or C++, then I'm not sure how easy it will be to use. Are you suggesting Haskell can generate object files, shared objects, and binaries for my systems without compiling to C or C++ first? How would it get the file formats and calling conventions right? Can I specify them somehow to Haskell (doubtful)?
    - MustardTiger 10y ago
      >Are you suggesting Haskell can generate object files, shared objects, and binaries for my systems without compiling to C or C++ first? Of course, that's what ghc does by default. >How would it get the file formats and calling conventions right? The same way every other compiler does. What systems are we talking about?

jnbiche 10y ago

Your platform must be pretty esoteric indeed to not be an LLVM target. What are you targeting? Also, Rust is interoperable to the exact same extent C is. Making shared libraries exposing a C ABI is a snap.

jjnoakes 10y ago
Rust is interoperable. That's why I could use it. I just need the compiler to generate code I can build with my C or C++ toolchain, since there is no rust toolchain for my platforms.

sn9 10y ago

Have you looked at OCaml? [0] [0] https://en.wikipedia.org/wiki/OCaml#Features https://en.wikipedia.org/wiki/OCaml#Features

jjnoakes 10y ago
I am familiar with ocaml at a high level. I have written a few toy interpreters in it. The c code it generates is basically the ocaml bytecode interpreter and the bytecode of my program. Not what I was thinking of.
- sn9 10y ago
  It also has a native code compiler and a foreign function interface.
  - jjnoakes 10y ago
    It can generate portable and human readable C? Can you link to some information about that?
    - loup-vaillant 10y ago
      Nothing of the sort. But on the platforms it compiles to, Ocaml can generate object files that look like they came from C. I use this feature right now to integrate a compiler in an otherwise C++ project. Here's a link to the FFI documentation: http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html http://caml.inria.fr/pub/docs/manual-ocaml/intfc.html But I run on Debian stable on x86-64. Not exactly an exotic platform.
      - jjnoakes 10y ago
        Is this not the bytecode embedded in C which I mentioned above?
        loup-vaillant 10y ago