Java|为什么许多原本的 Java 项目都试图用 go 进行重写开源？ Java

文章图片

文章图片

说明go是一门优秀的语言，值得为之造轮子，完善其生态。面向对象，如果c++是1代，那么java就是2代，它解决了gc问题让程序员放飞自我，这项发明在上个世纪90年代简直就是上了天了，还能这么玩。
从技术层面分析， Go 实现的项目相比 Java 实现的更节省资源。组件用途决定了项目的实现形态，特别是对高并发的友好支持。从并发方面去看， Go 的并发实现方式优于 Java 的实现方式。

从性能上看，同样的 CPU 和内存大小， Go 新发现的组件能支持更高的 QPS；即，同等的业务需求， Go 的实现消耗更少的资源。从项目维护的角度去看， Go 开源项目有比较多的高水平研发人员参与进来。
docker作为一个运行时环境，其本身的开发语言是次要的，用什么语言都ok ，但docker托管的app尽量用go开发， alpine镜像打包的go程序真的很小，小服务体积只有5M ， java项目要200M 。这样等后面k8s出现后，这种差距就越来越显得离谱。但凡是脑袋正常的老板都喜欢那个5M 。自己的服务以及各种中间件无障碍大规模部署，拉低了互联网的逼格，或许这是go火的原因吧。

性能我觉得是次要的，尤其是基于db的无状态web后端应用，被调是一次rpc ，调db又是一次rpc ，两次rpc四次正反序列化这种计算不需要考虑性能，别比db慢就好。有状态的应用，比如游戏，比如角色装备变更， buff变更，天赋变更导致的重新计算，比如5000行代码的计算量，这种计算也比较少，够不成考虑性能的理由。
【Java|为什么许多原本的 Java 项目都试图用 go 进行重写开源？】特殊场景对性能有要求的，比如导弹的控制系统，目标北美， 1ms内没处理信号就打偏了而且差之毫厘谬以千里，弹头打到非洲去了，这种大概率不会使用带gc的语言。
协程也是次要的，我们知道软件领域的框架相当于硬件界的soc ，集成了各个带license的模块(知识产权) ， import了github这个包那个包的。
soc其实已经把硬件方案都做完了，硬件工程师只要在爪子外面加个电阻电容就行了，了不得再做个仿真。软件框架也是的，已经把整个应用都做好了，并发处理的部分也写好了，我们开发者只需要阅读框架的手册，在某些地方实现一下接口，没几行代码的，甚至照葫芦画瓢都可以，因为业务代码都是横向拓展的。

所以对于我们普通码农而言不需要关心协程是什么，我们知道框架制造者是一群聪明人属于那1%年薪拿100w美刀的， c里面使用线程池去并发还是go里面使用协程去并发在他们看来都是一样的，他们对各种语言的内存模型了如指掌， cpu的每条指令的load/store语义他们一清二楚，他们每天用锁都用吐了。
java其实是很难的。我们知道高级语言之所以高级是因为编译器做了很多事导致写出来的代码和自己预期的很不一样，所以需要去观察编译器生成的指令。 java这边不光要学习字节码，想看jvm不仅要看specification还要学习c ，这就扯淡了，那我是不是还要先把c精通了才能去观察最终的汇编指令？

go相对就简单了， specification、字节码、c这些统统没有， -S直接给出汇编。我们知道汇编是最简单的，没那么多嘻嘻哈哈，这样能很好地把go搞搞清楚，也能给刚毕业的从事编程的一个上车的机会。 go只能算2.5代。 3代语言我相信并发是不需要考虑同步的。