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

[yazinnnn]

除去一些非技术的原因(如:领导不让用,同事看不懂,学不会,没时间,不挣钱,对比 java 没优势等)

可能对比 java 没优势算是一个技术原因

有哪些技术原因呢? 比如

• maven 配 kotlin 使用有 bug
• 换 gradle 后给我下载一堆不同版本的 gradle
• build 太慢了!
• java kotlin 混写的时候,空安全了个毛线
• 使用的插件对 kotlin 支持不好(点艹 lombok?)
• 毛子语言 /反毛公司的语言,不用(这算政治原因)

贴一些我认为kotlin对比java的优势

• 一般不用写分号
• var和val关键字，不用写final（java可以用lombok实现），以及完整的类型推导（java只有局部变量可以类型推导）
• 类型系统清晰（方法、变量、lambda统一类型后置，存在函数类型，不需要为了一个函数特地定义一个接口），但是这一点对初学者不友好，如果代码组织的不好，可能会出现看不懂的情况
• 类型系统的抽象能力及元编程能力比java稍强一些（kotlin没有type class,需要第三方库拯救）
• 有typealias和import xx as yy语法，不必写全限定类名
• 无栈协程（jdk19有有栈协程，不过两者并不冲突），现有的几个著名后端框架都对kotlin协程有很好的支持（如spring vertx quarkus等）
• kotlin协程实现了结构化并发和语义化的结构化并发（java结构化并发在孵化中）（不过结构化并发在后端领域的应用场景还不太明朗）
• 拓展函数及拓展属性（简化开发的有效手段，通过拓展函数和infix搭配可以组织很简单的dsl）
• 运算符重载（另一个很有用的简化开发手段）
• 区分两可变集合与不可变集合（可能是实际中最有价值的优势？）
• 可以实现函数式中的Monad comprehensions（如arrow通过suspend和context receiver），不清楚java库中是否有类似实现（fsharp、swift、scala都有类似实现，rust大概算半个？不知道csharp中有没有）

[MeatIndustry]

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

[roundgis]

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

[janus77]

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

[blankmiss]

好多糖啊

[aguesuka]

语言决定论主张语言决定思考模式, 语言相对论主张语言结构及使用可能影响思考模式及决策方式 -- 无论哪个版本, 至少认为"自然语言"对思考的影响是显著的, 不过对于主张编程语言工具论的 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 代码时非常难受别人应该都讲过了.

[aguesuka]

@Aurt 这个比喻太妙了

[daveh]

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

[vagusss]

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

[koloonps]

学 go 不好吗?

[xingjue]

为啥不换 go

[FrankHB]

@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 ）的语言。不过，考虑到设计缺陷的客观性，这也基本上不算是偏见了。
不过，我同时看不惯所有类型规则不可由用户自定义编程的静态类型语言。（所以你所谓的“现代”语言的特征对我来说比较返祖。）

[ZeroDu]

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

[potatowish]

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

[aguesuka]

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

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

[NCE]

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

[promisenev]

@jeesk kt 也配和 scala 比?

[promisenev]

@superchijinpeng spark 咋用的 kt ?

[zzzzzzZ]

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

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

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

[superchijinpeng]

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

[superchijinpeng]

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

[promisenev]

@superchijinpeng scala 一直都很小众,要不是大数据很多 scala 的东西,估计都没人用的,但是 scala 的强大 kt 真比不了.

[promisenev]

@superchijinpeng Flink 这个阿里在主导了,啥东西到了阿里手里,都是一通 Java 化,就很恶心

[gowk]

[Macolor21]

想代替 java 的多了去了，这么多年来 clojure ，goovy ，scala ，kotlin 。最后还是 JAVA 用的人多，你为什么不问问自己为什么要用 kotlin 呢

[Slurp]

@aguesuka 「而随着 JDK15 的推出, kotlin 的接口也能被密封了」很难不怀疑是在云

[aguesuka]

@Slurp
??? 你的攻击性让我放弃和你正常沟通

https://youtrack.jetbrains.com/issue/KT-20423/Support-sealed-interfaces

[aguesuka]

展开说下关于 kotlin 的 sealed interface
https://www.reddit.com/r/Kotlin/comments/4io0q5/i_can_has_sealed_interface/
7 年前是这么说的

>> Kotlin does not support sealed interfaces because there is no way to prevent Java classes from implementing the same interface. Therefore, it's not possible to obtain the exhaustiveness guarantee that sealed classes provide.

而上面那个链接里面是这样的
2 年前
>> How about using Java 15 sealed interfaces, and limiting the feature only to that Java version or later?
>> There's no reason to limit this feature to Java 15.

我并没有说 kotlin 所做是错的, 恰恰相反: "etbrains 已经做得(当时认为的)最好了". 我很为不妙的地方是, 尽管已经做得最好了, 但还沿用了 5 年的反设计, 为什么

[hdfg159]

goovy 语法糖更多，哈哈哈哈，语言而已，那个好维护就用那个

[FrankHB]

@aguesuka 对通用语言来说 type system 不是必须的，因为完全可以允许用户对语言的一部分规则进行元编程来改进语言，至少把 typecheker 做成库。（效果另说。）

或者说，如果一个语言的语义强到蕴含了 type system ，它就不那么通用，因为这部分规则原则上无法通过破坏 typing 的方式改变。

根本理由是语言的设计者没资格保证比任何用户都清楚用户需要什么样的 type system 。于是越是强大的 type system ，对越是清楚该怎么对付 type system 的用户来说越鸡肋。

至于 Kotlin ，成也 Java ，败也 Java 。Kotlin Native 大概不会成气候。这语言里没什么的新的和现有历史包袱有代差的导致非它不行的东西。

[FrankHB]

@zzzzzzZ 你谁啊，自我感觉良好有资格钦定什么巨婴，难道是我看漏了的自闭了二三十年的老古董？
说实话，要不是 Luca Cardelli 之流的吨位的，怕还没资格被我婊谢谢，我也确实不知道你有什么适合被挂的 contribution 。
光看所谓对“语法糖”的理解就暴露了要不是纯纯水货，要么就是语文水平有大病直接没看明白上面对口嗨“语法糖”的直球嘲讽。
我再多黑下，基本上所有 Algol-like 的语言（就凭 C 的那坨宏），还没资格来碰瓷语法糖的话题，因为它们的用户连生产正经的“语法”（比如上面提过的 Scheme 的 syntax ）都做不到。遥想当年 Herb Sutter 搞什么 metaclasses ，几年过去了折腾出了个啥？
Java ？更加是空气都没有。多饥不择食才管你这玩意儿混饭吃啊……
哦，工程？姑且就当 Java 的设计还有些利用价值而不只是反面教材好了……行，JLS 的写作风格不方便二次开发我看着不爽，你给重写个？
你这张口 PL 闭口直落代码的格局就约等于没有。等懂了这方面工程主要是写文档而不是什么代码再装熟吧，OK ？

[Slurp]

@aguesuka 😆 怎么不说 Kotlin internal 在运行时不是真 internal ？哦，另外还有 TypeScript 在运行时一点类型没有。JVM 自己还有一堆 Synthetic 呢。「而随着 JDK15 的推出, kotlin 的接口也能被密封了」你能不能先自己试试，Kotlin 1.7 JDK8 能不能编译密封接口，用什么手段实现的？

非要在这说绕不过 JVM 所以 Kotlin 是 Java……

是不是 Rust 绕不过机器码所以也是 C ？。。。

[nieyuanhong]

@GTim 如果 Lombok 不够，比如需要运算符重载，元编程，扩展方法，那就上 manifold https://github.com/manifold-systems/manifold

[aguesuka]

@Slurp 链接贴脸上了还嘴硬

「而随着 JDK15 的推出, kotlin 的接口也能被密封了」下一句就是 「而且 JDK15 以前的运行时也支持这个特性」, 还要我试「 Kotlin 1.7 JDK8 能不能编译密封接口」.下次和别人対线麻烦看全再回.

[Slurp]

@aguesuka 😆不多说了，非要运行时支持才是「能够被密封」。我问你 Kotlin internal 是不是假 internal ？你运行时要这些有啥用？？非要假设别人乱反射你？咋不研究 JVM 已经废弃的 SecurityManager ，搞搞所谓「 JVM 沙箱」？

抛开实用性不谈我就是要硬支持💦

[Slurp]

@FrankHB 还在这里婊别人？你谁？ unilang 半残的状态被多少人耻笑了？

[FrankHB]

@Slurp 你什么玩意儿啊，“你谁”都带复读的？是自知被怼你行你上的价值都没有，就只能表达对婊人有意见了？还是就那么想凑热闹？不好意思啊，你跟上面那个一样没 contribution ，骗我婊空气？
就算真有什么东西，这段时间想挨婊还得排队，想提高优先级，先把你这年龄还没这里任何一个项目时间长的马甲扔了，上大号放 issue 吧。要是嫌弃效率不够，顺带把你钦点的“多少人”at 过来陪你挨个儿 biu ？

[lmshl]

@NCE 我发现我工作十年了，Java 0 基础，但并不妨碍我写了 5 年多 Scala ，最近两年还写了万把行 Kotlin 。
Java 锁、多线程、设计模式、GC 和 Spring 八股文一句都没背过，不影响我写 JVM 上的语言......

[aguesuka]

@Slurp 这次没有提到 「而随着 JDK15 的推出, kotlin 的接口也能被密封了」,看来是承认 kotlin 在密封接口慢半拍 JVM 了.「非要假设别人乱反射你？」是 kotlin 自己 7 年前不做密封接口的理由, 结果成我说的了.

被打脸了还嘴硬, 菜到觉得有 internal 就不用 sealed 了, 还把观点提炼错了

[Slurp]

@aguesuka 🤣🤣🤣「菜到觉得有 internal 就不用 sealed 了」。看不懂人说话建议就别说了。没有运行时保障的特性多了去了，天天幻想别人反射图啥呢？ TS 运行时没类型不活得好好的？

「承认 kotlin 在密封接口慢半拍 JVM 了」自己 BB 扯扯说什么密封接口必须要「运行时」保障，才算「实现」。我说已经实现了又说「我没说 Kotlin 没实现」。是不是灵活观点？

[Slurp]

@aguesuka 🤣 你和 @FrankHB 大抵是同一种人，看不懂别人说话，却无限的要求别人看得懂自己说话。往往打了一堆字，却引得别人痴笑。何止是观点不行，简直是语文都不行。前后矛盾乱说胡话，还要靠一堆「链接」和「参考」来为自己背书。说的每一句仿佛都有一个「大他者」在为自己撑腰，实质上又何其的无助。仿佛在说「你去和链接、参考搏斗吧」，而非在与人交流。

[Slurp]

@FrankHB 你谁？你这不是还在回复我？建议你多回复。天天在一个三流论坛和百度贴吧 BB 。装什么清高？🤮

要求别人「证明身份」，请你自己先证明证明自己的身份。否则就是无稽之谈。🤣 说实话看到你那个 unilang README 的中文和英文水平，就知道你大概是个什么货色。骗不了投资人钱，更骗不到别人的认可，要说又有什么建设性的贡献，恐怕是没有。

真觉得自己清高，那就别在这怼天怼地怼空气，真觉得自己正黄旗了？先把你任何一个项目搞搞好。真没人关心你谁，证明给谁看呢？

[FrankHB]

@Slurp 这里是公共讨论区，回复 OP 的主题能给所有进主题的人看，又不是私人邮件专门 re 。
加上 at 就是顺带让人注意有人接了话免得让人以为当事人是词穷或者被塞抹布了。
（不过不清楚什么状况，我没收到这楼里最近的 at ，是看到最后回复变化才进来的。）

> 建议你多回复。
那得有抖出来什么欠教育的材料咯。
“请尽量让自己的回复能够对别人有帮助”，低级复读应该不是。就你大约也不配被鞭尸。

> 天天在一个三流论坛和百度贴吧 BB 。
天天？一个？不识数吧。贴吧？你 out 几年了？按时间算……你是在贴吧卖课被薄纱所以怀恨在心特意挑事？是不是断炊了啊……那还真是难为你了啊。

>「证明身份」
我对你的 identity 不感兴趣。知道你是谁只是看看有什么 credit 以便找到更有代表性的笑料可以挂出来起到点教育作用。你现在的发挥真是路人都够踩上一脚，我不太有兴趣凑热闹。

> 骗不了投资人钱，更骗不到别人的认可，要说又有什么建设性的贡献，恐怕是没有。
我不清楚你所谓的别人和认可是什么。你要是能发明出所谓的投资人，那不妨给坛友介绍介绍，应该会有很多人感兴趣。
建设性的贡献么，比如把你这样的笑料踩烂警醒 n00b 不要偏听滥信，多少也是功德。虽然总是挤痘痘一样想让你多吐出来让人觉得有意义评价的槽点，但是死活没货，那就算了。只当勿以善小而不为，打死一个是一个。

> 真觉得自己清高，那就别在这怼天怼地怼空气，真觉得自己正黄旗了？先把你任何一个项目搞搞好。真没人关心你谁，证明给谁看呢？
这么说吧，这情况类似是个没学过 C 的人都该比谭浩强有道德优越感，前者至少更加人畜无害。填充洼地那是人人得而诛之，哪需要什么证明？倒是你管这种被怼的货色叫空气，你哪个阴间来的？

[xiaocaiji111]

文言文和白话文，虽然白话文啰嗦，我选择白话文。

[Huelse]

口口声声说用稳定 api 、朴实代码、白话文代码，结果写出来不是一坨屎山就是 bug 一堆，也没见减少很多问题或者开发时间吧？

不想学就不想学嘛，没啥不好意思的，别搞得跟老领导似的样样给自己台阶下。

[xingchenxf]

kotlin 当然是比 java 好多了，这点已经不用证明了。

但是你的理由有些我不认同，尤其是这一点： 有 typealias 和 import xx as yy 语法，不必写全限定类名。 这完全不是优势，而是劣势好不好。
大型工程里，看到各种莫名其妙的类型，简直是受刑。
刚刚看到一个 typealias 写法， 要不是这作者就坐我旁边，怕肉身被打，我真想在公司大群里吐槽这段代码。

kotlin 虽然语法更简单了，但是骚操作也多了，很多时候写的代码，除了作者，别人看起来都是一头雾水。
大型工程里，还是要限制一些骚操作写法。