2022 年最适合写业务代码的编程语言是哪个？

[aljun]

2022 年，各个语言已经有了长足的发展，但其实业界更多的需求还是写业务。

这里写业务主要考虑的是解决问题的敏捷性与后期的可维护性和扩展性，在性能层面要求不会特别的高，考虑的不只是语言本身的特性，还包括语言本身的生态。当然也需要考虑招人或者新人上手成本。其中业务泛指非计算要求极高的场景。

其中我觉得作为候选的为：

• Java
• Go
• Python （特指有 asyncio 的 Python 3 ）
• Ruby (特指 Ruby3 ）
• Elixir
• Scala
• Javascript（特指 typescript ）

当然也不限上述语言，C++和Rust就算了吧，用那个写业务首先在敏捷性就不太好

因为限定为 2022 年，考虑的范畴都为该语言最新版本，且没有历史包袱

提名请给出具体的理由

[NeroKim]

PHP

[wdhwg001]

@bthulu 多个请求间共享数据？这是什么操作，试图在进程内或实例内共享数据本就不是正确实践。

你不拿个 redis 一类的的话以后扩容怎么搞，而且 c#要是崩了的话数据咋办。

把一个完整业务流程求导本就是 web 开发的架构能力，你看像传统 php ，请求和请求之间都不是一个进程。

[liaohongxing]

@Hanggi 你已经有点无聊了。Go 标准库算健壮 ，这我也同意 。但是没有 filter 就是没有 filter ，人家喷的也是这个 。你叫人家贡献 ，Go 社区也不会收，没有达到主线贡献者 ，发言权也没有。索然自己写个 filter 都能解决。

归根到底没有泛型，强类型没有泛型做不好 filter 的。后面 1.18 出来有个集合操作，里面就有集合的操作 。

Go 还有个 error 。这个是问题，也不是问题 。error 设计的好 。也没问题, 基本上两个大喷点无法反驳 。

[iyaozhen]

实话实说 JAVA 没有之一

虽然现在写 Go

[3dwelcome]

@lujiaosama “LZ 都限定了 ts 了, ts 没你说的那些缺点. 现在连前端都不直接写 js 了.”

这就和那句 Any application that can be written in JavaScript, will eventually be written in JavaScript.一样。

理论上你能用 JS/TS 写出任何代码。

而事实上，那些复杂的大应用，大家都在用别的语言，翻译成 WASM 后，使劲往 JS 里搬运。

当然你要说公司前端写来写去，就是那些表单开发，没任何深层次的功能和算法，那么 TS/JS 还是够用的。

[BeautifulSoap]

@liaohongxing 我真的怀疑你到底有没有用过 Go 语言或者拿 Go 语言开发过很多项目，一天到晚盯着我说的 filter 说事，我原话是”除此之外还有很多功能也同理”，这里的"很多功能看到没”？
你如果真的经验足够，参与项目够多，你就会发现标准库里除了没有 filter ，还没有数组 insert ，没有返回 max ，min 元素，除此之外获取 map 中的所有 keys ，values 也没有，等等等等并不少。当然这些功能非常简单很多时候一两行就写完的东西，但每到个新项目就都复制粘贴一遍，我觉得这体验“不爽”“很难受”，有问题？难道对你来说每次都要复制粘贴一次是一件非常有快感的事情？还是说你平时开发经验缺乏到连这些现代语言都基本默认内置的功能都没用到过？

至于我一直懒得反驳你让我贡献代码这点，是因为我真得觉得你这说法太奇葩了，多少年都没见过的 you can you up 言论没想到还能在这见到。
你这行为和顾客去餐厅吃饭觉得做的菜有一些地方不太好吃，然后你就跳出来说 “厨师烧得不好吃是有原因的，请你了解厨师为什么烧得不好吃，理解到之后还觉得不好吃那就是你的问题。并且你真觉得不好吃那就请你来改良厨师的菜谱和制作工艺，让我来看看你改良的菜谱到底行不行”
对于你这种耍无赖行为我只能说，你挺棒的

[bthulu]

@Itoktsnhc 你这个有解决跨方法事务问题吗? 没有. 你这个只是在方法内完成了数据库操作, 多个方法间咋办, 完全不考虑事务吗? 还是传递 DbContext? 那如果这几个方法的调用顺序是不固定的, 是不是要在调用这几个方法的外部再创建一个 DbContext 依次传递进去? 那如果突然这个外部方法又需要跟其他方法一起联动且维持事务一致, 是不是这个外部方法又得加一个 DbContext 参数再由外部的外部方法来创建 DbContext? 那如果后面业务再次变动了呢? 你怎么处理? 你不要说你们业务简单不存在这个问题.

[Hanggi]

@liaohongxing 我也觉得自己挺无聊的。

但是最近看到太多奇葩的言论，实在是看不下去。

类似，关系型数据库不要用 join ，API 接口全部用 POST 因为更安全，接口统一回复 200 ，Go 语言没有 filter 所以标准库有缺陷等等。。。
你可以这么用，你们公司也可以这么规定，每个人都有自己的决定权，虽然明白这是国内的现状，但...看到满屏幕这种奇葩言论，还好多人点赞附和，emmm...可能我确实有点无聊吧

[bthulu]

@wdhwg001 实例共享数据不是正确实践, 那什么是正确实践? 假如说你自己实现一个 redis 连接池, 那么你是不是要保存池子的最大最小连接数, 当前连接数, 当前连接状态. 获取连接难道不是多线程的, 难道不用根据这些状态参数来确定是返回池子里现有的空闲连接, 还是新创建一个连接, 或者干脆等待一个空闲连接? 这些状态数据不存在连接池实例里, 你存哪里? 放到数据库里去么?

[duke807]

討厭 rust 、typescript 、java 、c++、c#

後端用 python ，前端用 vanilla javascript ，MCU 用 c

python 我用來做芯片研發（ cocotb ）、工業生產工具、gui 軟件、服務器後台、機器學習在內的各種算法、kicad freecad blender 等開源軟件的 api 接口都是 python

[BeautifulSoap]

@liaohongxing 我真的不否定 go 标准库健壮性，想表达的意思是 go 标准库在一些基本又简单的功能上存在缺失，而这些功能又是几乎所有项目都必须要用的，导致每次要用的时候都得自己写一遍或复制粘贴一遍，体验不爽也不好（但这并不代表我就要否定标准库，说他垃圾之类的，做人又不是二极管，没必要非黑即白）。
而且我用 go 开发了不少项目，这方面少的功能不光是 filter ，还有没有 insert 元素到切片，没有返回 max 、min 元素这些基本功能，map 没有获取 keys 和 value 之类的，等等等等。当然我要明确一点就是这些功能实现起来的确很简单 for 循环几行的事，但每次用到这些其他语言大多内置的功能的时候，都不由地觉得 go 标准库在这方面不太方便

我想表达的也仅此而已

[Leviathann]

@wdhwg001 hibernate 这种重型武器我们都不敢用，高级功能基本都 disable 了
基本就用个 jpa 根据接口方法名自动生成查询的功能。。其他的复杂查询都是用 jdbc
好在 kotlin 拼 sql 比较方便。。

[liaohongxing]

@BeautifulSoap 你提的这些点全都跟泛型有关, 有 maxInt 那就配套的 maxFloat maxUint maxInt64 , 有泛型统统解决，一个泛型方法就行 , min 类似 minFloat minUint minInt64 , max 类似 maxFloat maxUint maxInt64 ,

有了泛型才有 map 容器 ,才能 insert , 才有 keys values , 才能有同类型的 keys , 不然又是 mapInt mapFloat mapUint mapInt64

列表容器类似， 归根到底泛型问题 ，现在泛型方案出来了 。相信这些马上就有。下面是容器的实验版本：

https://cs.opensource.google/go/x/exp/+/master:maps/maps.go

https://cs.opensource.google/go/x/exp/+/master:slices/slices.go

https://cs.opensource.google/go/x/exp/+/master:slices/sort.go

https://cs.opensource.google/go/x/exp/+/master:slices/zsortfunc.go

[BeautifulSoap]

@liaohongxing 十分感谢你能理解我想表达的意思，其实这些我也是知道和泛型有关的，所以我 14L 有说 “希望这方面能随着接下来泛型的发布有所好转”，也是在期待 1.18 发布后这方面有能逐渐补上的可能性（不过 go1.18 因为怕泛型引入的不确定性所以暂时不会大改标准库，估计真要动的话也是要下几个版本了吧）

[Hanggi]

@Goooooos
其实你稍微了解下就能明白，不是说当圣经，而是 Go 语言确实有一些独特的设计思想。

你觉得 filter 和 泛型这类几乎所有语言都有的东西，谷歌那些开发者们不知道吗？

而 Go 语言的设计思想里就有一条就是能用一种简单方法解决的问题就没必要给你第二种。
所以你会发现 if else 可以解决问题，所以不会给你三元运算符（还有一个原因是三元运算符容易被 abusing ）
for 循环可以解决的问题，就不会给你 while 循环和 forEach 循环。

而这种设计思想到底让我们的开发更简单了还是更复杂了是见仁见智的。
但是反观 Go 语言今天的成绩，说明这种思想正在被越来越多人所接受，他们在用这种设计思想开发更多有意义的服务。
这时你就要回来反思，这种看似好麻烦的设计为什么会被这么多人接受？

[liuxu]

@duke807 他們說的好高級，我聽不懂誒，我都是用 c 寫 web ，畢竟我的伺服器芯片只是一片小小的 8 位 attiny4 ，只有 32byte ram ，也不知道能不能跑抓哇狗浪

[Soar360]

我觉得是 PHP

[FirefoxChrome]

C# 但是国内工资真的低

[3dwelcome]

@liuxu 用 C 写 Web ，你还要考虑内存对齐之类的琐事，巨麻烦。

还是简单封装一下，用 lua 写逻辑都要好不少。

[james122333]

@Hanggi
还是有 用反射 不过效能很差... 正在研究