2021年最后一天，我在公众号发表了文章《Dubbo为什么用Go重写》，在各个平台的阅读量和打开率都挺高，也有各位大佬纷纷转载，在这里也顺便感谢各位大佬，

虽然自己公众号没有开通留言，但我也会去看其他平台或转载文章的评论，

我发现大家的注意力更多的是在编程语言上，比如下面这些：

看了这些评论想起了一个段子：

某女：你能让这个论坛的人都吵起来，我今晚就跟你走，

某软件工程师：PHP是最好的语言！

某论坛真的就炸锅了，各种吵架……

某女：服了你了，我们走吧，你想干啥都行，

某软件工程师：今天不行，我一定要说服他们，PHP必须是最好的语言…

——段子来源于网络

虽然是个段子，但我也想通了为什么这篇文章的打开率和阅读量如此之高，

文章有大段篇幅在说Java和Go语言，而编程语言之争历来都是程序员的谈资，

但这并不是我的本意，编程语言只是一个背景，可以有各种各样的理由选择一个语言，况且现实情况已是如此，所以后续的如何在Go和Java之间架起桥梁才是重点，

不过已经说到这里，也可以多扯一点，我自己是数学系毕业，所以大学也没怎么学编程语言，毕业时选了一个非常容易入门的语言，就是上面段子中的PHP，

后来大环境都是Java，所以也转了Java，一开始用Java写业务，后来做中间件，再后来跳槽来了现在的公司，也写起了Go，

如果非要评价Java和Go，我觉得Java的生态非常完备，有几乎所有互联网公司需要的解决方案，参考一篇文章里的话

我以为用Java适合做架构这事应该是常识了，

我解释一下吧：首先，小型的项目用什么语言都行，爱用什么用什么，

但是，真正的企业级架构就不一样了，其中并不仅仅只是 RESTful API 或 RPC，还有各种配套设施和控制系统，

比如：应用网关，服务发现、配置中心、健康检查、服务监控、服务治理（熔断、限流、幂等、重试、隔离、事务补偿）、Tracing监控、SOA/ESB、CQRS、EDA……

这些东西在非 Java 的技术堆栈体系内，很难看到全貌，Java 强大的生态环境，就是让你把注意力放到更高层次的架构和业务上来的，

另外千万不要觉得，整几个服务 RPC 一下，加个快取，加个队列，就能叫架构，那只是系统集成罢了，

虽然这段话有些绝对，Go生态也在奋力追赶，但就目前的情况来看，确实是这样，

我也混迹在各个技术群里潜水，有一次看到一个群里在讨论Java的Spring框架，有个写Go的同学这幺说：

Spring不就是个Web框架嘛

我觉得他对Java的了解太少了，Spring还真就不是一个Web框架，但我忍住了，没有反驳，

Go也有它的长处，比如协程调度模型、比如启动速度、存储器占用等等，

你别小看协程（虽然Java也快有协程了，但离我们还有点远），它背后的显示出的是思想的转变，比如Go提倡不要通过共享存储器来通信，而应该通过通信来共享存储器，在Java中，基本就是通过共享存储器来通信，这就导致一个问题，多执行绪访问共享存储器必须加锁，

但Go中建议通过channel来通信，你可能会说，在Java中也有BlockQueue啊，还不一样，BlockQueue通信本质上还是对共享内容加锁，但Go的协程调度模型下，channel就可能实作无锁，

我记得在我刚作业那会，遇到一位前辈，当时我还在写PHP，他建议我可以尝试转Java，我当时说，语言不过是一个工具，

现在我觉得这句话是有毛病的，语言不光是一个工具，它也凝结了一些编程思想，比如PHP的行程模型，Java的执行绪模型，Go的协程模型，在这些模型下，你能做的事可能就不一样，

比如我在学Go的Benchmark的时候，就觉得Java的Benchmark要比Go实作的严谨不少，不愧是工业级语言，

又比如Go的协程调度，在IO密集型下，调度效率比Java优了不少，

再比如在协程调度模型的加持下，Go的物件池性能优于Java，channel效率比Java的BlockQueue高，

总之，我们在力所能及的范围尽可能地多了解其他语言，对比他们的异同，也许对你下次的技术选型就有一些启发，

这也是我第一次写这种主观性较强的文章，在此特地求一个赞+在看，后面我也多扯扯淡，

搜索关注微信公众号"捉虫大师"，回复关键字「Nacos」送你一本《Nacos架构与原理》电子书，Dubbo资料也在准备中，不想错过可以点个关注，