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

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

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

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

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

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

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

展开说下关于 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 年的反设计, 为什么

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

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

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

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

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

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

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

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

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

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

@Slurp 链接贴脸上了还嘴硬

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

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

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

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

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

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

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

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

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

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

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