---
title: Kotlin 给我的感觉有点像 Scala -- ++
date: '2018-11-16 17:12:24'
draft: false
summary: 它像是拿掉了部分 Scala 的负担，同时保留了足够表达力，并把并发工具做得更开箱即用。
slug: kotlin-as-scala-minus-minus-plus-plus
syndication:
- platform: Weibo
  url: https://weibo.com/1648815335/H2WTrpRHG
tags:
- kotlin
- scala
- coroutine
- programming-language
topics:
- software-engineering
type: post
---

内部简单分享了一下 `Kotlin` 之后，我对它的一个直觉总结是：它有点像 `Scala -- ++`。

这个说法当然不严谨，但能大概表达我的感受。

`Scala` 很强，表达力很足，抽象能力也很漂亮，但很多时候它给人的负担也确实不小。语言本身、类型系统、工具链、社区风格，叠在一起后，团队真正吃透它的成本并不低。

`Kotlin` 的取向显然不一样。它没有试图把语言一路推向更强的理论复杂度，而是做了一种更工程化的取舍：

- 比 `Scala` 简化不少
- 但表达力又不至于退回特别保守的水平
- 同时把并发相关的能力往“默认可用”方向推进

我觉得它比较有意思的一点，是对并发模型的吸收方式。

像 `callback`、`async`、`future`、`promise`、`CSP channel`、`actor` 这些思路，过去大家往往要靠不同框架、不同库、甚至不同语言生态来分别体验。

而 `Kotlin` 借助 `coroutine`，有点像是在语言和标准工具链层面，把这些方案往一个统一入口收。

这样做的意义，不是说它把所有模型都完美统一了，而是让开发者更容易在一个相对一致的心智模型里尝试不同抽象，而不是每换一种方案都像重学一套世界观。

所以我会觉得，`Kotlin` 的价值不只是“语法更现代”，而是它找到了一种比较务实的平衡：

- 少一点语言层面的炫技负担
- 保留足够的抽象表达力
- 再把高频工程问题，尤其是异步并发问题，做成更自然的默认能力

如果从团队落地角度看，这种平衡很多时候比单纯追求语言能力上限更重要。

<!-- WEIBO_MEDIA_START -->
## 原微博中的媒体

![](./weibo-4307030456164640-1.jpg)
<!-- WEIBO_MEDIA_END -->