写点什么

为什么 Java 后端开发没有大规模采用 Kotlin?

  • 2021 年 4 月 13 日
  • 本文字数:2896 字

    阅读完需:约 10 分钟

为什么Java后端开发没有大规模采用Kotlin?

在使用了 Java 15 年后,我写了第一行 Kotlin 代码,到现在已经差不多 5 年了。我们的团队用Utterlyidle替代 Spring,用Totallylazy进行函数式编程。我们是 IntelliJ 的忠实粉丝,并试着充分利用它提供的 Java 工具。


那个时候,我们不只使用 Java。有一些团队对 Scala 感兴趣,并用它开发了一些服务。但是,因为 Scala 与 Java 代码库协作的复杂性以及缓慢的构建时间,对于我们大多数人来说,它并没有太大吸引力。


2017 年,谷歌宣布 Kotlin 成为 Android 的官方开发语言,另一个与我们关系密切的团队开始评估是否可以在他们的服务器端开发中使用它。最后,我们大多数人都去尝试了一下。


我被 Kotlin 给代码库带来的影响震撼到了。它给人的感觉是更高效、更安全,虽然开发工具没有 Java 那么成熟,但也足够好了。


从一门陈旧而冗长的编程语言中解脱出来,并探索哪些编码风格更适合 Kotlin 的特性,这本身就是一件非常有趣的事情。Kotlin 与 Java 出色的互操作性意味着我们可以增量地依赖现有的生态系统和过渡系统,而不会对工作造成重大干扰。


很快,由于对 Kotlin 的兴趣,我们一起开发了http4k,一个用于开发 Kotlin HTTP 应用程序的工具包,并组织了Kotlin开发研讨会,帮助其他团队尝试使用 Kotlin。


最后,我们看到其他各种项目也在服务器端使用 Kotlin,也看到了一些团队强烈不愿意采用 Kotlin 的原因。


有意思的是,这种抗拒并不总是因为编程语言本身。那么,为什么 Java 服务器端开发社区没有更多地采用 Kotlin 呢?


以下是我和我的同事们看到的一些原因。

“我们没有时间学习一门新语言”

这也就是我们在软件开发项目当中经常看到的“忙着砍柴没时间磨斧子”现象。这通常预示着更深层次问题,比如不断增加的技术债务和开发效率问题。


健康的软件项目需要开发者花大量时间去学习。一个有能力的 Java 开发者可以在数小时内掌握 Kotlin 的基本知识,并在数天内提高开发效率。


如果采用新语言可以让他们写的代码更简单,遇到的问题更少,那么投入就是值得的。

“Java 的每一个版本都在变得更好”

这是真的,Java 正在变得更好,而且发布的速度也越来越快。但是,对于处理空值这么简单的事情,仍然远远落后于 Kotlin。


也许 Java 社区已经习惯了这种演化速度。尽管如此,Kotlin 还是提供了一种方法,可以在项目中用上很多 Kotlin 特性。

“作为 Java 开发者,我们感到很自豪”

这种想法是最要命的。如果一个程序员把他们的专业身份和一种编程语言联系在一起,那就没有办法了。


如果说 Java 开发者不想赌上自己的事业踏入一门新语言的未知领域,我可以理解。或者他们可能想成为一个领域的专家,这也很合理。


但是,我也并没有看到哪个 Java 开发者因为使用 Kotlin 而“落后”了。相反,这表明他们一直在寻找适合自己的工具,这是一种积极的特质。

“Kotlin 是一种被炒作的语言,它的未来是未知的”

这是我们在 2017 年经常听到的反对采用 Kotlin 的说法。在那一年,谷歌宣布将 Kotlin 作为 Android 的官方开发语言,让我们确信科技巨头们对这门语言是感兴趣的。


现在,Spring 和 Micronaut 等流行框架似乎已经接受了这门新语言,之前的反对声就不那么经常听到了。


希望这能让更多的服务器端开发对这门语言有足够的了解,并尝试一下。

“我正在使用 Eclipse,不想切换到 IntelliJ”

在 Eclipse 中使用 Kotlin 的体验与 JetBrains 的 IDEA 不太一样。


这是可以理解的,因为销售开发工具是 JetBrains 的商业模式之一,而且这种情况短期内不太可能改变。


对于这些人来说,他们能够期望的是 Kotlin 可以达到一个质量临界点,证明 Eclipse 为它提供进一步的支持是值得的。但在此之前,对于 Kotlin 开发者来说,最好的开发体验仍然是使用 JetBrains 产品。


我认为,IntelliJ 已经是一个更好的 Java IDE 了,所以它也值得一试。

“Kotlin 开发者太贵了,而且很难招到”

这一点很难说,从招聘网站的数据来看,Kotlin 开发者的薪资总体上略高一些。


如果我们只考虑服务器端开发者,就很难进行比较。一般来说,Java 开发者的薪资是最高的,但在 Kotlin 方面并没有足够的数据来进行比较。


有趣的是,在实际当中,我们可以看到高级 Java 开发者经常是率先采用 Kotlin 的人,这可能会给人留下 Kotlin 开发者很“贵”的印象。


在招聘方面,我们并没有觉得很难招到 Kotlin 开发者。我们很清楚,有些工作需要使用这门新语言,并允许开发者在工作中边学边用。


这似乎让 Java 开发者放下心来,并吸引了那些热衷于学习新事物的人。

“Kotlin 太复杂了”

Kotlin 之所以成为 Scala 等语言的替代语言,其中一个原因是它在易用性和高级特性之间取得了良好的平衡,与 Java 具有更好的互操作性,所以更有可能被流行框架采用。


在实际当中,这种反对声与团队的技能、风格和习惯有关。


初学者一般会像使用 Java 一样使用 Kotlin,但随着他们越来越熟悉这门语言,可能会深入使用一些特性(例如扩展和内联函数),从而导致代码库变得越来越难以理解。


在团队完全掌握新语言之前,我们建议尽可能长时间地使用普通的 Kotlin 特性。最后,团队中的大多数人都会在选择很酷的语言特性和保持代码库易于理解之间找到平衡点。

“在一个代码库中使用两种语言让人感到困惑”

这是在实际项目中没有尝试过 Kotlin 的人经常会有的担忧。


在实际当中,当团队意识到新的 Kotlin 代码需要与 Java 共存,那么在一个项目中使用两种语言并不会给他们造成很大的痛苦。


这里有一个有用的规则:“如果一个变更涉及到两种语言,首先将旧代码转换成 Kotlin”。


这样,团队就可以避免大爆炸式的重写,并将需要添加新特性的地方进行逐步迁移。


如果需要保留一些 Java 代码,那也没关系。很有可能是因为这些代码仍然有用,并且没有进行重构的迫切需求。

“我们更喜欢 Java”

在实际当中,有一些场景不一定要使用 Kotlin,一切仍然能够进行得很顺利,团队能够以可接受的速度完成工作。


然而,根据我们的经验,这是例外,而不是常态。通常情况下,这种对语言的抗拒源于缺少时间和兴趣,而不是因为没有可提升的空间。


如果没有在真正的项目中使用 Kotlin,是也很难体会到 Kotlin 的好处的。即使是作为一个实验,也存在很多焦虑。


对于这种情况,我们建议“在工作中边学边用”(以编码道场、培训等形式),创造一个可以进行这种实验的安全环境。


这样可以帮助团队评估他们对 Java 的使用状况,以及是否值得在 Kotlin 上投入。

“我看不出 Kotlin 会带来什么好处”

有时候,Java 开发者意识不到语言方面存在的限制,或者是因为他们已经习惯了。有时候,他们会抗拒新语言,因为新语言会让他们质疑自己正在使用的语言。


在不深入细节的情况下,我们可以说 Kotlin 的简洁性和安全性是它的主要优点。然而,有些人声称他们不认为 Java 的冗长有什么问题,并且写出来的代码也很安全。


在真正去尝试 Kotlin 之前,人们很容易将其忽略掉。而在真正面对它的时候,一些人会继续寻找不尝试使用它的理由。

一些想法

采用一种新的编程语言,特别是在正在进行的项目当中,这对于大多数团队来说都是一个挑战。对变化的抗拒与特定的环境有关,与项目需求和个人原因以及语言本身也有关。


话虽如此,我仍然鼓励更多从事 Java 服务器端的开发者,如果有机会的话,可以尝试一下 Kotlin。


原文链接:


https://medium.com/google-developer-experts/why-are-java-server-side-developers-not-adopting-kotlin-8eb53e06ee99?fileGuid=nbh1KOt8ZzMdpX2m

2021 年 4 月 13 日 14:108889
用户头像

发布了 114 篇内容, 共 28.6 次阅读, 收获喜欢 297 次。

关注

评论 13 条评论

发布
用户头像
使用过kotlin一段时间,是比较爽
2021 年 04 月 21 日 10:41
回复
用户头像
空值处理,第三方库我们防止不了可以做一些包装。但是业务代码的话是否可以使用@NotNull,Optional,规范,工具检查来避免出现空值。如果只是一些语法糖精简代码的话不是很有必要。因为维护两个语言需要双倍的精力。还有就是OpenJDK有多个公司可选,而Kotlin只有一个。也就是使用Kotlin语言依赖Jetbrain公司,而Kotlin又依赖JDK.,双重依赖下风险增大,还有就是Java的调优工具比较完善, 每个大公司都有,而Kotlin少。
2021 年 04 月 15 日 00:19
回复
@NotNull Optional 等工具并不能强制程序员做好null检查。java语言也没有提供良好的语法简化null处理。比如 someObject?.method() ?: throw BadRequestException() 类似这样的语法,使得在java中处理null比较麻烦。

kotlin被编译成class文件,概念上和java互操作性非常好,100%互操作。你依旧可以选择多种jdk作为运行时。

实践中,采用kotlin是在jvm平台上最好的语言,比java好太多,根本不是一个量级。建议所有java程序员都转到kotlin语言上。
展开
2021 年 04 月 15 日 10:33
回复
能说出建议所有java开发者都转到kotlin,能看出来你应该还在用开发者的思维考虑事情
2021 年 04 月 17 日 19:29
回复
同意你说的。技术上讲,新的kotlin一定会有不小的后发优势,这点不假。但站在项目角度,你就得考虑人力,技术风险,等等因素。每个公司都有自己的特定条件,基本上大规模转对于大多数公司是不现实的。
2021 年 04 月 19 日 11:46
回复
用户头像
当你还在考虑要不要用的时候,别人已经有两三年经验了。
2021 年 04 月 14 日 15:28
回复
用户头像
都是主观原型啊
2021 年 04 月 14 日 14:11
回复
用户头像
三线城市的Kotlin+GraphQL的孤独人
2021 年 04 月 14 日 12:59
回复
哪个城市啊

2021 年 04 月 14 日 13:55
回复
温州哈
2021 年 04 月 22 日 09:42
回复
温州不错了 太原作为一个2线 知道kotlin和graphql的人都不多
2021 年 05 月 08 日 15:13
回复
查看更多回复
用户头像
作为一名Java开发者,我觉得Kotlin很简洁,有很多先进的地方。只是惯性太大了,Java也变得越来越好。至于简洁性,我只想说组里就我一个人想用Kotlin,组内其他成员都不愿意去了解,项目中想用也用不了……
2021 年 04 月 14 日 10:13
回复
没有更多了
发现更多内容

架构师01期,第二周课后作业

子文

Mac mini 2020上手体验

Lin

Mac

架构师训练营第 1 期 -- 第二周学习总结

发酵的死神

极客大学架构师训练营

面试中常见的C语言与C++区别的问题

C语言与CPP编程

c++ 面试 编程语言 C语言 编译器、程序语言、CPU

第二周总结

睁眼看世界

极客大学架构师训练营

架构师训练营 Week2 总结

lggl

总结 极客大学架构师训练营

架构师训练营第 1 期 - 第二周学习总结

Anyou Liu

极客大学架构师训练营

架构师训练营第二周课程笔记及心得

Airs

第二周 框架设计作业

钟杰

极客大学架构师训练营

SpringBoot 异步任务

hepingfly

Java springboot 异步任务

什么是依赖倒置原则,为什么有时候依赖倒置原则又被称为好莱坞原则?

魏小龙

敏捷开发 依赖倒置原则

架构一期 - 甘霖 - Week2 - 作业一

小粽

软件设计的基本原则

天天向上

极客大学架构师训练营

架构师训练营第二周学习感悟

吴传禹

极客大学架构师训练营

week1--作业一

hero_genlot

极客大学架构师训练营

第二周作业

alpha

极客大学架构师训练营

回首挑灯看剑谱 - Week2 - 学习总结

小粽

荷之美 | 中国荷苑

xcbeyond

生活 摄影 摄影征文 荷花

架构师训练营学习总结——第二周

文智

极客大学架构师训练营

架构师训练营第 1 期 -- 第二周作业

发酵的死神

极客大学架构师训练营

十七张图玩转Node进程——榨干它

执鸢者

前端 进程 Node

依赖倒置及接口隔离原则

天天向上

极客大学架构师训练营

依赖倒置原则

知行合一

软件设计原则

开源推荐:国内3大主流前端UI表单设计器,千万不要让领导知道

互联网应用架构

Vue Element antd

食堂就餐卡系统设计-作业

Kenny

作业

训练营第二周作业1

Yangjing

极客大学架构师训练营

架构师训练营第二周作业

吴传禹

极客大学架构师训练营

架构一期第二周作业

Airs

深拷贝与浅拷贝到底是什么

C语言与CPP编程

c++ 面试 C语言

架构师训练营 1 期 -- 第二周总结

曾彪彪

极客大学架构师训练营

Spring 5 中文解析数据存储篇-JDBC数据存储(上)

青年IT男

Spring5

Flutter 自动化测试

Flutter 自动化测试

为什么Java后端开发没有大规模采用Kotlin?-InfoQ