关于

从 2015 开始，我一直在设计和实现一门编程语言。

十多年下来，我推翻过很多设计，也踩过不少坑。这些经历让我对语言设计、编译器架构以及软件工程有了不少新的理解。

我希望通过这个博客，把这些思考和经验整理出来。如果你也对语言设计、编译器开发，或者大型软件设计感兴趣，希望这些内容能给你一些启发。

为什么我要开发编程语言

这些年，我使用最多的语言是 TypeScript 和 Go。

如果只考虑开发效率，TypeScript 是我最喜欢的语言。它拥有非常强大的类型系统，例如自动类型推导、联合类型等特性，既能保证类型安全，又能减少大量样板代码，让业务开发变得更加高效。

但 TypeScript 终究是一门脚本语言。虽然生态完善、开发体验优秀，但在运行性能、部署方式以及资源占用等方面，与原生编译语言仍存在明显差距。因此，在开发对性能要求较高的后端服务时，我通常不得不改用 Go。

Go 在工程实践方面做得非常出色。它坚持”简单优先”的设计理念，编译速度快、部署简单、运行效率高，因此成为了许多后端项目的首选。不过，相比 TypeScript，它的类型系统表达能力有限，在复杂业务开发中需要编写更多样板代码，开发效率也会受到一定影响。

于是，我开始思考：是否能够设计一门新的语言，在保持 TypeScript 开发效率的同时，拥有 Go 这样的原生编译能力和运行性能？

这便是我开始设计这门编程语言的初衷。

我发现，开发一门语言远比想象中困难

最初，我认为设计语言就是设计一套漂亮的语法。

但真正开始实现之后，我才意识到，除了语法还有大量需要解决的工程问题，比如：

• 模块系统应该如何设计？
• IDE 语法高亮、智能提示应该如何实现？
• 怎样才能支持让 AI 生成新小众语言的代码？

很多问题都没有标准答案，不同语言也做出了截然不同的选择。

有些设计，当时觉得非常合理，真正实现之后却发现会带来新的问题；有些看似复杂的方案，最终反而证明是更合适的选择。

随着不断重构和推翻自己的设计，我逐渐意识到：一门优秀的编程语言，绝不只是语法糖的堆砌，而是一整套工程模型（语言、编译器、运行时、工具链）的精密设计。

接下来的文章中，我会毫无保留地拆解这门新语言的设计细节——从具体语法的权衡、内存管理模型的选择，到编译器架构的重构实践。

如果你对其中某个设计有不同的看法，或者有更优雅的实现思路，欢迎在下方评论区直接留言（无需登录），或者发我邮箱：xuld@xuld.net。我很期待听到来自一线的技术交锋与声音。