Rik Arends 有着 20 多年的编程语言经验，是软件开发与技术创新领域一位卓越的引领者。作为 Makepad 的创始人，他在 Web 技术、UI 开发与 AI 集成等方面广为人知。

八岁那年，他迷上了计算机技术，用它来处理图像和声音。他与计算机的缘分始于自学写程序播放莫扎特，后来又打造了 Cloud9 IDE。这两个“魔法时刻”坚定了他的职业道路，让他不断推动编程语言的边界，并从零开始构建 Makepad，确保它能在多个平台上高效运行。

在把 AI 引入 Makepad 的过程中，Rik Arends 再次站到了前沿。意识到 AI 对软件开发的深远影响后，他致力于一个超越“造一个框架”的完整愿景。通过集成语言模型，他让 AI 得以应用于代码生成、UI 设计等环节，努力在开发者与 AI 之间架起构建应用的桥梁。他强调，高效地嵌入 AI 不只是一个机会，更是行业演进的必然要求。

GOSIM 很荣幸邀请 Rik Arends 来到中国，与全球技术人交流并分享他宝贵的经验。在 GOSIM CHINA 2024 大会上，他发表了题为《Makepad：用 Rust 做可视化应用设计》的精彩主题演讲。会后，GOSIM 的特别对话栏目 Open AGI Forum 独家邀请 Rik Arends 与 CSDN 资深技术编辑王启隆（Eric Wang）进行了一场专访，谈及他的编程哲学、Makepad 的发展历程，以及他对 AI 驱动应用的独到见解。

对话亮点：

  • 我想要一个完整的 IDE，可视化设计器和代码编辑器彼此配合、调校得恰到好处，这样就能把一个应用交到开发者手上——无论他是否借助 AI。

  • 我认为，以一种高效的方式把 AI 嵌进来，对我们是一个机会。而且不只是机会，它是一种必需，因为这就是不久之后软件开发的运作方式。你要么做，要么就不再重要了。

  • 我觉得，正因为 Rust 的报错信息如此友好，它可能会成为最适合 AI 操作的语言。因为你能从 Rust analyzer 和代码编辑器那里获得大量编译信息、类型推断和类型信息，然后输出一个漂亮的错误提示，告诉你哪里做错了。

  • 对程序员来说，自我怀疑不该是放弃的时刻，而应该是运用所学、从错误中吸取教训并再试一次的时刻。

  • 我们下一个研究方向，是一个具备实时编译与设计能力的 IDE。

  • 未来，AI 将参与编程与设计。我们有机会成为开发者与 AI 之间构建应用的桥梁，而具备视觉感知能力的新一代多模态开源 AI 模型也将出现。

1. 人生中的两个“魔法时刻”：从莫扎特到 Cloud9 IDE

Eric Wang: 您是怎么走上现在这条职业道路的？

Rik Arends: 我很小的时候，大概八岁吧，就完全被 Commodore 64、MSX、Amiga 这些有颜色和声音的老式电脑迷住了。那是我对计算机最初的吸引力来源。

我写的第一个程序是用 BASIC 在 PC 扬声器上播放一段莫扎特的曲子，非常基础。是的，那份对计算最初的兴奋从未离开过我。但我确实发现，每次技术迭代，要回到“播放一个声音”这种最基础的状态反而更费劲了。哪怕到现在，这依然很难。我还没真正把 API 做到能回到那种简洁的程度。不过时代变了，现在下一个前沿也许是 AI 音乐，我也说不准。

也许固守过去并不是通向未来的最好方式，但我最初就是这样开始的。

18 岁时，我开始用第一代 GPU——Voodoo 显卡，配合 C++ 开发。那是我的第一个“魔法时刻“。在那之前，你想画点什么，就得写一个 CPU 函数去填充多边形——效率低下，也很难快到足以支撑交互式应用。而有了第一代 GPU，你可以瞬间渲染出一个完美的三维模型。

我的第二个“魔法时刻“，是我决定投身 GPU 加速图形的时候。你只需要懂一点数学、一点矩阵代数，就能做出来。画面突然变得如水晶般清晰，简直像魔法。从那一刻起，我开始对用于设计实时动画的 UI 工具产生了兴趣。

一开始，我做的是基于 XML 应用的 UI 工具，全部用 C++ 写。到 2004 年，我意识到自己做的那个浏览器市面上已经有了。我问自己该不该继续，因为我并不算特别擅长——尽管结果比我预想的要好。

于是我转向学习 JavaScript 和 Web 开发。那是一次痛苦的转变。从“什么都能做”的 C++ 转到 JavaScript，突然变得处处受限、运行缓慢，让人沮丧。但与此同时，给企业开发 Web 应用是能赚钱的。那就是我进入 UI 技术开发的起点。到某个阶段，我们手上的 UI 技术已经足以构建一个 IDE，那最终就成了 Cloud9 IDE。

Eric Wang: 开发一个基于 Web 的 IDE 面临哪些挑战？尤其是现在 AI IDE 正在涌现，而它们依然是云端的。

Rik Arends: 我们是凭着“在浏览器里构建复杂用户界面”的功力进入云 IDE 领域的，而用 HTML 做这件事，至今仍是一小撮人才能胜任的挑战。

一个挑战是 UI 性能——如何操作 DOM，才能让代码编辑器足够快。我的同事 Fabian 是代码编辑技术方面的先驱，这部分由他负责。我们是一家小公司，有一支工程师团队，这个挑战被解决之后，成了后续开发的基础。

另一个挑战是围绕它构建一套 UI 工具包，这部分由我当时的联合创始人开发。我一直觉得 UI 的问题没有被真正解决，因为性能不够快。像代码折叠、动画这些东西我都做不好，它们在 HTML 里就是跑不顺。

所以在我的经验里，UI 才是真正妨碍创新的瓶颈，因为我不想只做和其他 IDE 一样的东西，我想做新东西。但真正的问题出在云端后端上，比如托管编译。当时的云还非常早期，所有人都才刚有第一朵云。这意味着我们必须去寻找一个真正可用的云方案，而这难得离谱。

这让我一度厌恶云计算，因为它不仅管理复杂，而且昂贵——对创业公司来说尤其如此。

2. Makepad 源于对极致 UI 体验的追求

Eric Wang: 作为 Makepad 的创始人，您最初是怎么构建这个框架的？它解决什么问题？

Rik Arends: Makepad 是把整个 UI 技术栈从零彻底重写了一遍。我就想用这种方式来做 UI。创立 Makepad 之前，我做的是 Cloud9 IDE。我一直热衷于构建高性能 UI，以支撑复杂的应用。但我发现 HTML 的限制太大，于是开始寻找更好的方案，尤其是面向代码编辑器、IDE 和设计工具的方案。

Cloud9 是基于 HTML 和 CSS 构建的，我对它非常熟悉。我也意识到，HTML 引擎的速度不足以支撑动态的设计类应用。我一直想把设计和代码整合在一起。

我有一个带实时内联组件和动画的代码编辑器，也有一个规模足够、不只是玩具的设计工具。当时 WebGL 刚发布，我就想：“如果我能做出类似 ShaderToy 的东西呢？“在 ShaderToy 里我看到了一个编写像素着色器的地方。尽管它的执行效率不高，但它让我看到：存在一种不基于 CSS 或矢量引擎的绘制与样式调整方式——也许我们可以用小程序来做样式。

于是我们就用 JavaScript 和 WebGL。我又一次尝试用 WebGL 和 JavaScript 重建我的 IDE，前后彻底从头来过将近五六次，每次都因为某些原因失败了。最后一次迭代，我让 JavaScript 用上了多线程架构：主线程里跑一个显示服务器，Web Worker 里跑应用，只把显示命令和着色器程序发给主线程。我当时真的挺得意的。

问题是，我想用它来实现自己的想法。我试着在 Makepad 上写一个内容生成程序，但大约 30 分钟后，Chrome 就开始不断崩溃，报错信息缺失，也无从判断原因。那时我已经有了一个基于 WebGL 和 JavaScript 的很棒的代码编辑器，但它效率太低，CPU 占用能到 100%，运行得很糟糕。

我一位做游戏开发的热心朋友觉得这 UI 很酷，但它占用了太多 CPU 内存，影响到了其他任务。这件事对我触动很大。UI 通常只占用极少的 CPU，我开始思考做一些真正有用的优化，比如面向 CAD 软件或其他高性能计算任务。虽然我也考虑过放到另一个线程上，但那并不理想。所以我基本上放弃了 JavaScript——试了五六次都没成功。

我的联合创始人 Eddie 曾在 Mozilla 工作并为 Rust 项目做过贡献，他建议我们用 Rust。我想着可以通过 WebAssembly 来实现，那么“在浏览器里运行”的梦想仍然有可能。于是我开始重新学 Rust，那真的很难。

Eric Wang: 那么 Makepad 是如何利用现代 CPU 和 GPU 的能力来提升性能的？

Rik Arends: 因为 Rust 是编译型语言，我把 Makepad 的 UI 模型代码写得高效、简洁，几乎不怎么占用 CPU。我把性能优化到每毫秒能处理 16 次或 8 次操作，CPU 占用保持在 10% 左右。这样 CPU 就能腾出来给其他任务，也不会耗电。我把样式处理挪到了小的着色器程序里，这样就不需要 CPU 去跑矢量引擎的三角剖分或矢量引擎代码，节省了时间。不过 GPU 的效率会略有下降。在处理非常简单或生成式的矢量数据时，Makepad 的 GPU 表现会掉一点，但我认为这个取舍是值得的。只要不是持续重绘，GPU 就不会耗电，而且 GPU 的速度还在提升。所以即便在 GPU 这一侧，我占用的 GPU 时间也一直在减少，这只是时间问题。刚开始做 Makepad 时我还担心 GPU 用得太多，但现在这已经不是问题了。

Eric Wang: Makepad 在跨平台开发上有什么独特的思路？

Rik Arends: 首先，Makepad 的独特之处在于它保留了一定程度的平台特异性，而不是过度抽象。底层平台抽象很难做到一致，因为平台之间差异巨大。Makepad 的后端支持 WebAssembly、iOS、macOS、Windows、Linux 和 Android。这些平台在某些方面相似，但像事件循环这样的实现完全不同。在 Android 上，我们甚至跑在一个特殊的线程里，而不是 UI 线程。图形 API 在较高层次上对着色器做了抽象，把 Makepad 的着色器语言转换成 Metal 或 GLSL。

然后，我为每个后端实现了一个场景图解释器，以避开底层平台抽象的复杂性。像 WGPU 这样的底层抽象也许更好，但它们往往过于复杂，不适合 Makepad。WebAssembly 就更奇特了——它是一个消息传递式的后端，所以底层实现可能导致性能很差。而高层次的平台抽象，给 Makepad 带来了编译时间上的优势。

由于我们的代码库涵盖了从平台层到上层的一切，对外部库的依赖极少（尤其是平台层的库），我可以在 10 秒内编译出包含所有组件和内容的 Makepad Studio 或 IDE。我尽量让代码保持简洁。即便在处理字体支持时，我们也避免背上沉重的负担，保持精简，看看能不能一直这样走下去。

快速编译是开发中一个至关重要的起点，因为最终的结果很难预测，而快速的编译流程为后续开发打下了好的基础。

Eric Wang: 与 Rigged 或 Flutter 这类流行的 UI 框架相比，您认为 Makepad 的优势在哪里？

Rik Arends: 我关注的是构建一个完整的愿景，而不只是一个框架。我想打造一个完全一体化的开发环境，把可视化设计器和代码编辑器结合起来协同工作，为开发者提供一个能高效使用的应用——无论他是否借助 AI。用户点一个按钮，就能把应用部署到移动端、Web 或桌面。我相信这种全面的思路会是我们的关键差异所在。

我印象中 Flutter 没有设计工具，尽管可能有人为它做过一个。Web 领域有过 Webflow 之类的尝试，但都算不上真正好用。在 Web 协作方面，Makepad 使用 Web canvas 做嵌入；但在其他操作系统上协作能力较弱，因为它用的是自己的 Metal 窗口。所以我们正在考虑可选的 WGPU 后端增强，比如与 Bevy 这类系统的互操作。不过主要目标还是实现我们设定的价值，兼容性可以往后放。

3. Makepad 将成为开发者与 AI 之间构建应用的桥梁

Eric Wang: 展望未来，您对 Makepad 的发展有什么计划或愿景？

Rik Arends: 正如我在演讲中提到的，旧的软件开发模式正处在转折点上，而 AI 会对它产生重大影响。这意味着，把老的 Visual Basic 那一套照搬到 Rust 上，不足以支撑 Makepad 未来的发展。因此我们正在重新思考并探索：在一个由 AI 驱动的未来里，Makepad 能扮演什么角色。未来，AI 将参与编程与设计。我们有机会成为开发者与 AI 之间构建应用的桥梁。在我的设想里，具备视觉感知能力的新一代多模态开源 AI 模型将会出现。

理想的 IDE 应该允许 AI 生成 UI 并即时展示结果。如果结果不符合预期，AI 可以自动修正，无需人工干预。我们还可以把 Rust 编译器的错误信息集成进来。我认为 Rust 的报错非常友好，我们可以从 Rust 的 analyzer 和代码编辑器中收集大量编译信息、类型推断和类型信息，然后展示清晰的错误提示。所以它可能会成为最适合 AI 驱动操作的语言。不过这只是一个假设，我还没有验证它，但这肯定是我们要研究的方向——一个具备实时编译与设计能力的 IDE。

我相信高效地嵌入 AI 不只是机会，更是必需，因为这是行业不可避免的方向。你要么跟上趋势，要么被甩在后面。

Eric Wang: 目前 Makepad 集成了哪些 AI 功能？

Rik Arends: 第一个集成的功能是语言模型。做法很简单——我写了一些带注释的示例代码，通过输入上下文和需求来引导它，再加上纠错代码。结果表明这个方法效果相当不错，它能有效地生成着色器语言、UI 领域特定语言以及 Rust API 代码。不过它的可扩展性还需要时间来验证。我还不知道最终结果，只是分享一个概念验证。

Eric Wang: 是什么启发您把 AI 集成进 Makepad 的？这是最近才有的想法吗？

Rik Arends: 这是比较近期的事。就像我说的，这件事我做了 10 年，它源于我在 Cloud9 时期遇到的前端工程挑战。这比我预想的要久得多——我不得不放弃 JavaScript、学习 Rust，并彻底重构整个系统。

如果你把我开始学 Rust 半年后的 Makepad 和现在的做对比，会发现它已经被优化过好几轮了。而与 JavaScript 不同的是，我们能够优化和重构 Rust，因为它的编译器会给出非常有帮助的错误信息。但如果你去重构 JavaScript，运行时会冒出各种各样的问题，那种体验糟透了。

所以 Rust 极大地提升了我的效率。我没有固定的时间表，只是朝着既定的方向推进。随着时间推移，我开始思考集成 AI 代码生成。但一两年前的实验错误太多，无法实际使用。

而当 OpenAI 的 GPT-3 发布时，我看到它能生成高质量的代码，于是重新开始研究开源模型，并意识到开源模型并没有落后太多——它们正在追上来。

至于 Makepad，我希望至少当我问这些 AI 模型“你知道 Makepad 吗”时，它们能有所了解。Makepad 显然在训练数据集里，因为 AI 已经读过我们的代码库并基于它训练过。

Eric Wang: AI 集成如何增强 Makepad 对开发者的价值？

Rik Arends: 当我们用一门新语言创造一个新框架时——Rust 对很多人来说是新的，我们又要引入一种新的 UI 描述 DSL，而使用着色器时还有许多未知——这就需要准确的文档，并且需要有人去读文档才能用你的系统，而这样的人越来越少了。或者，我们可以让 AI 来处理样板代码：只要给出一个问题，它就能给出最好的答案。我认为 AI 集成可能是 Makepad 作为一个新框架能否成功的关键。

Eric Wang: 您认为 Makepad 面向性能的设计与 AI 结合之后，会对应用开发产生什么影响？

Rik Arends: 我希望我们能用 AI 从更高层的规格说明、自然语言描述或草图生成 Rust 代码，让 Makepad 的性能优势更容易被获取和使用。但 Rust 并不是一门好写的语言——它有借用检查器，对只懂垃圾回收的人来说非常困难。所以我希望借助 AI 提升 Makepad 的性能表现，同时不增加开发者的难度。

Eric Wang: 您认为 Makepad 会如何改善开发者的工作流？

Rik Arends: Makepad 还有很多改进在进行中，但它已经足够强大，可以用来构建应用了。比如我们有 Robrix 这样的示例应用，那是 Kevin 在做的一个 Matrix 客户端，还有 Moly——一个 AI 前端应用。它们是我们 UI 系统很好的测试用例，但构建这些 UI 很有挑战，需要有经验的开发者。我们正在利用现有的基础设施来打造拖拽编辑器之类的工具，并把类型信息集成进 IDE。我们计划明年把这些工具交付给开发者。

4. 程序员成长手册：在 AI 时代“冲浪”

Eric Wang: 您有 20 年的编程经验，涵盖 C、C++、JavaScript 和 Rust。不同编程语言的经历如何影响了您对软件开发的看法？

Rik Arends: 我认为探索编程语言的边界至关重要。2005 年，我在应用开发上触到了 C++ 的极限。之后我深入 JavaScript，从静态编译转向了 JavaScript。JavaScript 引入了垃圾回收，性能因此变慢，但也避免了那些可怕的内存错误。这打开了一种全新的编程范式。比如在 C++ 里生成代码很困难，模板也很笨重，而在 JavaScript 里，你可以在运行时动态生成大量东西。我也学到了很多元编程的知识，那在 C++ 里是做不到的。现在，我有能力在运行时生成专门的函数。

Rust 在某种意义上既是一次倒退，也是一次巨大的飞跃。它把我们带回编译型语言的领域，没有运行时代码生成。但我们获得了出色的内存安全、高性能，以及无需大量开销的底层 API 访问能力。所以每次切换语言，我都能学到新东西，不过这并不适用于所有语言。Rust 没有垃圾回收，也没有运行时代码生成，这改变了你编程的方式。总体来说这是更好的，因为运行时代码生成非常棘手。

Rust 结构化的安全体系确实有益于代码质量。用 C++ 时，我遭遇过导致不可预测崩溃的内存错误，那对我的血压可不太友好。JavaScript 则可能带来不可预测的内存问题，导致垃圾回收器卡顿。而在渲染 UI 时，你显然不希望动画卡顿。用 Rust 虽然有各种限制，但它非常稳定，生成的代码也非常稳定。

Rust 在运行时不会有内存或性能问题，而某些在别的语言里被视为优点的东西，对生产环境的软件未必友好。

Eric Wang: 从程序员的角度看，您认为我们真的需要 AI 具备人类的情感或共情吗？还是说我们只需要一个完美的工具？

Rik Arends: 我很难说清我们究竟需要什么。未来我们会看到各种各样的形态，会有看起来有意识的计算机充当助手。一切都会自然而然地展开，这不是我能控制或引导的。它就像一道朝我们涌来的浪，我们能做的就是努力驾驭它，在上面冲浪。

Eric Wang: 我听说程序员常常经历自我怀疑，而随着 AI 的兴起，这种自我怀疑可能会加剧。您有什么建议？

Rik Arends: 我每次 JavaScript 实验失败时，那都不是什么愉快的时刻。但我从那个阶段学到了东西，然后再试一次。所以，自我怀疑不该是我们放弃的时刻，而应该是我们运用从错误中学到的东西、再试一次的时刻。

我认为完全没有自我怀疑其实不是好事，因为那会让我们无法反思和学习。所以我不惧怕自我怀疑，我拥抱它。但别让它把你困住——用它来做出更明智的决定，为下一次尝试做好准备。

Eric Wang: 对于从传统编程转向 AI 时代的资深程序员，以及想使用或为 Makepad 做贡献的开发者，您有什么建议？

Rik Arends: 我自己也在面对 AI 时代的挑战。我在思考如何把即将到来的变化转化为积极的东西。我意识到，首先，我们不能无视 AI。如果无视它，我们就享受不到即将到来的巨大生产力提升。这份进展还没有完全兑现，但它已经在地平线上了。

许多开发者已经开始使用 Cursor，或者借助 AI 来做文档检索、写注释——这些已经成为他们日常工作流的一部分。但我想强调的是，我们必须拥抱 AI，而不是无视它。新时代正在到来，我们不再需要资深开发者去处理样板工作，AI 可以取代那部分。对许多开发者来说，这将是一个拥有超能力的时代，用 AI 去实现目标。所以我认为最积极的态度，就是享受接下来的这段时期。

Eric Wang: 非常感谢 Rik Arends 为我们带来如此深刻的分析。感谢所有观看的开发者，本期 Open AGI Forum 到此结束，我们下期再见！

作者 | Harper Zhuo
采访 | 王启隆 Eric Wang
编辑 | 何苗
出品 | GOSIM 开源创新汇