6 ms·

Heh, I wonder if anyone has tried transpiling the C generated by Chicken Scheme to Go. Would be interesting to see how (horrifically?) the garbage collector wo

Heh, I wonder if anyone has tried transpiling the C generated by Chicken Scheme to Go. Would be interesting to see how (horrifically?) the garbage collector would fare in performance once it's transpiled to a garbage collected language like Go.

kubb 4y ago
What would also be nice is an ML or Lisp transpiled to Go. Go has a nice compiler with a lot of money thrown into it, but it's locked into one syntax, and set of language features that isn't optimal for every use case, so it's a good target for transpilation. It would be fun to see Go with a terser syntax, better type inference, nicer error handling, etc.
- anon_d 4y ago
  Compiling functional languages to other high-level language s generally has pretty awful performance compared to simple native compilation. Even compiling to C has it's limitations. The fact that Go has a nice compiler doesn't really help, because the code generated by the functional compiler will have usage patterns that are very different from what the Go compiler is designed around.
- kaba0 4y ago
  Not trying to start a flame war, but.. is the Go compiler nice? Other than being fast, and static compilation what good features does it have compared to say the LLVM toolchain? It barely does any optimizations.
- dividedbyzero 4y ago
  Something like that would be amazing, like the godsend that Scala was for the JVM back when Java was very, very imperative and totally stagnant, though Scala didn't/doesn't transpile to Java, but compiles to JVM bytecode directly. I don't think the same would be possible for Go, which is a shame, but AFAIK there is no such intermediate to target. And given how limited Go itself is, I wouldn't be all that optimistic that a transpiling approach could support many advanced features without tanking performance because you just can't model them efficiently in Go at all, even if you limit enforcement of most guarantees to the transpiler.
  - kubb 4y ago
    What kind of difficult to support advanced features do you have in mind?
    - kaba0 4y ago
      I’m not who you are responding to, but optimizing recursions (e.g. tail-call elimination), loop fusion, etc. Functional languages (at least haskell) does plenty of optimizations not generally possible in imperative codes.
      - kubb 4y ago
        tail call elimination is possible by converting the tail-recursive function to a loop. in fact Go could support it, but the team doesn't want to do that. I agree that everything Haskell does would be hard, but everything e.g. Clojure does should be possible
  - vnorilo 4y ago
    I think Clojure on Go (Gojure)? Would probably do nearly as well as the JVM hosted version if done well.
- pjmlp 4y ago
  Why bother when Common Lisp, SML, OCaml, F# and OCaml already provide AOT toolchains and have better tooling anyway.
  - kubb 4y ago
    To enrich the ecosystem? for fun? Maybe someone has a Go project and needs to add a module that is difficult to maintain in Go? I'm always taken aback by "why bother" questions when it comes to hacking.
    - pjmlp 4y ago
      Maybe they shouldn't have started in Go then.
      - erik_seaberg 4y ago
        My team never chose it, but it’s becoming harder to avoid for some use cases in my org due to other teams’ omissions.
  - christophilus 4y ago
    I’ve used all of those except SML. Go is much easier to set up and get productive in, in my opinion. And if you care about compilation speed, you can forget about F#. I say this as someone who loves F#.
    - pjmlp 4y ago
      In what concerns UNIX workloads, it is the same apt/rpm/yum + vim/emacs/vscode workflows. Common Lisp stuff like LispWorks and Allegro, run the installer, done. Why are you compiling F# AOT to binary all the time?
      - christophilus 4y ago
        I’ve never AOT compiled F#. It’s just slow in normal, iterative mode compared to Go. I’m on Linux, though. Maybe it’s better on Windows?
- praptak 4y ago
  The selling point of Go is readability, feature minimalism and code that might be boring to write but gets you readability in return. Putting a Lisp on top of that throws these away. I'm not saying there's nothing left - channels, maybe the standard library. But putting a Lisp on top of Go feels like going strongly against the grain.
  - kubb 4y ago
    Besides the (subjective) advantages that you've mentioned, the selling points of Go include standalone binaries, fast compilation, a good standard library, and crucially, strong corporate support. A transpiled language could benefit from those.
    - arethuza 4y ago
      Transpiling Python to Go would be neat and it turns out at least one project does just that (at least to prove the concept): https://github.com/google/grumpy https://github.com/google/grumpy
  - rowanG077 4y ago
    But Go is not that readable. In fact across all languages I know I would factor go towards the bottom end of readability. Mostly because of it's insane error handling overhead. A lot of function bodies are like reading a book where every sentence is followed with 3 that have no meaning.
    - maleldil 4y ago
      That's subjective. Readability is one of Go's goals. Whether they achieved it depends on your preference.
      - mywittyname 4y ago
        The fact that goland automatically collapses error handling blocks is solid evidence that enough developers find go's error handling blocks to be invasive.
- eru 4y ago
  I think compiling via LLVM is probably a better idea than compiling via Go.. (Also why do people invent a new word 'transpile', when the old word already perfectly describes translating from one formal language into another?)
  - erik_seaberg 4y ago
    It feels like stolen valor to say I've written a compiler when I'm really relying on someone else's compiler.
    - deleted 4y ago
      [deleted]
    - eru 4y ago
      Well, that's what LLVM does, too. You compile to LLVM's intermediate language, and they compile further.
  - chrisseaton 4y ago
    > Also why do people invent a new word 'transpile' Not this ignorant myth again - it isn’t a new word, been in use since mid 60s. A transpiler is a form of compiler from high-level language to high-level language. A compiler didn't even originally translate, but just link. The same way ‘navy’ is a kind of blue but we can say navy and add a little more specific information. Nobody rails against navy saying ‘but it’s just a shade of blue!’
    - eru 4y ago
      I didn't say 'transpiling' was a newly invented word.
      - chrisseaton 4y ago
        I thought you asked? > Also why do people invent a new word 'transpile', when the old word already perfectly describes translating from one formal language into another? The answer is... the old word ('compiler') didn't mean what it does today, back in the 60s, when 'transpiler' was coined. Compiler with its current meaning isn't a much older word than transpiler - they're near contemporaries (50s and 60s). Before that a compiler meant a linker. Your criticism doesn't match up with the history.
- zem 4y ago
  I believe purescript does have a go target

kubb 4y ago

What would also be nice is an ML or Lisp transpiled to Go. Go has a nice compiler with a lot of money thrown into it, but it's locked into one syntax, and set of language features that isn't optimal for every use case, so it's a good target for transpilation. It would be fun to see Go with a terser syntax, better type inference, nicer error handling, etc.

anon_d 4y ago
Compiling functional languages to other high-level language s generally has pretty awful performance compared to simple native compilation. Even compiling to C has it's limitations. The fact that Go has a nice compiler doesn't really help, because the code generated by the functional compiler will have usage patterns that are very different from what the Go compiler is designed around.
kaba0 4y ago
Not trying to start a flame war, but.. is the Go compiler nice? Other than being fast, and static compilation what good features does it have compared to say the LLVM toolchain? It barely does any optimizations.
dividedbyzero 4y ago
Something like that would be amazing, like the godsend that Scala was for the JVM back when Java was very, very imperative and totally stagnant, though Scala didn't/doesn't transpile to Java, but compiles to JVM bytecode directly. I don't think the same would be possible for Go, which is a shame, but AFAIK there is no such intermediate to target. And given how limited Go itself is, I wouldn't be all that optimistic that a transpiling approach could support many advanced features without tanking performance because you just can't model them efficiently in Go at all, even if you limit enforcement of most guarantees to the transpiler.
- kubb 4y ago
  What kind of difficult to support advanced features do you have in mind?
  - kaba0 4y ago
    I’m not who you are responding to, but optimizing recursions (e.g. tail-call elimination), loop fusion, etc. Functional languages (at least haskell) does plenty of optimizations not generally possible in imperative codes.
    - kubb 4y ago
      tail call elimination is possible by converting the tail-recursive function to a loop. in fact Go could support it, but the team doesn't want to do that. I agree that everything Haskell does would be hard, but everything e.g. Clojure does should be possible
- vnorilo 4y ago
  I think Clojure on Go (Gojure)? Would probably do nearly as well as the JVM hosted version if done well.
pjmlp 4y ago
Why bother when Common Lisp, SML, OCaml, F# and OCaml already provide AOT toolchains and have better tooling anyway.
- kubb 4y ago
  To enrich the ecosystem? for fun? Maybe someone has a Go project and needs to add a module that is difficult to maintain in Go? I'm always taken aback by "why bother" questions when it comes to hacking.
  - pjmlp 4y ago
    Maybe they shouldn't have started in Go then.
    - erik_seaberg 4y ago
      My team never chose it, but it’s becoming harder to avoid for some use cases in my org due to other teams’ omissions.
- christophilus 4y ago
  I’ve used all of those except SML. Go is much easier to set up and get productive in, in my opinion. And if you care about compilation speed, you can forget about F#. I say this as someone who loves F#.
  - pjmlp 4y ago
    In what concerns UNIX workloads, it is the same apt/rpm/yum + vim/emacs/vscode workflows. Common Lisp stuff like LispWorks and Allegro, run the installer, done. Why are you compiling F# AOT to binary all the time?
    - christophilus 4y ago
      I’ve never AOT compiled F#. It’s just slow in normal, iterative mode compared to Go. I’m on Linux, though. Maybe it’s better on Windows?
praptak 4y ago
The selling point of Go is readability, feature minimalism and code that might be boring to write but gets you readability in return. Putting a Lisp on top of that throws these away. I'm not saying there's nothing left - channels, maybe the standard library. But putting a Lisp on top of Go feels like going strongly against the grain.
- kubb 4y ago
  Besides the (subjective) advantages that you've mentioned, the selling points of Go include standalone binaries, fast compilation, a good standard library, and crucially, strong corporate support. A transpiled language could benefit from those.
  - arethuza 4y ago
    Transpiling Python to Go would be neat and it turns out at least one project does just that (at least to prove the concept): https://github.com/google/grumpy https://github.com/google/grumpy
- rowanG077 4y ago
  But Go is not that readable. In fact across all languages I know I would factor go towards the bottom end of readability. Mostly because of it's insane error handling overhead. A lot of function bodies are like reading a book where every sentence is followed with 3 that have no meaning.
  - maleldil 4y ago
    That's subjective. Readability is one of Go's goals. Whether they achieved it depends on your preference.
    - mywittyname 4y ago
      The fact that goland automatically collapses error handling blocks is solid evidence that enough developers find go's error handling blocks to be invasive.
eru 4y ago
I think compiling via LLVM is probably a better idea than compiling via Go.. (Also why do people invent a new word 'transpile', when the old word already perfectly describes translating from one formal language into another?)
- erik_seaberg 4y ago
  It feels like stolen valor to say I've written a compiler when I'm really relying on someone else's compiler.
  - deleted 4y ago
    [deleted]
  - eru 4y ago
    Well, that's what LLVM does, too. You compile to LLVM's intermediate language, and they compile further.
- chrisseaton 4y ago
  > Also why do people invent a new word 'transpile' Not this ignorant myth again - it isn’t a new word, been in use since mid 60s. A transpiler is a form of compiler from high-level language to high-level language. A compiler didn't even originally translate, but just link. The same way ‘navy’ is a kind of blue but we can say navy and add a little more specific information. Nobody rails against navy saying ‘but it’s just a shade of blue!’
  - eru 4y ago
    I didn't say 'transpiling' was a newly invented word.
    - chrisseaton 4y ago
      I thought you asked? > Also why do people invent a new word 'transpile', when the old word already perfectly describes translating from one formal language into another? The answer is... the old word ('compiler') didn't mean what it does today, back in the 60s, when 'transpiler' was coined. Compiler with its current meaning isn't a much older word than transpiler - they're near contemporaries (50s and 60s). Before that a compiler meant a linker. Your criticism doesn't match up with the history.
zem 4y ago
I believe purescript does have a go target