scala - 将Scala转换成golang是否可能/有用？

Question

Scala native 是最近发布的，但是他们(现在)使用的垃圾收集器非常rudimentary，因此不适合严肃使用。

所以我想知道:为什么不只将Scala转换为Go (即Scala.js)？这将是一个快速，可移植的运行时。他们的GC越来越好。更不用说伟大的并发模型的继承: channel 和goroutines。

那么，为什么scala-native选择LLVM这么低？

使用golang编译器有什么收获？

Answer 1

有两种语言是编译器的理想目标:

语义与源语言的语义非常匹配的语言。

语言具有非常低的层次，因此具有非常普遍的语义(或者可能会争辩:根本没有语义)。

＃1的示例包括:编译 ECMAScript 2015 to ECMAScript 5(大多数语言添加都是专门为现有功能设计的语法糖，您只需要对它们进行解糖)，编译 CoffeeScript to ECMAScript，编译 TypeScript to ECMAScript(基本上，在类型检查之后，只需擦除类型即可完成操作) )，编译 Java to JVM byte code，编译 C♯ to CLI CIL bytecode，编译 Python to CPython bytecode，编译 Python to PyPy bytecode，编译 Ruby to YARV bytecode，编译 Ruby to Rubinius bytecode，编译 ECMAScript to SpiderMonkey bytecode。

＃2的示例包括:通用CPU的机器代码( RISC even more so)， C--和 LLVM。

将Scala编译为Go并不适合两者。它们的语义非常不同。

您需要一种具有强大的低级语义的语言作为目标语言，以便可以在顶部构建自己的语义，或者需要一种具有紧密匹配的语义的语言，以便可以将自己的语义映射到目标语言。

实际上，甚至JVM字节码也已经太高级了!它的类之类的构造与Scala特质之类的构造不匹配，因此必须将特质的相当复杂的编码编码到类和接口(interface)中。同样，在 invokedynamic之前，实际上几乎不可能在JVM字节码中表示结构类型的动态调度。 Scala编译器不得不求助于反射，换句话说，故意跳出JVM字节码的语义(与其他类类型的方法分派(dispatch)相比，结构分派(dispatch)的方法分派(dispatch)了巨大的性能开销，尽管两者都是完全一样)。

正确的尾部调用是另一个示例:我们希望将它们包含在Scala中，但是因为JVM字节码不足以在没有非常复杂的映射的情况下表达它们(基本上，您必须完全放弃使用JVM的调用堆栈并管理自己的堆栈) ，这会破坏性能和Java的互操作性)，因此决定不使用该语言。

Go也存在一些相同的问题:为了实现Scala的表达性非局部控制流构造(例如异常或线程)，我们需要一个等效的表达性非局部控制流构造来映射。对于典型的目标语言，此“表达性非本地控制流构造”可以是延续，也可以是古老的 GOTO。 Go具有 GOTO ，但是故意限制了它的“非本地性”。对于人类编写代码，限制 GOTO的表达能力是一件好事，但是对于编译器目标语言而言，则不是很多。

很可能有可能使用goroutine和 channel 来构建强大的控制流，但是现在我们已经离开了舒适的范围，仅将Scala语义映射到Go语义，并开始在Go高级的基础上构建Scala高级语义不是为这种用法设计的语义。 Goroutine并不是设计为通用的控制流构造，而是在其之上构建其他类型的控制流。那不是他们擅长的!

So why did scala-native choose to go so low level with LLVM?

因为这正是LLVM的目的所在并且擅长。

What would be the catch with a golang transpiler?

两种语言的语义对于直接映射而言太不同了，并且Go的语义并非旨在在其之上构建不同的语言语义。

their GC is getting better and better

Scala-native的也可以。据我了解，当前使用Boehm-Dehmers-Weiser的选择基本上是一种懒惰:它在那里，它可以工作，您可以将其放入代码中，然后就可以完成它的工作。

请注意，更改GC为 under discussion。还有其他GC设计为直接插入而不是与主机VM的对象布局紧密耦合。例如。 IBM当前正在将其高性能JVM J9重组为一组松散耦合的，可独立重用的“运行时构建块”组件，并在许可的开源许可证下发布它们。

该项目称为 "Eclipse OMR"( source on GitHub)，并且已经可以投入生产:IBM J9的Java 8实现完全由OMR组件构建而成。有一个 Ruby + OMR项目，演示了如何轻松地将组件集成到现有的语言运行时中，因为组件本身没有语言语义，也没有特定的内存或对象布局。换出GC并添加JIT和事件探查器的 commit的时钟刚好超过10000行。它尚未准备就绪，但可以引导并运行Rails。他们还有一个类似的CPython项目(尚未公开)。

why not just transpile Scala to Go (a la Scala.js)?

请注意，Scala.JS存在很多我上面提到的相同问题。但是他们还是这样做了，因为 yield 是巨大的:您可以访问地球上的每个Web浏览器。假设的Scala.go无法获得可比的 yield 。

之所以有一些举措，是为了使诸如 asm.js和 WebAssembly之类的低级语义进入浏览器，恰恰是因为将高级语言编译为另一种高级语言总是需要克服这一“语义鸿沟”。

实际上，请注意，即使对于专门设计为特定语言的编译目标的低级语言，也仍然会遇到麻烦。例如。 Java具有泛型，而JVM字节码则没有。 Java具有内部类，而JVM字节码则没有。 Java具有匿名类，而JVM字节码则没有。所有这些都必须以某种方式进行编码，特别是泛型的编码(或更确切地说是非编码)引起了各种各样的痛苦。