2022 年冬月, Java 后端工程师拒绝使用 kotlin 的技术原因有哪些?

@witcherhope 工具也有好用和不好用的区分。

@yannxia 連 scala 大佬鄧草原都轉投 java17 了

又不是不能用.jpg ，工程语言技术因素真不重要，好多上古系统跑的好好的也没人说他啊

好多糖啊

语言决定论主张语言决定思考模式, 语言相对论主张语言结构及使用可能影响思考模式及决策方式 -- 无论哪个版本, 至少认为"自然语言"对思考的影响是显著的, 不过对于主张编程语言工具论的 Java 程序员来说, 至少编程语言对他们没啥影响, 毕竟他们写代码从不思考.

言归正传, 私以为 kotlin 是伪装成现代编程语言的 java, 现代编程语言的一个重要特性是支持 structural type system, 否则语法糖会变得特别苦.

举个例子 java 中的 lambda 其实是只有唯一方法的接口的匿名实现, 而 kotlin 中, 看起来我们可以定义 T -> R, 但实际上它和 java 没啥区别, kotlin 的标准库里面绝望地定义了 Function0 到 Funciton22 以及 FunctionN 合计 24 个 class;
```
var lambda : () -> Unit = ::func
var kFunction0 : KFunction0<Unit> = ::func
var kFunction : KFunction<Unit> = ::func
var kCallable : KCallable<Unit> = ::func
var function : Function<Unit> = ::func
```
以上五个对象, 如果两两给对方赋值, 哪些可以编译通过? 如果使用 IDEA 的创建函数功能, IDEA 的默认补全是哪个类型? 如果 func 是一个泛型函数怎么表示?

我们知道 interface 作用是用来弱化 class 的 type 语义 上. 而在 JDK15 (大概)前, kotlin 的密封只能作用于 class 不能作用于 interface, 这是反设计的, 而随着 JDK15 的推出, kotlin 的接口也能被密封了, 而且 JDK15 以前的运行时也支持这个特性, kotlin 的基本盘安卓很长一段时间都不会升级到 15. 当初理由现在看起来不成立了. 很多时候会惊喜地发现 kotlin 居然有这个特性, 然后失望地发现这个特性存在各种各样的陷阱, 这个特性受限于 JVM 就这样, jetbrains 已经做得(当时认为的)最好了.

还有一些我不喜欢的设计, 比如说我可以写出这样的迷惑代码 `fun Unit(Unit : () -> Unit) = Unit(); Unit`, 我们在读代码的时候, 大脑也是容易出 bug 的编译器, 没有必要为了这样的特性丰富 AST.

解构函数也是硬编码, 而且是从 1 开始. 至于协程 null 在调 java 代码时非常难受别人应该都讲过了.

@Aurt 这个比喻太妙了

@urnoob #87 既然 Java 对付 var 都用 idea 了，C++就上 clion 了，什么 auto 、lambda 、structured binding 都能显示对应类型，阅读调试都方便。

没有广泛被使用的原因只有一个, 那就是并没有好用到愿意让大家切换过去.

学 go 不好吗?

为啥不换 go

@Leviathann 应该不用怀疑水平差距，react 那坨不理解 PFP 是基本别打算会用得顺的。
虽然这不代表 react 更顶用。

@kwh 可以看懂一些 Android app 的实现以及自己写。现阶段新项目用 Java 可能会被鄙视。
另外 Dart 乱缝合特性的问题比 Kotlin 严重，只是表面上语法看起来更 Java 点。

@dcsuibian 难道不是会越好奇怎么那么多那么弱鸡的山寨语言也意思好被发明出来么。

@urnoob 看到那什么都往语法糖里装的用户就想笑。
保守估计这些用户中 90%以上既不懂什么叫语法(syntax)，也不懂什么叫糖，经常性地混淆语义特性甚至把盐当做糖，
考虑到现有 PL 教学质量的垃圾，基本上语法糖这个词就是会自己实现语法糖的用户才顶用。
比如 Scheme 的卫生宏写成 API 就叫 syntax ，作为一线特性能轻易简化实现做出糖味，所以合格的 Scheme 的用户没有不会语法糖的。
如果 C/C++ ，那么得熟练用（不卫生的）宏提供 API 才会实现糖。但是语言规范中是不是糖的东西就未必理解的对了。
——比如说，C 的 E[p] 和 *(E + p) 因为语言规则钦定等价而能原地变换，这个明确是语法糖（虽然基本没什么甜度）；而 C++ lambda-expression 因为一些 unspecified 的语义性质（比如 layout ）不可能用等价的方式确保能用 C++ 或者外挂预处理阶段一对一翻译实现，所以就不是 C++ 的糖，不少半吊子 C++ 用户即便会玩宏也不理解这一点。
——（更何况很多用户根本就没意识到，C++ 里什么能叫 syntax 都是个问题。）
至于 Java 之流的所谓后端语言就更是笑话了，不仅没熟练看会 JLS 之类 spec 的要求就能上岗，语言里连宏那么弱鸡的造糖设施都没有。这样的用户，不到有本事自己发明语言自己实现的程度，何德何能脑补得清楚什么叫语法糖？

@matrix67 “语法简单”就算了。
没有天赋一眼看穿文法设计的毛病也没自己独自写过严格符合 spec 要求的 parser 的，还是不要误导别人的好。
最简单地：C 的 syntax 都不是 CFG 能完整表示的。而且 normative 里的东西甚至还不都是 formal 的（像嵌套 if 这种）。
汇编五花八门的就更跳了。
另外别忘了 C 和一般汇编器还都是能预处理的。

@zzzzzzZ 也不反省反省为什么会争得起来。
不就是到处水货还好意思逃避优劣标准？到底谁是巨婴？谁在制造巨婴？

@yazinnnn paulg 其实挺水的，不过爆杀巨婴是绰绰有余了。
起码会去思考这个问题。

@aguesuka 我怀疑还是有那么些思考的，否则不会那么容易理解翻车的地方取得一致。
只不过这种思考大致上的效果就是把 ISO C“编译”成谭浩强 C 这样自以为可以熟悉的劣等方言。
顺便，我是把代码使用的语言还原成λvC-derived calculi 来 reasoning 的，而且效率足够到让人看不出实现，所以足够应付陷阱——绝大多数语言作者还没这本事构造出这种方式处理起来麻烦的场景塞到语言设计里。
这也导致我天然鄙视 Java 之流非得多绕弯弯才能翻译得干净（ reduce 到λvC ，不需要 PFP ）的语言。不过，考虑到设计缺陷的客观性，这也基本上不算是偏见了。
不过，我同时看不惯所有类型规则不可由用户自定义编程的静态类型语言。（所以你所谓的“现代”语言的特征对我来说比较返祖。）

gradle 这个东西啊，硬盘杀手；用的没多久，.gradle 目录占几十 GB ，相反 maven 这边就不存在这个问题

好用的不需要吹，不好用的自然会被淘汰

@FrankHB 没太懂, 想听听你对 kotlin 的想法?

支持 structural type system 是必要不充分条件, 就像 lambda 这个古老概念一样, 以前这个特性是可选的, 而现在是必须的. 比如我们不需要 null, 必须要有泛型, 泛型支持协逆变的最佳实践. 尽管早有有了这样的想法, 但是直到最近(10 年?)才形成共识. 比如说我今天的暴论: undecidable 的类型体操都是错的, 等到 20 年后说不定就是喝水一样平凡的事情.

怎么说呢，在 jvm 生态上，你会发现，用 kotlin 还是避不开 java 。

@jeesk kt 也配和 scala 比?

@superchijinpeng spark 咋用的 kt ?

@FrankHB 巨婴急了，今年大几啊你这么幼稚？学了几年网课了？

PL 世界那一套在工程领域不适用，你真缺那点语法糖建议了解下高版本 java 。
你这回复太初级看起来也不像是搞 PL 的，只能说是大一仔出来指点江山了。

格局真不够，等毕业写几年代码再回来看你这个帖子吧

@promisenev https://github.com/Kotlin/kotlin-spark-api

@promisenev scala 现在真比不了 Kotlin ，社区、生态、背后的商业化公司各方面，现在 Spark 和 Flink 的核心 API 都在去 Scala