大家好，今天小编关注到一个比较有意思的话题，就是关于java 转行go语言的问题，于是小编就整理了2个相关介绍Java 转行go语言的解答，让我们一起看看吧。
j***a和go哪个值得入手？
如果市场上有个调查,我相信 Go 程序员的平均薪资是能高出 J***a 一节的.
第一, J***a 不管是大小厂都在用,低级 j***a 数不胜数,工资也入门级的,这些金字塔低端的人拉低了 j***a 的平均薪资.
第二,Go 主要是大厂在用,小厂不敢冒险跟一种新技术(除非有强力 CTO 坐镇),而且 Go 基本上没有新手可言, Go 的使用者绝大部分集中在多年后端经验的老鸟,大部分由 Python、c++、j***a 转过来的，因此平均薪资极高，能跟 Scala、Erlang 媲美的高薪一族（注意这俩高薪也是跟 Golang 一个情况,多年 j***a、c++转的）.
为什么许多原本的J***a项目都试图用go进行重写开源？
很多j***a开发者应该听过当初j***a兴起时的一句宣传口号：“一次编译，到处运行”，但这个优势已经被容器大幅度地削弱，不再是大多数服务端开发者技术选型的主要考虑因素了。
现在微服务盛行，对应用的容器化亲和性，譬如镜像体积、内存消耗、启动速度，以及达到最高性能的时间等方面提出了新的要求。
而j***a对云原生不友好，一个j***a应用的docker镜像几百兆，在k8s动态扩容时拉取镜像、启动容器比较耗时；而go应用镜像只有几十兆，相对来说启动速度快了很多，占用内存较小。
个人觉得应该是三个主要原因吧。
因为容器服务越来越主流，这到不是说J***a不能在云原生环境使用，现在云原生里的微服务模式，主流编程语言还是J***a，只是，依赖于JDK平台确实让容器镜像体积大了很多！大部分情况下，微服务本身jar的体积（包括各种依赖的flat jar）也与JDK本身的体积相差无几（甚至不及）。在多个服务情况下，拉取镜像的成本就高很多，虽然分层存储可以有效降低存储容量，但这也依赖所有微服务需要相同的镜像基座（部署好JDK），对于不同厂商的微应用（服务）情况不一定乐观。
Golang在这部分表现好很多，虽然打包后的Binary也不小（相比于C），但它包含运行时支持及静态链接，非常独立（单体程序易于部署），体积相比J***a的服务，总体要小很多。
二. 开发难度不大
后端应用服务最重要的是稳定，J***a之所以能长时间占据后端开发市场份额，也是因为其异常及GC机制能够平衡好程序开发难度和程序质量这两个矛盾体。而Golang也引入了GC，开发难度也不高（并不比J***a难），不需要特别优秀的能力也能写出健壮的后端应用。
三. 语言发展的必然结果
现在越来越多的人开始使用Golang写后端应用。当你进入这个领域，你就会发现，你需要的各种框架，基础设施基本上都是在重复写一遍其他已经进入该领域的语言的各种框架和基础库😄 这是工程本身决定的，到不一定是抄J***a。记得Nodejs刚出来的时候，借助于V8强大的性能，大前端的各种开发工具，框架如雨后春笋般发展起来，但也基本上是走了一遍其他语言（尤其是J***a）的路。
不同语言在发展过程中，总会进入其他“先入语言”的领域，然后也会再走一遍人家的路，完善和建立自身在该领域的生态。这是后发语言发展的必经之路！
到此，以上就是小编对于j***a 转行go语言的问题就介绍到这了，希望介绍关于j***a 转行go语言的2点解答对大家有用。
