将Scala转换为golang是否可行/有用？

Question

最近发布了Scala native，但他们使用的垃圾收集器（目前）非常简陋 ，并且不适合严肃使用。

所以我想知道：为什么不将Scala转换为Go （一个scala.js）？ 它将是一个快速，可移植的运行时。 他们的GC越来越好了。 更不用说伟大的并发模型的继承：渠道和goroutines。

• 那么为什么scala-native选择使用LLVM这么低级呢？
• golang编译器有什么特点？

Answer 1

有两种语言是编译器的良好目标：

1. 语义与源语言的语义紧密匹配的语言。
2. 语言具有非常低级别，因此非常一般的语义（或者有人可能会说：完全没有语义）。

＃1的示例包括：将ECMAScript 2015编译为ECMAScript 5 （大多数语言添加专门设计为现有功能的语法糖，您只需要去除它们），将CoffeeScript编译为ECMAScript ，将TypeScript编译为ECMAScript （基本上，在类型检查后，只需擦除类型即可完成），编译Java到JVM字节码 ，编译C♯到CLI CIL字节码 ，编译Python到CPython字节码 ，编译Python到PyPy字节码 ，编译Ruby到YARV字节码 ，编译Ruby到Rubinius字节码 ，编译ECMAScript到SpiderMonkey字节码 。

对＃2的实例包括：用于在通用CPU的机器代码（ RISC更是如此 ）， C-- ， LLVM 。

编译Scala to Go不适合两者。 他们的语义非常不同。

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

实际上，即使JVM字节码已经太高了 ！ 它具有诸如与Scala的特征之类的构造不匹配的类的构造，因此必须对类和接口中的特征进行相当复杂的编码。 同样，在invokedynamic之前，实际上几乎不可能在JVM字节码中表示结构类型的动态调度。 Scala编译器不得不求助于反射，换句话说，故意踩到JVM字节码的语义之外 （与其他类类型的方法调度相比，这导致结构类型上的方法调度的性能开销很大，即使两者都是完全相同的事情 ）。

正确的尾调用是另一个例子：我们希望在Scala中使用它们，但是因为JVM字节码的功能不足以在没有非常复杂的映射的情况下表达它们（基本上，你必须完全放弃使用JVM的调用栈并管理你自己的栈，它破坏了性能和Java互操作性），决定不在语言中使用它们。

Go有一些相同的问题：为了实现Scala的表达式非局部控制流构造，例如异常或线程，我们需要一个同样表达的非本地控制流构造来映射。 对于典型的目标语言，这种“富有表现力的非本地控制流构造”是延续或古老的GOTO 。 Go 有 GOTO ，但故意限制在它的“非本地性”。 对于人类编写代码，限制GOTO的表达能力是一件好事，但对于编译器目标语言而言，并非如此。

很可能使用goroutines和channel来安装强大的控制流，但是现在我们已经离开了将Scala语义映射到Go语义的舒适范围，并开始在Go高级别上构建Scala高级语义不是为这种用法而设计的语义。 Goroutines并不是作为一般控制流构造而设计的，以构建其他类型的控制流。 这不是他们擅长的！

那么为什么scala-native选择使用LLVM这么低级呢？

因为这正是LLVM的设计目标并且擅长。

golang编译器有什么特点？

两种语言的语义对于直接映射来说太不同了，而Go的语义并不是为了构建不同的语言语义而设计的。

他们的GC越来越好了

Scala-native也是如此。 据我所知，当前使用Boehm-Dehmers-Weiser的选择基本上就是懒惰之一：它存在，它有效，你可以把它放到你的代码中，它只是做它的事情。

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

该项目被称为“Eclipse OMR” （ GitHub上的源代码 ），它已经可以投入生产了：IBM J9的Java 8实现完全由OMR组件构建。 有一个Ruby + OMR项目，它演示了如何轻松地将组件集成到现有的语言运行库中，因为组件本身不假定语言语义，也没有特定的内存或对象布局。 交换GC的提交 ，并在超过10000行添加JIT和分析器时钟。 它不是生产就绪的，但它启动并运行Rails。 他们也有类似的CPython项目（尚未公开）。

为什么不只是将Scala转换为Go（一个Scala.js）？

请注意，Scala.JS有很多我上面提到的相同问题。 但他们无论如何都在这样做，因为收益巨大 ：你可以访问这个星球上的每个网络浏览器。 对于假设的Scala.go，没有可比的收益。

这就是为什么有一些举措可以将低级语义转化为浏览器，例如asm.js和WebAssembly ，正是因为将高级语言编译成另一种高级语言总是需要克服这种“语义鸿沟”。

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