都2022年了,还在争论编程语言?
共 1889字,需浏览 4分钟
·
2022-01-23 02:58
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资料也在准备中,不想错过可以点个关注。