Kotlin 1.4 和未来值得期待的地方

对于企业来说，目前的Android开发面临着许多挑战，尤其是选择哪种技术用于开发最好的Android应用程序。

Kotlin和Java是用于Android应用程序开发的两种编程语言，即使是有技术背景的人，也会混淆Kotlin和Java，更不要说那些不知道这两个词的人了。而自Google推出Kotlin作为Android应用程序开发的第二种官方编程语言以来，Java与Kotlin之战就变得更加激烈了。

另外，包括Pinterest、Evernote、Uber、Trello、Postmates、Corda等顶级公司也已经将他们的Android应用程序从Java转换到了Kotlin——这就引起了开发者们的好奇心：在Android应用程序开发中，究竟哪种语言可以获得最佳的性能？不要担心，阅读本文你就会知道Kotlin 和Java哪种更好用了。

其他的一些问题还有：

Kotlin和Java比较如何？ 对于Java和Kotlin，Android开发者更愿意用哪个？ 同时学习Java和Kotlin是否更好？ 对于Android开发，应该先学Kotlin后学Java吗？ 我应该将Java转为Kotlin吗？ 从Kotlin转向Java是一个好主意吗？ 还有一些谷歌上提问最多的问题：

Android操作系统（OS）上的应用程序大多是用什么编程语言编写的？ Android应用程序用什么语言编写？

什么是Kotlin？

简单来说，Kotlin可以更好地构建一个能在Java上运行的应用程序，并且不会产生很多麻烦。Kotlin是一种编程语言，可以通过制作一款很好的应用程序帮助开发者们在更短的时间内构建应用程序。

Kotlin是一种静态类型的面向对象的编程语言，它是由JetBrains 开发的。它具有与Java的互操作性和简洁性，并支持Android Studio。

Kotlin优于Java之处？

开发者们对于Kotlin 和Java的比较存在多种看法，但是下面是他们普遍认为Kotlin优于Java的地方。

声明数据类型可能既繁琐又乏味，但Kotlin提供了主动类型推断形式的解决方案。 它可以通过查看其余代码来告诉开发者们某个函数正在使用的数据种类，并防止开发者们对代码中表达式类型和值进行不必要的声明。

我们都知道掌握Java及其语法需要多年时间，Kotlin则不是这样的，Kotlin的语法并不像Java那么复杂。 在Kotlin中编写代码比在Java中操作要简单，它利用了之前编程语言中的最佳创意。而且，阅读和理解代码也很简单，调试花费的时间就会更少。

Kotlin允许开发者们在不使用冗余类型的情况下定义函数和静态对象。 开发者可以很容易地在一个位置定义对象和函数，这样读取和调试代码就变得更加容易。最后，用Kotlin编写的代码比用Java编写的更友好、更快速以及更容易。

Kotlin和Java比较

既然你已经知道Kotlin是什么了，那么我们来看一下Kotlin和Java在功能方面的区别吧。

流行程度方面：

当Google于2016年推出其首个稳定版本时，截止到2017年5月，Kotlin的市场份额已增至4.28％。到2017年9月，增至7.54％。

2018年进行的一项调查显示，100,000名Stack Overflow用户中有超过7.54％的受访者使用Kotlin进行Android开发。

但是目前Java的受欢迎程度仍然处于高峰。Java的TIOBE索引可以作为最新证据，表明2019年3月Java是最受欢迎的Android编程语言。

Android Studio 支持方面：

说到Java，Android不支持所有的Java功能。虽然Android完全支持Java 7，但它只支持Java 8的部分功能。

但是，Kotlin在Android Studio支持方面是有效的。因此，在支持全方位功能方面，你无疑可以选择使用Kotlin。如果你计划在未来构建多个应用程序，Kotlin是一个非常不错的选择。

处理Null方面：

在使用Java时，你可以向任何变量发送“Null”。当你使用带有控制的对象引用时，你会觉得这是一种挑战，因为这时你会收到“Null Pointer Exception”。

而这就是Kotlin的一大优势。在Kotlin中，没有哪种“类”（type）在默认情况下有空值（null）。如果开发者们想要在“可空的”变量中保留空值，则必须明确定义这个空值，这就消除了“Null Pointer Exception”。

处理长期网络I/O或CPU密集型任务方面：

Java允许后台进行多线程处理，但很复杂，一个线程会涉及长期的I/O运行或CPU密集型运行。但在Kotlin中，开发者可以运行多个线程，同时又支持协同程序。这些操作在一定程度上会使执行无效，但不会阻塞任何线程。

因此，Kotlin在处理长期网络I/O或CPU密集型任务方面领先于Java。

开发成本方面：

2018年底，Kotlin是最受欢迎和最赚钱的一项技能，Kotlin开发者们的平均年薪约为140美元。随着Android应用程序开发需求不断增加，也亟需对Kotlin熟练的开发人员。因此，你应该做好长期准备，储备更高层次的人才。

相比之下，Java开发人员的招聘成本就比较低了，因为你可以根据项目要求和大量的开发人员商量薪资的事情。

创造更复杂的产品方面：

如果你的目标是大规模地创造一款更加复杂的产品，Java是更好的选择，并且Java的特点支持这一点，因为比起Kotlin，Java更加成熟。

另一方面，如果只有Android开发是主要的目标，那么毫无疑问你应该选择Kotlin，因为它在生产这方面具有优势，并且支持Google。

性能和编译速度方面：

JetBrains声称由于速度比较快，所以Kotlin的性能要优于Java。Kotlin支持内联函数，这些函数允许使用Lambdas的代码比用Java编写的同样代码运行速度要快。

另外，Java编译清洁构建快10%-15%，但是，在编译方面，Kotlin的结果是一样的，甚至还稍微快一些。

Java在哪些方面仍然处于领先地位？

Kotlin可能比较新，并且很受开发人员的欢迎。但是Java除了成熟之外，还是比Kotlin有优势，许多开发人员更愿意用Java来进行Android开发。

Kotlin不具备的特点：

静态成员 通配符类 非私有域 非检查型异常 原始类型 三元运算符a?b:c 如何选择编程语言是一件非常棘手的事情，Java和Kotlin都有自己的优点。因此选择一款适合你的编程语言，需要考虑两个平台的长期战略。

令人不能忽视的是，Google现在正在远离Java，但是另一方面，开发者们已经用了Java很长时间了。

在同一个项目中Java和Kotlin可以共存，因为它们在结构上很相似。

原文：https://www.excellentwebworld.com/kotlin-vs-java

Kotlin 1.4 和未来值得期待的地方

Kotlin 1.4 将于 2020 年春季推出，其开发团队在博客介绍了他们对 Kotlin 的愿景：“让 Kotlin 成为您所有工作的可靠伴侣，并是您执行任务的默认语言选择。”因此，开发团队将会让开发者在所有平台上都能使用 Kotlin。

据开发团队的介绍，Kotlin 1.4 将侧重于质量和性能。因为对现在的 Kotlin 来说，提高整体体验比添加新功能更加重要。此外，因为构建速度通常是用户最关心的问题，所以开发团队正在不断改进工具链以解决此问题。但是逐步改进跟不上生产代码库的自然增长：尽管开发团队加快了编译速度，但用户编写了更多的代码，使总体构建时间还不够短。为此，开发团队计划重新实现编译器以使其更快速。

新的编译器

新编译器实现的目标是变得更快速、统一 Kotlin 支持的所有平台，并提供用于编译器扩展的 API。这将是一项多年的工作，不过开发团队已开始好一阵子了，因此新实现的某些部分将在 1.4 中发布，可让这个过程变得更加平顺。

有些功能也已经发布了；例如，如果开发者尝试了用于类型推理的新算法，它是新编译器的一部分。其他部分的处理方法相同。也就是说，两种版本都将在一段时间内可用，旧版本和新版本都将处于实验模式；当新的稳定后，它将成为默认版本。

新的前端（front-end）加速

开发团队期望新编译器提高的速度将来自新的前端实现。

为了提供一些背景信息，可以将编译想成吸收源文件并将其逐步转换为可执行代码的管道。此管道的第一步俗称为编译器的前端。它解析代码和命名、执行类型检查等。此编译器的这一部分也可以在 IDE 中使用，来高亮显示语法错误、导航到定义并搜索项目中的符号用法。这是 kotlinc 如今花费最多时间的步骤，因此开发团队希望使其更快。

当前的实现尚未完成，并且不会在 1.4 中到来。但是，大多耗时的工作都是由它完成，因此可以预期提速的效果。基准测试（编译 YouTrack 和 Kotlin 编译器本身）表明，新前端的速度约为现有前端快 4.5 倍。

统一的后端和可扩展性

在前端完成对代码的分析之后，后端将生成可执行文件。目前有三个后端：Kotlin / JVM，Kotlin / JS 和 Kotlin / Native。前两个以往是独立编写的，没有代码共享。当启动 Kotlin / Native 时，它是基于围绕 Kotlin 代码内部表示（internal representation）构建的新基础架构的，该功能具有与虚拟机中的字节码类似的功能。

现在，开发团队计划将其他两个后端迁移到同一内部表示。因此，他们将共享许多后端逻辑并拥有统一的管道，以允许对所有目标仅执行一次大多数功能、优化和错误修复。

虽然正逐步迁移到新的后端，可是在 1.4 中，默认情况下不太可能启用它们，但用户将能够选择明确使用它们。

通用的后端基础结构为跨平台编译器扩展打开了大门。可以在这管道中添加一些自定义处理和/或转换，这些处理和转换将自动适用于所有目标。在 1.4 中将不提供用于此类扩展的公开 API（该 API 稍后将被稳定），但开发团队正在与合作伙伴 （其中包括已经构建其编译器插件的 JetPack Compose ）紧密合作。

新的语言功能：

Kotlin 1.4 将提供一些新的语言功能。

Kotlin 类的 SAM 转换

社区已要求开发团队引入对 Kotlin 类（ KT-7770 ）的 SAM 转换的支持。如果仅将一个抽象方法的接口或类预计作为参数，则将 lambda 作为参数传递时，将应用 SAM 转换。然后，编译器自动将 lambda 转换为实现抽象成员函数的类的实例。

SAM 转换当前仅适用于 Java 接口和抽象类。该设计背后的最初想法是针对此类用例明确使用函数类型。然而，事实证明，函数类型和类型别名并不能涵盖所有用例，开发者常常不得不仅在 Java 中保留接口才能对其进行 SAM 转换。

与 Java 不同，Kotlin 不允许使用一种抽象方法对每个接口进行 SAM 转换。开发团队认为，使接口适用于 SAM 转换的意图应该明确。因此，要定义 SAM 接口，开发者需要使用  fun  关键字标记一个接口，以强调它可以用作功能性接口：

fun interface Action {
    fun run()
}
 
fun runAction(a: Action) = a.run()
 
fun main() {
    runAction {
        println("Hello, KotlinConf!")
    }
}

请注意，仅在新的类型推断算法中支持传递 lambda 而不是  fun 接口 。

混合命名和位置参数

Kotlin 禁止将带有显式名称的参数（“命名”）和不带名称的常规参数（“位置”）混合使用，除非仅将命名参数放在所有位置参数之后。但是，在一种情况下，这确实很烦人：当所有参数都保持在正确的位置而您想为中间的一个参数指定名称时。Kotlin 1.4 将解决此问题，因此将能够编写如下代码：

fun f(a: Int, b: Int, c: Int) {}
 
fun main() {
    f(1, b = 2, 3)
}

优化的委托属性

开发团队将改进  lazy  属性和其他一些委托属性的编译方式。

通常，委托属性可以访问相应的  KProperty  反射对象。例如，当使用  Delegates.observable 时，可以显示有关已修改属性的信息：

import kotlin.properties.Delegates
 
class MyClass {
    var myProp: String by Delegates.observable("") {
        kProperty, oldValue, newValue ->
        println("${kProperty.name}: $oldValue -> $newValue")
    }
}
 
fun main() {
    val user = MyClass()
    user.myProp = "first"
    user.myProp = "second"
}

为了使之成为可能，Kotlin 编译器会生成一个附加的语法成员属性，即一个存储所有  KProperty  对象的数组，这些对象表示在类内部使用的委托属性：

>>> javap MyClass
 
public final class MyClass {
    static final kotlin.reflect.KProperty[] $$delegatedProperties;
    ...
}

但是，某些委托属性不会以任何方式使用 KProperty 。对于他们来说，在  $$delegatedProperties 中生成对象是次优的。Kotlin 1.4 版本将优化这种情况。如果委托属性运算符是  inline ，并且未使用  KProperty 参数，则不会生成相应的反射对象。最出色的示例是  lazy 属性。 lazy 属性的  getValue 实现是  inline ，并且不使用  KProperty 参数：

inline operator fun  Lazy.getValue(thisRef: Any?, property: KProperty): T = value

从 Kotlin 1.4 开始，当定义 lazy 属性时，将不会生成相应的  KProperty 实例。如果在类中使用的唯一委托属性是  lazy 属性（以及符合此优化的其他属性），则不会为类生成整个  $$delegatedProperties 数组：

class MyOtherClass {
    val lazyProp by lazy { 42 }
}

>>> javap MyOtherClass
public final class MyOtherClass {
    // no longer generated:
    static final kotlin.reflect.KProperty[] $$delegatedProperties;
    ...
}

尾随逗号

可以在参数列表中的最后一个参数之后放置一个附加的尾随逗号，然后交换行或添加新参数，而不必添加或删除丢失的逗号。

其他主要变化

• Kotlin 1.3.40 中引入了的有用的 typeof 函数将变得稳定并在所有平台上得到支持。

• 1.3.60 版本博客文章中已经描述了使您可以在 when 内启用  break 和  continue 的功能。

详情查看：blog.jetbrains.com/cn/2020/01/kotlin-1-4

https://www.oschina.net/news/112801/kotlin-1-4

演讲视频：https://youtu.be/0xKTM0A8gdI

Java 24 岁！ Google 加持的 Kotlin 真能取代它？

Kotlin 最常被用于哪些平台中？

Kotlin 最受欢迎的用途是在 JVM 中，占比高达 67％，而在 Android 环境中，Kotlin 以 57％ 的使用率排在第二位。

哪种 JDK 版本，开发者最常用？

在这一问题中，一直以来，Java 的长期支持版本都极具优势。这不在此次调查中，有 84％ 的 Kotlin 用户选择了 JDK 8。而第二个最受欢迎的版本是JDK 11，占 27％；与此同时，JDK 9 和 10 使用率均为 8％。

是否使用 Java 模块？

在对以 Kotlin 开发者为主的调查中，我们发现有 70% 的开发者表示不会使用 Java 模块，仅有 18% 的受访者称在日常的开发中会用到 Java 模块。

常用的 Android 版本？

在以下的调查结果中，有 82% 的开发者表示使用的是 Android 8.0 Oreo 版本；其次有 78% 的受访者表示最常用 Android 7.0 版本，而对于最新的 Android 9.0，其使用率与 Android 6.0 相同，均为 75%。

从中我们也可以看出一个问题，即当前大环境下，Android 的碎片化依旧很严重。

在哪里运行从 Kotlin 编译的 JavaScr ipt 代码？

有 88% 的开发者表示基于浏览器的方式。

常用的开发平台/操作系统？

相比 2017 年有 48% 的开发者基于 Android 平台来使用 Kotlin 语言，2018 年，66% 的受访者表示最常用 Android 平台。其次，Linux 为第二选择。

整体而言，越来越多的开发者在基于 Kotlin 进行跨平台开发。

基于 Kotlin 开发的 App 类型有哪些？

据报告显示，25％ 的用户正在使用 Kotlin 开发 2 种类型的 App。

15％ 开发了 3 种类型的 App，但大多数开发者仍然只在一种类型的 App 中使用 Kotlin。

Kotlin 开发了哪些类型的应用程序？

在移动互联网时代，无论是 Java 还是 Kotlin，大多数会被用于移动应用开发。在本次调查中，有 58% 的受访者表示，他们正在使用 Kotlin 开发移动应用，48% 的开发者称用其开发 Web 后端。此外，Kotlin 还被用于库和框架、桌面、工具、Web 前端、游戏开发、数据分析、IoT、机器学习以及嵌入式等场景中。

Kotlin 的跨平台实践

在 Kotlin 1.2 版本中，首次引入了多平台项目特性，可通过多平台项目支持 JVM 和 JavaScript 平台的代码共享，随后在 Kotlin 1.3 版本中，JetBrains 的开发团队对其进行了大幅改进。彼时它包含了一组特定的库，可帮助开发者编写多平台代码。

作为 Kotlin 开发者，你是否在 Kotlin 中使用多平台项目（MPP）功能？

对于这一新功能，有 89% 的受访者表示并未用过，仅有 11% 的开发者称使用过。

主要会针对哪个平台使用 MPP 功能？

基于以上使用了 MPP 功能的开发者，大多数会应用于 JVM 平台，其次分别是 Android、JavaScript 和 iOS。

MPP 用户所开发的 App 类型

整体而言，依旧是移动领域使用 MPP 最为广泛。其次为 Web 后端，占比 56%。

在跨平台开发过程中，主要共享哪部分的代码？

“Write once，run anywhere”应该是每位开发者在开发过程中最为期待的一件事。根据调查报告显示，Kotlin 开发者在跨平台开发过程中最常共享的代码为算法和数据架构部分，而这一部分相对而言，也比较复杂。

随后 JetBrains 也对尚未使用 MPP 功能的开发者进行了深入的调查，其中，有 41% 的受访者希望可以实现算法和数据结构的代码共享，32% 的人表示希望数据格式能实现共享。

Kotlin 工具的选型

均出自 JetBrains 之手的 Kotlin 语言和 IntelliJ IDEA，这两者的匹配应用应该不足为奇。

而 Android Studio 又是 Google 基于 IntelliJ IDEA 平台而开发的 Android 开发工具，其为移动开发提供了出色的用户体验。

根据调查显示，有 44% 的受访者称正在使用 Android Studio，其次，有 37% 的开发者使用 IntelliJ IDEA Ultimate 版本。

使用哪种 IDE 进行 Kotlin 开发？

对于 Kotlin 开发者，基于不同的环境开发，所使用的 IDE 均有所不同。就 JVM 平台而言，开发者最喜欢使用 IntelliJ IDEA Ultimate 版本；

在 Android 平台下，则有 76% 的受访者使用 Android Studio。除此之外，在 JS 和 Native 下，开发者最常用的 IDE 均为 IntelliJ IDEA Ultimate。

最常用的构建工具

无论是哪个平台或环境，对于开发者而言，其最常用的工具均为 Gradle，整体占比高达 86%。

库和框架

最常用的 Kotlin 库和框架有哪些？

根据调查发现，自 2017 年以来， Kotlin 库的使用率几乎翻了一番，而且最常用的库也继续受欢迎。其中，开发者最常使用的 Kotlin 库或者框架为 kotlinx.coroutines。其次，令人诧异的是，有 26% 的开发者没有使用过任何的 Kotlin 库和框架。

Kotlin 的生态发展

在此次的调查中，Java 仍是最受欢迎的编程语言，占比高达 42%，不过相比去年，这一数据有所下降。而其中，Kotlin 的发展与其相反，当前有 39％ 的受访者称 Kotlin 为其主要的编程语言。

在本次受访者中，有 86% 的用户为程序员以及软件工程师。

而其公司的规模主要为 51-500 人的区间。

简而言之，当前的 Kotlin 正被各种规模的企业以及组织使用。

Kotlin 的前景

最后，对于 Kotlin 的发展前景，根据调查显示，Kotlin 在处理数据方面似乎更有前途。有 64% 的开发者表示，正在使用 Kotlin 来进行机器学习、数据分析、BI 等场景中。

更多报告内容，可参考：https://www.jetbrains.com/research/kotlin-census-2018/

2020年最受欢迎、待遇最高编程语言的发展方向

时间行至 2020 年，对于编程语言的未来发展，很多人会更多的期待。因此，我们向多位编程专家征询了他们对热门编程语言的看法。

IT行业现在发展普通都比较好，但想自己未来也会有更好的发展，选对编程语言很重要。

但是哪些编程语言前景才更好呢，有人做了一些图直观反应了编程语言的定义：

Python

今年 Python 最大的新闻是，其创造者和“终身仁慈独裁者（BDFL）”Guido van Rossum 退休了，将 Python 交给了 Python 指导委员会（Python Steering Council）。到目前为止，权力转移还算顺利，正如《Python 编程从入门到实践》（Python Crash Course）的作者 Eric Matthes 所认为的那样，这并不足以为奇，因为“长久以来，Guido 一直都能在他自己和在社区中的角色之间保持平衡。”2020 年也将 终止对 Python 2.7 的支持，这很可能会让 其反对者感到头疼。同时，Python 仍然是数据科学的首选语言。

对于 Matthes 而言，Python 令人兴奋的一个方面是“在一个长期以来刻意构建其多样性的社区中，出现了各种有趣而关键的项目。”Python 指导委员会的成员、CPython 的核心开发人员 Carol Willing 也对这些项目表示了赞赏，比如 Binder 服务，它通过我们的 Jupyter Notebooks 创建一个可执行的环境来促进可重复的研究，尤其是当它们超出最初的目标时。她指出，Binder“去年被广泛用于许多 Python 会议的教学研讨班和教程”，Willing 还对 CircuitPython 和 Mu 项目大声疾呼，问到：“谁不喜欢硬件、闪烁的 LED、传感器，使用 Mu，一个老少咸宜、用户友好的编辑器？”

Java

这主要是 Java 方面的好消息。Java Champion Ben Evans 解释道，“关于 Java 消亡的谣言再一次被证明不过是平台批评者的一厢情愿而已。”但这也并非一帆风顺。正如我们去年所注意到的那样，2018 年 9 月 发布的 Java 11 带来了大量的新特性，其中许多特性为容器的使用提供了显著且明显的优势。然而，JetBrains 的调查显示，这个最新版本 并没有被广泛采用，超过 80% 的开发人员仍然使用 Java 8。Evans 想知道，“这是否意味着人们并没有像我们所说的那样在容器中运行 Java 呢？还是人们根本不知道 Java 11 在容器方面的优势呢？”

尽管采用速度很慢，但 Java每六个月发布一次的节奏 一直在不断延续：Java 12 于 2019 年 3 月发布，Java 13 于 9 月发布。据 Java Champion Trisha Gee 所说，它已经开始显示出它的价值了：

每个版本都很小，但都是可预测的。尽管它们并没有令人兴奋的新语言变化，但我们可以看到该语言正在稳步向前发展。此外，它还支持了预览特性的想法，我认为正如我们所看到的那样，它对 switch 表达式非常有效，开发人员应该尝试该特性，并根据使用的情况给出真正的反馈，而不是对抽象的概念性的想法进行反馈。作为回应，对 switch 表达式的语法进行了少量地更改，这是有可能的，因为它是 Java 13 中的一个预览特性，而不是一成不变的。现在，计划将这个更新后的语法作为一个可用于生产的特性在 JDK 14 中发布

当甲骨文将 Java SE 迁移到基于订阅的模式时，2019 年又带来了另一个惊喜。但是，正如 《Learning Java，第五版》（现已发布的早期版本）的合著者 Marc Loy 所指出的那样，“整个 Java 社区 对 OpenJDK 的热情越来越高，它已经开始着手处理这个不幸的变化了。”

至于来年，Evans 建议 2020 年需关注 2019 年的趋势发展：

Project Valhalla 的生产版本还有多久才能发布？提供模式匹配和代数数据类型（Project Amber）的增量策略是否有效？Quarkus 能兑现它的承诺并支撑早期粉丝的信念吗？2020 年会成为 Kotlin 超越 Android 成为重要排头兵的一年吗？这是一个令人兴奋的时刻，我们正处于向新事物过渡的阶段，而且还有很多事情可以做。

Kotlin

谷歌在 2019 年 5 月宣布，Kotlin 现在是 Android 应用程序开发人员的首选语言，这促进了该语言的广泛采用。尽管许多 Android 开发人员仍处于向 Kotlin 迁移的过程中，但那些已经过渡过来的人都知道它能提供的好处了。《Head First Kotlin》 的作者 Dawn 和 David Griffiths 分享了 Kotlin 崛起背后的几个原因：

对于由 IDE 公司创建的语言，Kotlin 能拥有良好的工具支持也就不足为奇了。用于代码契约的实验性 DSL 使开发人员能够为代码的行为方式提供保证。你的函数有副作用吗？它是否能保证返回一个非空值？代码契约允许我们做出这些承诺，而编译器可以使用它们来放宽编译时检查。现在，不同 Kotlin 平台之间的屏障也正在被打破。“expect”/”actual”限定符使开发人员可以更轻松地编写跨 Java/Native/JS 环境的兼容代码。现在，序列化支持意味着可以更容易地将 JSON 数据转换为 Kotlin 对象，反之亦然。

希望 Kotlin 能继续保持其惊人高速增长，而不仅仅是在 Android 上。JetBrains 的开发者权益团队负责人 Hadi Hariri 指出 Kotlin/Everywhere（一系列社区主导的活动，在这些活动中，我们可以在 Android、谷歌云平台和多平台开发中学习 Kotlin 的基本知识和最佳实践）的成功，就是最好的证明：“从 5 月到 11 月，我们已经成功地覆盖了 86 个国家的近 30000 人。2019 年，KotlinConf 连续三年售罄，吸引了 1700 多名与会者。这尤其表明，人们对这门语言的兴趣和接受程度正在增长。”

Go

当 Go 程序员（Gopher）回顾 2019 年时，他们很可能会记得“try”提案的传奇故事。Go 的开发者兼作者 Jon Bodner 解释道：

对于 Go 最常见的抱怨之一是错误处理过于冗长。因此在 6 月初，Go 的核心开发人员们提议 添加一个新的内置函数 try。并发布了一个 GitHub issue 来讨论这个新特性。不到一个月，就有近 800 条评论，其中大多数都是否定的。反对这一新特性的人认为，这一变化使代码变得太“魔法”，并使逻辑流程变得模糊了。在审查了反馈之后，Go 团队将提案标记为关闭，并于 7 月 16 日拒绝掉了该提案。

在这个过程中值得注意的不是这个特性的失败，而是，正如 Bodner 所描述的那样，“过程的发生方式：提出一个特性，讨论也是受到尊重的，但是许多人觉得这个变更与 Go 的风格不一致。最后，掌管语言的人决定尊重大多数人的意见。这就是开发者所说的社区。”

2020 年，Go 的契约规范（也就是众所周知的 泛型提案）应该会更加清晰。Bodner 说，“看起来 Go 将使用一种与其他语言略有不同的方法来实现泛型，但是这种方法非常适合 Go 的习惯用法。”它将有望使 Go 在添加泛型特性（开发人员在其他语言中发现泛型非常有用）的同时，仍能保持其惯用的风格。

Rust

我们采访了《Programming Rust》的合著者 Jim Blandy，以了解他对 Rust 的发展看法在 2019 年发生了怎么的变化。去年，他指出，“Rust 长期以来一直以这样或那样的形式支持异步编程，但是异步函数为这种代码提供了一种语法，这是对 Rust 之前语法的重大改进。”

他对 Rust 语法进行改进的愿望实现了吗？是的，最终：Blandy 解释到 async/await 语法直到 2019 年 11 月 7 日发布的 1.39 版才趋于稳定。“最初，我们希望 async/await 语法可以成为 Rust 2018 版的一部分，但它需要花费更长的时间才能把事情做好。”尽管如此，他仍然对 async 在 2020 年对 Rust 的意义寄予厚望：“将 async 集成到语言中，可以让借用检查器（borrow checker）了解我们在做什么，因此异步代码看起来就像是惯用的 Rust。”

正如 Blandy 所指出的那样，Rust 生态系统正在迅速采取行动，以利用该语言的新表现力。

Rust 社区对 WebAssembly 也很感兴趣，今年 WebAssembly 成为了 C/FFI 的理论替代品 ，可用在需要具有可移植的、高性能的模块的生态系统中。正如 Rust 专家 Nathan Stocks 所说：“我么也可以使用轻量级的沙箱！”令 Stocks 印象最深的是“该理论已经被原型化并被成功地证明了”

以前，我曾把 WebAssembly 纯粹视为一个编译目标，以便在浏览器中运行非 JS 语言的代码。添加这种可以从浏览器之外的任何语言中使用 Web 程序集的能力是令人不寒而栗的。

Swift

Swift 去年最大的事件是 SwiftUI 和 Swift for TensorFlow 的发布。SwiftUI 是苹果公司的最新框架，可用于在所有苹果设备上设计用户界面，Swift for TensorFlow 是一个将谷歌 TensorFlow 框架和 Swift 集成在一起的深度学习和可微分编程（differentiable programming ）平台。正如 Timirah James 所解释的那样，SwiftUI“已经凭借其声明式的特性在开发者中获得了很大的吸引力（理应如此），并且已经被视为是未来 UIKit 的潜在继任者。

”至于 Swift for TensorFlow，Paris Buttfield-Addison 称之为“Swift 的一个全新用途。”他解释道，“Swift 一直是一种优秀的应用程序开发和系统编程语言，也是一种很有前途的 Web 和后端开发语言，但现在，可以使用 Swift for TensorFlow 了，并且它还是一个功能强大的 ML 框架。”原因如下：

Swift for TensorFlow 有一个开发团队，其中包括 Swift 的创始人 Chris Lattner，并且它可以为我们提供（或将在完成后提供）机器学习和数值计算所需的一切。最令人惊讶的是，它对带有自动微分（automatic differentiation）的 可微分编程（differentiable programming） 提供了完全一流的支持，这是由 Swift 的底层编译器框架和设计来实现的。全语言可微分编程将使之前不可能的事情成为可能：一个很好的例子是，当我们构建神经网络时，可以使用标准的编程调试器逐步进行反向传播并调试派生类。Swift for TensorFlow 还为 Swift 提供了完整的 Python 支持，使数据科学家可以将他们所需要的有用且熟悉的 Python 框架与简洁而富有表现力的 Swift 代码进行混合和匹配。

展望未来，看到 Swift 选择的新方向，James 和 Buttfield Addison 都感到很兴奋，James 指出“ 在不同的社区和除移动领域之外的其他技术栈中，特别是在无服务器领域中，Swift 的采用非常迅速”，Buttfield Addison 称之为“令人惊叹的 Web 开发框架，比如 Kitura，以及各种针对细分领域的惊人的框架，比如 SwiftPlot，它是 Python 中无处不在的 Matplotlib 的 Swift 原生版本。”

未来是什么？

变化是不可避免的，并且随着编程语言继续向云、微服务、大数据和机器学习中的新趋势优化倾斜，每种语言及其生态系统都将以其独特的方式继续适应。某些语言可能会在 2020 年发布大版本（C++ 20 将于今年夏天发布，Scala 3 有望在 2020 年底发布）。但有一点很清楚，即使是最小的变更也可能会在程序员的日常生活中引起轩然大波。