加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 综合聚焦 > 服务器 > 安全 > 正文

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

发布时间:2020-12-16 19:12:00 所属栏目:安全 来源:网络整理
导读:Scala native最近已经发布,但他们使用的垃圾收集器(目前)非常大,并且不适合严肃使用. 所以我想知道:为什么不将Scala转换为Go(一个scala.js)?它将是一个快速,可移植的运行时.他们的GC越来越好了.更不用说伟大的并发模型的继承:渠道和goroutines. 那么为什
Scala native最近已经发布,但他们使用的垃圾收集器(目前)非常大,并且不适合严肃使用.

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

>那么为什么scala-native选择使用LLVM这么低级呢?
> Golang转换器的捕获量是多少?

解决方法

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

>语义与源语言的语义紧密匹配的语言.
>具有非常低级且因此非常一般语义的语言(或者可能会争论:根本没有语义).

#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 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并不是作为一般控制流构造而设计的,以构建其他类型的控制流.这不是他们擅长的!

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设计为drop-ins而不是紧密耦合到主机VM的对象布局.例如. IBM目前正在将其高性能JVM J9重组为一组松散耦合,可独立重用的“运行时构建块”组件,并在允许的开源许可下发布它们.

该项目名为“Eclipse OMR”(source on GitHub),已经可以投入生产:IBM J9的Java 8实现完全由OMR组件构建.有一个Ruby + OMR项目演示了如何将组件轻松集成到现有语言运行库中,因为组件本身不假定语言语义,也没有特定的内存或对象布局. commit交换了GC并添加了一个JIT和一个分析器时钟,只有10000多行.它不是生产就绪的,但它启动并运行Rails.他们也有类似的CPython项目(尚未公开).

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

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

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

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

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读