Kotlin vs Dart：当“优雅”变成心智负担，我选择了更简单的 Dart

大家好，我是老刘

老刘做Flutter开发有7年了差不多。

我记得早先的时候还经常有人讨论为啥Flutter没有选择kotlin而是选了dart。

当时我罗列和很多原因，同时也说过我个人其实是很喜欢Kotlin的。

想当年，Kotlin 就是拯救我们脱离Java 苦海的。

优雅的 Lambda 表达式、丝滑的集合操作符，效率直接起飞。

但是这两年我发现自己越来越不喜欢用kotlin 而是更适应dart了。

你可能会说：“老刘，这是因为你最近只写 Flutter 吧？”

确实，Flutter的开发工作占比重很大是一个因素。

但如果仅仅是因为框架绑定，还不足以让我改变对一门语言的喜好程度。这背后，其实有着自己对编程的理解和思考。

Kotlin 很强，但 Dart 更香

Kotlin 确实是个强大的语言，各种语法糖简直甜到心里。

空安全、扩展函数、高阶函数，用起来那是真香。

但是，这种强大是要付出代价的，而这个待机通常是开发人员的心智成本。

写 Kotlin 的时候，我脑子里经常要多跑一个线程：这块逻辑是用apply还是also？是用let还是run？

// 这种纠结时刻都在发生，仅仅是初始化一个对象：// 写法1：用 apply (上下文是 this, 返回对象本身)valview=TextView(context).apply{text="Hello"textSize=16f}// 写法2：用 also (上下文是 it, 返回对象本身)valview2=TextView(context).also{it.text="Hello"it.textSize=16f}// 写法3：用 run (上下文是 this, 返回最后一行结果)valview3=TextView(context).run{text="Hello"textSize=16fthis// 如果忘了这一行，view3 就是 Unit}

同样的一个功能，可能有五六种写法，每种都有细微的差别。这种问题在团队协作时尤为明显，每个人的风格都不一样，看别人的代码有时候得脑补半天。

最重要的是他会打破写代码时心流的状态。

反观 Dart，刚开始接触时觉得它有点土。

但用久了你就会发现，这种“平平无奇”才是真爱。

Dart 的语法设计非常克制，它不追求炫技，而是追求直观。

写 Dart 的时候，我不需要在大脑里时刻绷着根弦去纠结语法细节，直接顺着逻辑写下去就行。

// 同样的逻辑，Dart 的解决方案通常只有一种 —— 级联操作符 (..)// 不需要纠结是用 apply 还是 run，也不用担心 this 和 it 混淆varview=TextView(context)..text="Hello"..textSize=16;

代码写出来，三个月后再看，还是能一眼看懂。

这种特质，让我在开发时能更专注于业务逻辑本身，而不是语言特性。

这一点在日常开发中其实是非常重要的。

开发人员的逻辑思路不会经常因为语法问题而打断，一方面能提高效率，另一方面也会大大减少心智负担，不会写一会代码就感觉很累。

AI 时代的生存法则

让我内心的天平彻底偏向 Dart 的最后一块砝码，其实是 AI。

在这个 AI 辅助编程的时代，我们必须认识到一个事实：目前的 AI 模型，本质上还是一个强大的模式匹配机器，它是个“直肠子”，远没有进化到能进行深度逻辑思考的程度。

而 Dart 这种平平无奇的语法，恰恰是 AI 最喜欢的。

因为它足够简单、直观、显式。AI 读得快、懂的透、写得准。

反观那些拥有丰富语法糖和黑魔法的语言，虽然对人类专家来说写起来很爽，但对 AI 来说，却成了幻觉的温床。过多的隐式上下文和多样的语法选择，大大增加了 AI 犯错的概率。

在 AI 时代，谁的代码能让 AI 更好理解、更容易生成，谁就是赢家。

以前我们追求代码要写给人看，现在可能还要加一条——写给 AI 看。简单直白的代码，不仅人类维护起来轻松，AI 辅助生成的准确率也会显著提高。

这才是 AI 时代的生存法则：摒弃花哨，回归朴素。

重剑无锋大巧不工

年轻的时候总想着怎么实现最复杂的功能，怎么把语言特性用到极致。

那时候觉得，能把一行代码写得像天书一样难懂，才叫水平。

但随着年岁渐长，写过的代码越来越多，填过的坑也越来越深，我开始慢慢领悟到“重剑无锋，大巧不工”的真谛。

现在的我，编码风格发生了巨大的转变。不再追求那些花哨的语法糖和所谓的“黑魔法”，而是更倾向于简单、直接、健壮的代码。

举个最直接的例子，以前我很痴迷于各种自动化的依赖注入框架。觉得写个注解，对象就自动注入进来了，多酷啊，多省事啊。

// 以前觉得很酷的“黑魔法”@InjectlateinitvaruserService:UserService// 它是从哪来的？谁初始化的？完全是黑盒。

但现在，我反而更喜欢手动管理依赖，甚至就是最原始的通过构造函数参数传递。

// 现在更喜欢的“笨办法”classUserViewModel{finalUserServiceservice;// 一切都在阳光下，没有秘密UserViewModel(this.service);}

看起来这种方式有点笨，写起来也没那么灵动。但它的好处是显而易见的：直观、清晰。

数据的流向一目了然，依赖关系清清楚楚。出了问题，不用去翻框架源码猜它是怎么注入的，看一眼调用栈就能定位。

我们写代码，最终目的是为了解决问题，为了让系统稳定运行，而不是为了炫技。

哪怕抛开 AI 不谈，我也更愿意写这种一眼就能看懂的代码。

因为它经得起时间的考验，也经得起团队协作的折腾。这把“重剑”，虽然没有锋刃，但挥舞起来，却是最扎实的内功。

当然，必须要承认的是，如果是在构建一个依赖关系错综复杂的超大型系统，或者需要极其严格的解耦和动态替换实现，成熟的依赖注入框架依然是不可或缺的神兵利器。但在我们大多数的日常开发，尤其是 Flutter 这种重 UI、重逻辑直观性的场景下，盲目引入复杂的框架，往往是杀鸡用牛刀，反而增加了维护成本。

5. 总结

从最初沉迷于 Kotlin 的语法糖和“黑魔法”，到如今偏爱 Dart 的朴素与直观，这不仅是编程语言的选择转变，更是对代码本质认知的转变。

另一方面这也是在强大的语法糖和简洁的心智模型中找到一个更适合自己的平衡点。

在 AI 辅助编程日益普及的今天，简单、显式的代码不仅降低了开发者的心智负担，更成为了 AI 理解与生成的最佳载体。

摒弃花哨，回归代码解决问题的本真，Less is More，这或许才是我们在 AI 时代应有的生存法则。

如果看到这里的同学对客户端或者Flutter开发感兴趣，欢迎联系老刘，我们互相学习。

私信免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。

可以作为Flutter学习的知识地图。

—— laoliu_dev