原因之一是技术发展更加细化了,需要去更多方向上发展,做更好的组合,来榨取更多价值
理论上说,java这种静态类型一开始就可以很适合AOT模式的,(GC之类的问题其实并不必须VM,也可以VEE,像Go这样),只要不嫌麻烦在各种平台上搞对应编译器(或者通过其他代码中转,如java->C),但因为某些原因并没有直接做成这样,当年微软的VJ似乎就这么干,然后被起诉了。。。
直接解释执行性能是个问题,如果不AOT,那么就JIT,然后大家发现JIT也就是“慢热”了一点,实际效果可能比AOT还好,因为JIT可以做到AOT做不到的一些动态优化,于是干脆就解释+JIT这个架构搞定,综合性价比最高
不过随着应用和需求的发展,JIT的一些弱点(比如上面说的慢热之类)也显现了,这时候就引入AOT来补足,也是挺自然的事情
但并非所有解释+JIT的架构都可以引入AOT来解决一些问题,例如你提到的pypy,基本就没有AOT的价值,这很大程度是Python语言本身特性决定的
反过来说,题主提的C++、Go这种一般以“AOT”形式实现的语言,难道就不能再进一步引入JIT来优化性能么,其实是可以的,说不定将来也会是一个趋势
所谓的十年风水轮流转呗。
早期的计算机由于性能真的不行,所以需要程序能尽可能的吃尽计算机的性能,运行效率才能被人接受。所以那时候的语言都专注于运行效率,用得多的基本都是 AoT 编译型语言。
在摩尔定律还适用的年代,计算机的性能不断提升,内存也越来越大,再加上 Ruby 的出现,让人开始关注开发效率,运行效率反而被一定程度地忽视,反正我写的程序这一代计算机跑不动,下一代就能跑动了。而开发效率并不会因为CPU性能提升而成正比地提升,所以这个阶段比较流行的是那些关注开发效率的解释型语言。
现在摩尔定律已经不适用了,CPU运算速度很难再往上提。在各种新兴语言都已经让开发人员敲得足够爽的情况下,关注点自然又会回归到运行效率,但是开发效率和语言的表现力又不想放弃,所以很多解释型语言开始搞 JIT 编译器,而在这个阶段的全新语言也会考虑 AoT,只要工具链做的够好,AoT 在开发效率上也一样高效。
说白了,计算机领域就是个在贪婪和怠惰这两种原罪的相互作用下不断发展的领域。贪婪是技术革新的第一推动力,而怠惰指明了革新的方向。
低情商:是的,已经结束了。
高情商:diy的时代暂停了,只不过我们暂时不知道重新开放的期限。