GO语言崛起，Java该何去何从？
最近看到GO语言吵得沸沸扬扬的，这里也看了下GO语言相关，有很多话想说，不吐不快的那种。
2021年的今天，诸多语言都在百家争艳，如同过去的诸子百家般，但是每个语言的出生都是有着它的使命。
比如C语言的出现时为了解决汇编或者B语言的晦涩难懂，过多的代码量，将大部分的工作留给编译器去解决。
C++的出现解决了C类语言的不人性化，即引入了面向对象的思想。
JAVA、Python、PHP等更高级的语言则去掉了C和C++的不通人性的一面，也即较为难理解的一面，比如指针、运算符重载等等骚操作，降低了学习成本，让语言越来越人性化。
其实就是让门槛越来越低，内卷越来越严重。
比如Java的spring套系的出现，让JavaSE的基础都几乎不用学精。
只需要了解if、else、map、list、set等等CRUD必备的操作外，其余压根都不用懂，直接上高并发项目。
毕竟再怎么烂的代码，多加几台机器，部属个集群总能撑吧，至少小公司就这样。
那么，来聊聊GO语言吧。
这个语言的出生就是带着取代C++和C去的，保留着指针，结构体，接口，去掉了模板类也即泛型。
去掉了try catch，去掉了重载，去掉了宏定义等等特性，本着简单易上手的目标去的，而且引入goroutine和channel。
让编写高并发不在那么复杂，毕竟谁都不想去pthread_create等等的一堆操作吧，直接go xxx就异步处理了，多骚。
而且Go语言的协程堆栈动态扩张，随随便便就是成百上千个协程，这确实牛逼，毕竟实现了Linux一直想实现的M:N的模型，也即多个内核线程，多个User Space的线程。
but，重要的事情要说三遍，but，but，but，很多人开始不管任何场景，直接选型用GO，这好吗？这不好！
GO语言诚然有很多优势：简单易上手，高并发性能，编译快，编译后由于直接是机器码所以代码很小。
但是问题来了，GO语言能代替C去编写Linux内核吗？想都不用想，不可能。每个语言都有它适用的地方。
那么就来聊聊大家最关心的吧，用GO语言来代替Java编写Web后端业务逻辑合适吗？
我的结论是部分合适，部分不合适。
就如同DDD里说到的三种模型：事务驱动，MVC，DDD是根据不同业务复杂度来选定。
随着业务复杂不断增加我们可以选择使用DDD来进行设计，但是对于中小型公司来说选用MVC的较多。
而事务驱动型也即原生Servlet+JDBC的方式我想在如今没人用了吧。
但是我可以告诉大家一个结论当你选择使用GO语言来编写业务的时候，这就是事务驱动型的开发，也即使用GO语言来面向过程编程，这好吗？
还可以，对于小型业务来说，快速开发何乐而不为，一个go xxx各种异步，而且没有Java生态那么多配置，直接import库函数 CRUD return json就行了。
诚然，我经常说的过去，我们使用面向对象的语言来写面向过程，就如同用Java的编写MVC的框架一样，那么现在GO语言了，没有面向对象，别给我说接口，我这里说的面向对象特性。
所以各位熟知的设计模式，很多无法套在go上使用，毕竟这个语言的使命就是C++而不是JAVA。
所以GO语言如果继续发展，不管怎么样它肯定会占据C++的一些领域，把C逼到最底层，把JAVA逼到更上层，更贴合于业务处理。
最终我的结论是：GO语言诚然厉害，但是在业务处理方向上和业务架构上，JAVA还是一个王者。
GO语言你的目标是C++、RUST、python，但是业务处理还期待你的发展。
希望在以后对于大型业务场景上能够看到GO的声影，目前GO最适合的场景是业务逻辑不复杂的中间件场景。
image.png
