分享
为什么 2010 年前后诞生的语言(如 Golang, Rust, Swift)都是直接编译成机器码?
autumn20080101 · · 4972 次点击 · · 开始浏览这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。
为什么 2010 年前后诞生的语言(如 Golang, Rust, Swift)都是直接编译成机器码?
之所以问这个问题是因为知乎上有问题"为什么 2010 年前后诞生的语言(如 Golang, Rust, Swift)都是强类型 + 静态?",其中大多数答案都是在说动态语言存在的问题
那么按照这个逻辑,这三门语言都不是像JAVA、C#那样先编译成中间代码(JAVA字节码和CIL)、在运行时再JIT成机器码,那是不是说明中间码这种思路也有问题呢?
那么按照这个逻辑,这三门语言都不是像JAVA、C#那样先编译成中间代码(JAVA字节码和CIL)、在运行时再JIT成机器码,那是不是说明中间码这种思路也有问题呢?
按投票排序按时间排序
2 个回答
什么是答案总结? 答案总结
你忘记scala和clojure等jvm上的语言了。所以提问的前提就不对
你忘记scala和clojure等jvm上的语言了。所以提问的前提就不对
java和c#都可以编译成机器码,也可以JIT编译,有了LLVM IR,c/c++/swift也不一定非要直接编译成机器码。苹果已经不允许store上swift开发的应用直接编译为机器码,而是bitcode的形式,和jvm的字节码所要达到的目的差不多。比如说哪天苹果的芯片改个指令集,s...
显示全部
java和c#都可以编译成机器码,也可以JIT编译,有了LLVM IR,c/c++/swift也不一定非要直接编译成机器码。
苹果已经不允许store上swift开发的应用直接编译为机器码,而是bitcode的形式,和jvm的字节码所要达到的目的差不多。比如说哪天苹果的芯片改个指令集,store上的应用啥都不用管直接获得性能提升。jvm的字节码也是如此,android art虽然支持aot编译,但也同样如此,android采用renderscript而不接受opencl也是这个考虑。
另外2010年前后诞生的语言很多,jvm上的,dart/typescript和js相关的,nim,elixir,crystal,kotlin,ceylon等等,你看看有几个是直接编译为机器码的?
至于Golang为何还要编译为机器码,在未来,Go语言能否撼动Java在Android、Hadoop大数据、云计算领域的地位?这个问题中,王益的回答里"Dockerization的开销"这段说的很清楚了。
关键不是在字节码还是机器码,而是【类型系统】的强弱问题,这个问题很重要,而且似乎达成了一致共识,就连某些fp语言都添加类型了。
苹果已经不允许store上swift开发的应用直接编译为机器码,而是bitcode的形式,和jvm的字节码所要达到的目的差不多。比如说哪天苹果的芯片改个指令集,store上的应用啥都不用管直接获得性能提升。jvm的字节码也是如此,android art虽然支持aot编译,但也同样如此,android采用renderscript而不接受opencl也是这个考虑。
另外2010年前后诞生的语言很多,jvm上的,dart/typescript和js相关的,nim,elixir,crystal,kotlin,ceylon等等,你看看有几个是直接编译为机器码的?
至于Golang为何还要编译为机器码,在未来,Go语言能否撼动Java在Android、Hadoop大数据、云计算领域的地位?这个问题中,王益的回答里"Dockerization的开销"这段说的很清楚了。
关键不是在字节码还是机器码,而是【类型系统】的强弱问题,这个问题很重要,而且似乎达成了一致共识,就连某些fp语言都添加类型了。
有疑问加站长微信联系(非本文作者)
入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889
关注微信4972 次点击
上一篇:Go学习笔记:关于defer
添加一条新回复
(您需要 后才能回复 没有账号 ?)
- 请尽量让自己的回复能够对别人有帮助
- 支持 Markdown 格式, **粗体**、~~删除线~~、
`单行代码` - 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
- 图片支持拖拽、截图粘贴等方式上传
收入到我管理的专栏 新建专栏
之所以问这个问题是因为知乎上有问题"为什么 2010 年前后诞生的语言(如 Golang, Rust, Swift)都是强类型 + 静态?",其中大多数答案都是在说动态语言存在的问题
那么按照这个逻辑,这三门语言都不是像JAVA、C#那样先编译成中间代码(JAVA字节码和CIL)、在运行时再JIT成机器码,那是不是说明中间码这种思路也有问题呢?
那么按照这个逻辑,这三门语言都不是像JAVA、C#那样先编译成中间代码(JAVA字节码和CIL)、在运行时再JIT成机器码,那是不是说明中间码这种思路也有问题呢?
按投票排序按时间排序
2 个回答
什么是答案总结? 答案总结
你忘记scala和clojure等jvm上的语言了。所以提问的前提就不对
你忘记scala和clojure等jvm上的语言了。所以提问的前提就不对
java和c#都可以编译成机器码,也可以JIT编译,有了LLVM IR,c/c++/swift也不一定非要直接编译成机器码。苹果已经不允许store上swift开发的应用直接编译为机器码,而是bitcode的形式,和jvm的字节码所要达到的目的差不多。比如说哪天苹果的芯片改个指令集,s...
显示全部
java和c#都可以编译成机器码,也可以JIT编译,有了LLVM IR,c/c++/swift也不一定非要直接编译成机器码。
苹果已经不允许store上swift开发的应用直接编译为机器码,而是bitcode的形式,和jvm的字节码所要达到的目的差不多。比如说哪天苹果的芯片改个指令集,store上的应用啥都不用管直接获得性能提升。jvm的字节码也是如此,android art虽然支持aot编译,但也同样如此,android采用renderscript而不接受opencl也是这个考虑。
另外2010年前后诞生的语言很多,jvm上的,dart/typescript和js相关的,nim,elixir,crystal,kotlin,ceylon等等,你看看有几个是直接编译为机器码的?
至于Golang为何还要编译为机器码,在未来,Go语言能否撼动Java在Android、Hadoop大数据、云计算领域的地位?这个问题中,王益的回答里"Dockerization的开销"这段说的很清楚了。
关键不是在字节码还是机器码,而是【类型系统】的强弱问题,这个问题很重要,而且似乎达成了一致共识,就连某些fp语言都添加类型了。
苹果已经不允许store上swift开发的应用直接编译为机器码,而是bitcode的形式,和jvm的字节码所要达到的目的差不多。比如说哪天苹果的芯片改个指令集,store上的应用啥都不用管直接获得性能提升。jvm的字节码也是如此,android art虽然支持aot编译,但也同样如此,android采用renderscript而不接受opencl也是这个考虑。
另外2010年前后诞生的语言很多,jvm上的,dart/typescript和js相关的,nim,elixir,crystal,kotlin,ceylon等等,你看看有几个是直接编译为机器码的?
至于Golang为何还要编译为机器码,在未来,Go语言能否撼动Java在Android、Hadoop大数据、云计算领域的地位?这个问题中,王益的回答里"Dockerization的开销"这段说的很清楚了。
关键不是在字节码还是机器码,而是【类型系统】的强弱问题,这个问题很重要,而且似乎达成了一致共识,就连某些fp语言都添加类型了。