当有人查看Corda代码时，他们会立即注意到它是用Kotlin编写的-Kotlin是JetBrains的新编程语言，可以为JVM和Javascript进行编译。 这是一个不寻常的选择，在本文中，我想分享一些做出此决定的原因，以及我们“在Kotlin投入生产的那一年”的经验。
为什么选择科特林？
此解决方案可以分为两部分：
- 使用哪个平台？ JVM，.NET，Node，Python / Ruby，Go，Haskell或其他已编译的（以机器代码形式）？
- 如果选择JVM，将使用哪种语言？ Java的？ 如果没有，那为什么呢？ 如果不是，那么还有什么：Scala，Ceylon，Clojure，Kotlin，Python，Ruby，Javascript或Haskell（因为它们都有JVM的实现）。
选择JVM作为平台的原因在企业应用程序环境中广为人知，对此一无所知。 只需说一下，如果您需要一个具有垃圾回收功能的可伸缩，线程安全，跨平台的运行时，并需要有许多文档齐全的库来解决基本的业务问题，那么选择仅限于JVM和.NET。
在Corda的工作开始之初，该项目没有名称，很难想象它会在将来开发成产品。 实际上，当成为Corda的项目于2015年12月（在我上班的第一天）开始时，还没有创建新的公司分布式会计系统的计划。 Corda最初是一组原型，用于探索联盟架构工作组感兴趣的新想法和要求，尤其是那些与数据和提供“ UTXO事务输出数组的可伸缩性”的数据模型的有限可视性有关的需求。以及一般性命令式以太坊智能合约的可编程性。
由于尚不清楚这些原型是否会变成某种东西，或只是用作市场上其他产品的信息，因此我们面临一个艰难的选择。 一方面，我们希望快速高效地探索算法和数据结构。 另一方面，应该仍然有潜在的机会来创建大型公司产品并迅速为其雇用人员。
Java确实满足了这些要求，但是语言中缺乏现代功能大大降低了生产率，更隐含地降低了开发人员的士气。
没有考虑动态类型-静态类型所提供的正确性，开发工具和性能的好处实在太大，无法忽略。
也没有考虑与流行语言根本不同的语言，因为 我们希望能够聘请财务专家。 而且，尽管完全有可能围绕Haskell这样的语言创建团队，但是找到一个具有认真银行业务经验并随机地（随机）地生活在伦敦的人看来是冒险的。 另外，该产品的本质意味着我们的“用户”实际上是使用该平台的插件和应用程序的开发人员，没有必要要求他们学习全新的范例和工具。 我们选择的语言不应限制用户太多。
结果，这些要求使我们离开了Kotlin，Scala和Ceylon。 这些语言非常相似，也很有趣。 我们选择Kotlin的原因如下：
- 与Java几乎无缝集成
- 特别是，Kotlin程序使用标准JDK集合的增强版本（增强的编译器），从而确保不会由于使用其他集合库而导致集成问题。 我们在世界各地的Java库之间来回传送集合，因此不要造成任何问题很重要。
- 从Kotlin类中，我们获得了一个外观简单的Java API，其
get / set / is方法根据类型而定。 为此，不需要特殊的注释或其他操作。 由于Corda提供了专为Java开发人员透明使用而设计的API，所以这是一个很大的优势：从普通代码中，您得到的API只需几个警告就无法与Java API区别开（例如，显式拦截Java中的检查异常需要显式）方法注释）
- 内联小功能（例如
map / filter / fold / groupBy （而不是希望JVM自己完成）是由编译器完成的。 不幸的是，JIT JVM编译器虽然总体上非常出色，但是并不能在所有情况下都消除大量使用高阶函数的开销。 除了允许您从Lambda函数内控制程序执行（注意：例如， 非本地返回）之外，使用Kotlin可以弥补这一点。 这是鲜为人知但有用的功能之一。 因为 在任何地方，我们都以这种功能风格编写代码，如果将其翻译成机器代码的方式不好，我们可能会为自己造成性能问题。 - 由于Kotlin上的代码已转换为相当相似的Java代码，因此几乎所有现有的面向Java的工具都可以直接使用。 对于其他语言，情况并非总是如此。 例如，Quasar难以检测Scala代码，因为它需要方法注释，而Scala将lambda转换为无法注释的方法。 Kotlin Lambda通常是嵌入的（请参见上文），或者可以附加注释。
- 出色的文档和纤巧的标准库使学习变得非常快。 我们没有在空缺中表明需要Kotlin的经验，我们在1-3 年的时间里雇用了没有他的知识的人员，此后团队的新成员便能够编写惯用的代码。
- 根据对我们进行面试的候选人的选择，IntelliJ是最受欢迎的IDE（他们可以自由选择工具）。 在后Java语言中，IntelliJ最好地支持Kotlin。
- 我已经与他取得了令人满意的经历，因此，我确信他的新同事也会喜欢他。
如果不是Kotlin，我们可能会选择Scala：Kotlin很大程度上是受它的启发，两者都是很好的语言。
我们与科特林的一年
感觉如何-在公司申请环境中使用一种新语言的一年？
毫无疑问，最重要的是从同事那里听到他们真的很喜欢与他一起工作。 编程语言是每个人的个人问题，人们通常对此事有明确的看法。 如果您作为一项新工作的首要任务，要求某人学习一种新语言并且甚至没有事先警告它，那么总是存在这样的风险，即同事只会讨厌他，而是发现他讨厌而不是提高他的工作效率。 但是事实并非如此。
以下是我们自己遇到的Java / C＃后企业开发环境中经常出现的一些问题：
- 代码看起来是不同的，具体取决于谁编写。 一般来说，不是什么大问题。 与需要某种设计风格的Go不同，不同作者的Kotlin代码可能看起来有所不同。 但是IntelliJ有一个格式化工具，可以提供统一的代码库样式。 它比Java更受限制，但这足够了。 Java-OOP和Haskell-FI编码风格的对立是一个更微妙的问题，尤其是Scala代码。 对于希望看到改进的 Java的开发人员来说，使用scalaz等库的Scala代码可能很难阅读 。 在这场辩论中，Kotlin坚决支持改进的 Java。 而且，尽管以某种方式进行了函数式编程（ 可能在Kotlin上），但社区（至少到目前为止）尚未分成阵营。 在某些情况下，编写代码的方式就像是Haskell，但可以在codereview上解决。
- 图书馆 在Corda中，我们使用了50多个开源库，并且没有任何问题。 我们从未写过包装器或适配器层。 由于通常在Kotlin，Maven或Gradle上的项目中使用构建系统-没有这些工具的官方Kotlin特定替代品（尽管Gradle引入了Kotlin支持作为一种新的脚本语言！）。
- DSL和SQL。 C＃具有LINQ，Java具有JOOQ，而Kotlin具有Exposed 。 这是Kotlin比竞争对手弱一些的领域之一-公开的示例是使用Kotlin的功能来构建DSL的一个很好的例子，但是该库本身具有不稳定的API，并且是一个辅助项目。 当然，JOOQ可以与Kotlin一起使用，回头看，这似乎是首选。
- IDE /工具包。 当然，用于IntelliJ的Kotlin插件是由JetBrains编写的，总的来说，它很棒。 但是，与Java支持相比，它不那么复杂。 必须手动将新的编辑器功能（例如参数提示）移植到Kotlin，因此，支持本身通常落后于许多较旧的Java插件。 我们还注意到，IDE插件经常会通知内部错误，尽管在一年中IDE例外的发生率已显着降低（而且似乎不影响任何事情）。 使用其他工具也不会引起问题，因为 Java编写的内容通常是开箱即用的 。 一个例外是使用源代码而不是字节码的工具，并且显然不能重复使用。 有了这些，即使在1.0版本发布一年后，Kotlin编译器和IDE插件的调试也不如Java调试。 您很有可能永远不会在
javac遇到内部错误，但是尽管很少见，但我们仍然在Kotlin中看到它们。 - 被用户认可。 Corda用户通常是大型且保守的金融机构。 这样的公司更喜欢使用通用的，公认的语言。 Kotlin既不是彼此也不是另一个，显然在我们开始的时候就引起了一些惊奇。 “为什么科特林？” -这个问题在过去一年中几乎消失了，因为 人们仔细观察并意识到，这并不像使用新的编程语言那样冒险。 我们还尝试通过提供代码示例来促进采用，以证明使用该平台构建应用程序不需要Kotlin知识。 这样的结果并不是很成功-许多第一次与Corda合作的开发人员仍然从探索Kotlin开始。 还不是很清楚这是否是由于我们没有提供足够的面向Java的用法示例和文档，还是仅仅是为了学习一个新的炫酷工具的好借口。 主要投资银行越来越多地采用Kotlin，也为我们提供了帮助。 在过去的一年中，我们从该财团的几位成员那里听说，他们的内部开发团队已经开始认真考虑Kotlin自己的产品：通常是由将Java转换为Kotlin的工具的可用性驱动的，这些工具可以将痛苦的整合减少到现有代码库中。
- 商业支持。 使用鲜为人知的语言的风险是，它们可能会停止开发，或者其目标与围绕产品，用户社区形成的需求不一致（例如，对于研究语言，开发人员的主要目标是创建科学文章）。 我们对Kotlin充满信心的主要原因是JetBrains是一家稳定，盈利的公司，已经在市场上销售了15年以上。 通过将Kotlin引入主要产品的代码中，JetBrains很快开始品尝他们自己的工具。 因此，终止支持的风险很小。 此外，JetBrains已经是一家中年公司，其目标市场（IDE和开发人员工具）已不再是新事物，尤其是不流行的时尚产品，这降低了公司可能被收购的风险，这可能导致不可预测的战略变革。 而且，尽管缺少Kotlin的商业支持包，但实际上，该团队可以迅速解决已知问题。 目前，JetBrains打算在1.0版发布一年后发布下一个语言更新。 此发布周期与公司环境中的开发周期非常相似。
结论？
我们不后悔：在这个项目开始时选择一种年轻的语言虽然有风险，但是很平衡。 他为我们做得很好，我们不会改变选择。