在Docker能轻易的创造功能化切分来看
跨语言的合作看样子在未来将越来越容易
也就只有功能与功能之间的通讯协定一致即可
容器内的实作是什么语言实现的并不重要了
而功能则可挑选最适合的语言来进行开发
需要执行速度可挑选编译式语言
需要快速开发可挑选脚本语言
应用在不同的情况下
挑选最适合的语言来应对
可能会是将来的senior要求技能之一？
这比过去在单一语言下选择框架
提供的选择性又来的更高了
而在后续维护上也将产生新的问题
维护成本可能因为语言多种
而造成人员流动后的无法维护问题
所以未来可能选定双语言为主
在两种语言下根据执行速度与开发速度
来做不同的应用策略
将会是一种流行？
也或者Micro Service架构会死
Monolith继续当道？

你可以学很多语言，很多新的技术那都是没问题且值得鼓励的但不一定要同时用在 1 个专案以内，跨度太多技术时，管理上会相当困扰。而容器化只是延迟你面对问题的时间，什么都封起来，只至最后一个稳定的版本是能动的。当原始团队脱离后技术的再选择（头洗下去，学跟他一样的语言、技术）或整并还是得面对的问题。

楼上，打好多字或许可以定义Micro Service，不一定要多语言而是要多功能

一个语言多库多框架。

一楼是对的

以为多语言是可称为程式设计师的基本。

好像跟 Docker 没太大关系, 只要接多系统就会这样了 @@JS C++ JAVA PHP 目前公司产品用这几个 (多个系统互串)