能够稳定地、高效地、优雅地完成业务项目是我一直追求的目标。如果代码不能按直觉预期正确地执行我认为是不稳定的。如果常见的需求也需要写很多代码、花大量时间来实现我认为是低效的。如果本来一行代码就能搞定的功能却需要写十多行我认为是不优雅的。现有的编程语言总有一些地方让我觉得很不满。这种不满不是因为个人习惯或喜好问题而是它真正影响了项目开发效率。为了我追求的目标我决定打造自己的“干活工具”——刚好我还有这个精力。我为什么不喜欢 JavaJava 总是给人一种“把简单问题复杂化”的感觉。同样的需求用 Java 需要的工作量总是比其他语言要多地多。以读取文件为例在多数语言的系统库都提供了现成的函数可以直接读取。但在 Java 里你需要先学习“Stream”的概念然后需要学习“StreamReader”的概念然后再学习“BufferedReader”最后你才可以实现真正的文件读取的功能。虽然很多 Javaer 美其名曰“高性能文件读取就是这样的”但业务中真的需要这么时刻在乎性能吗而且用 Java 写的程序好像总体性能都不如用 Go 写的程序吧Java 最新版似乎有点改进了Files.readString(Path.of(test.txt))一行也能搞定。但Path.of又是什么鬼总之吧不逼你先学习下“Path”这个概念就不是 Java 了。对我来说用 Java 开发就像开拖拉机一样慢当然也不是不能开。我为什么不喜欢 KotlinKotlin 比 Java 确实好太多了但同样热衷于发明新概念。我认为这些新概念仅仅是简化了 Java 的语法但没有本质区别——相当于大家不用学“拖拉机”了但还是需要学“手动挡”——概念的复杂度并没有降低。而且 Kotlin 离不开 Java 生态一个没学过 Java 的人我觉得他也很难用 Kotlin 干活。比如companion object本质就是静态方法、静态类、命名空间的另一种写法而已。其他语言不需要类似概念因为他们要不选择直接使用静态方法要不选择彻底删除静态方法。我为什么不喜欢 RustRust 号称很先进。但我不喜欢需要手动管理内存因为这会增加工作量。虽然手动管理的性能更好但实际业务中我也不需要为了追求极致性能而牺牲开发效率。我为什么不喜欢 Go相比其他语言Go 的简单和性能使它成为我目前开发后端的首选语言。但 Go 的语法实在是太简陋仿佛回到了 C 时代。特别是业务中常用的a ? b : c和a?.fn()使得实际代码量增加不少。我为什么不喜欢 C#在 Go 之前我倾向于用 C# 开发后端。但相比 GoC# 就显得过于复杂了。C# 的约束太多一股“大公司味”如果我的项目有上百人一起开发C# 的合规性约束确实是有意义的。但我的项目没有这么多人一起开发很多时候我不想为了所谓的“合规”而牺牲工作效率。比如 C# 的规范要求所有参数都作 null 校验否则报ArgumentNullException而不是更普遍的NullReferenceException。如果自己的项目不校验显得代码不正规。如果校验了又增加了工作量。我为什么不喜欢 JavaScript/TypeScript从语法上我认为 TypeScript 是所有语言中最优秀的。既符合传统 C 语言的美感又为业务开发提供了需多语法糖。但核心的缺点是“慢”。慢到无法写实际业务的后端毕竟它是单线程的。虽然有很多人反对说很多公司也用 Nodejs 写后端的。但用 Nodejs 写的后端一定不能处理复杂业务的高并发或者 Nodejs 只是个代理真正的业务由其他语言开发完成。我为什么不喜欢 Python将空格作为语法的一部分在代码复制时特别麻烦。特别是业务项目里复制代码是很常见的。我需要的是什么目前我的首选语言只有 TypeScript 和 Go分别写前后端。相比其他语言它们是最好的选择。但我希望为自己打造一门更好的语言它是 TypeScript 和 Go 的结合体拥有和 TypeScript 一样强大的类型系统一样便利的语法糖同时又具有 Go 的高性能、编译能力。它既可以用来写前端也可以用来写后端。对语言设计的思考虽然每个语言都有不同的语法、特性但多数语法本质是相通的纯粹是写法的区别。每个语言作者都有自己的偏执和抉择并试图让他人接受和自己相同的选择。我非常反感有些语言设计者把多数人都熟知的概念换成一个新概念但这种新概念又没有引入什么优势纯粹是习惯上的区别而已。比如 PHP 里面用 “.” 作字符串连接符导致对象调用必须用 “-”在所有语言里独树一帜就是不好的设计。新设计语言时应该尽量追求和主流语言类似因为主流的背后代表有很多已经习惯他的用户。如果没有功能性上的改进尽量不要发明新语法。