文章目录
- 背景
- 以Java的发展看
- 未来的语言形态
背景
带的实习生小伙伴问了我一个问题，大意是未来会不会出现一个全能语言，能解决从数据管理，缓存管理，数据库交互，多线程，NIO，协程，桌面端，移动端，并适配网页样式的所有问题。
这个问题真的很有趣，因为这个问题指向了一个编程语言发展的绕不过去的方向性选择：
究竟是要大而全，还是要小而美
以Java的发展看
我大约从2016年那会儿开始真正参与这个行业。那个时候Java还有一大部分公司在用SSM架构/SSH架构，没有上微服务也没有上容器，更遑论service mesh。甚至于前端也分属后端开发，用的技术基本是JSP或者THYMELEAF。少部分公司为了拓展Java的可用范围节约人力，正在努力探索Swing在客户端开发的潜力。
在这种情况下，其实在六年前那个时刻，Java就是一个大而全的语言。它用Spring做项目的整体管理，用Mybatis或者hibernate做数据库交互，用线程池技术做多线程，用Jsp做前端，用Swing做客户端，发版靠自行打包手动部署，服务监控靠经验，服务缩扩容靠怼人力。
但是到了2022年末的这个微凉的冬天，Java的绝大部分职能都被拆分了，分散到了各种技术模块
从终端到服务器，大概可以这么看：
前端页面：React / Vue等
桌面：Electron / QT等
打包：ci/cd持续交付
部署：service mesh弹性缩扩容、
监控：grafana / promethues监控预警系统
架构：微服务高度解藕
反向代理：Nginx / Kong
缓存：Redis / Mongo
数据库：mysql / Tidb / Oracle / CK / ES / Hbase / Hive
文件存储：AWS / COS等
核心思路就是：让专业的模块做专业的事，一切以项目的高效高可用快速推进为准。
未来的语言形态
我们来思考一下一个常见的案例：
登陆注册鉴权等模块使用Nodejs网关，而涉及真实服务则反向代理分发到各个不同的模块。可能是Python的某些AI模块，可能是Java的某些流批处理模块，也可能是Go / Rust的什么别的功能。
这个案例告诉我们，不仅仅是语言内的功能划分，甚至于不同的业务功能模块，也在迅速解藕。某项功能有更合适的语言，就一定要用更合适的语言。登陆注册鉴权在Java或者Go做的太重，就换Nodejs；数学计算 / AI计算在Java或者Go或者Nodejs都不够完善，就用Python。
也就是说，未来的语言发展方向，必然是数个小而美的语言，在各自擅长的领域成为不可替代的规范，然后多个语言通过统一规范相互交互，成为一个统一的大型微服务。这个微服务架构不再是某一个语言仅仅按照功能区块进行区分，而是按照不同语言的擅长领域，针对性的匹配对应业务。
这就对软件工程师、架构师提出了更高的要求，要对不同的语言体系有高度敏感，同时也要能感知业务形态内容的发展变化。