【旧闻】一个由Atom开发者用Rust编写的代码编辑器

我们最初计划使用Electron作为为Zed提供跨平台GUI的便捷手段，同时用Rust构建应用程序的核心。但每当这时，我们发现网络技术是实现惊人性能的瓶颈。最后，我们决定建立一个由GPU驱动的可完全控制的并简单的UI框架，以满足我们的需求。

我们称它为GPUI。

我们从Mozilla的Webrender项目中得到了很多灵感。关键的见解是，现代图形硬件可以以高帧率渲染复杂的3D图形，那么为什么不利用它来渲染相对简单的2D用户界面，并采用即时模式架构呢？

Rust的所有权模型要求我们重新思考我们在其他UI编程范式中所学到的很多东西，但其结果是一个框架，使用起来很有成效，而且非常容易推理。

控制每一个像素是一种解放，而以闪电般的速度推动这些像素则是一种冲动。(It’s liberating to control every pixel, and it’s a rush to push those pixels at lightning speed.)

Rust迫切需要一个好的UI框架，让每个人都觉得用起来很舒服......现在有一些很棒的独立解决方案，但没有一个听起来适合每个人的。

Rust有什么是Zig所没有的？

我还没有深入研究过Zig，但与Rust相比，它似乎是一种非常简单的语言，就系统编程语言而言，它是相当有能力的。Rust有什么是Zig所没有的？

Rust有什么是Zig所没有的？

编写代码时不需要经常考虑内存管理问题的能力。

Zig让内存管理变得非常明确，比如强迫你处理分配失败的情况，这很好......但是，这并不是我在PC平台上做游戏时真正要处理的问题。

一旦Rust的基本借用规则成为第二天性，代码就几乎不存在内存管理部分了......一切都会自动地做 "正确的事情"。

在使用Rust这么长时间后，我觉得要传递内存分配器，要存储指向内存分配器的指针都是很麻烦的。

不要误会我的意思，它是一个非常棒的项目（就像Jai、Odin和所有其他即将推出的"更好的C"一样），但是不断有走错路的危险，我觉得很难再回去了。

而且这还没有触及多线程的问题

【博文】关于Rust中上下文和能力的思考

今天早些时候，我阅读了Tyler Mandry的《Rust中的上下文和能力》，我非常喜欢我看到的内容。但是我和很多人一样，有很多问题。这将如何影响语言？这是否会损害定位性/可读性？需要什么来使之适应？

所以这里是我到目前为止的想法的探索。

本周周报

与螃蟹有关的重要诊断改进在nightly版本启用@rustlang

error: Ferris cannot be used as an identifier
--> src/main.rs:2:9
  |
2 |     let 🦀 = 123;
  |         ^^ help: try using their name instead: `ferris`
3 |
4 |     for i in 0..🦀 {
  |

• Rust.cc 论坛: 支持 rss
• 微信公众号：Rust 语言中文社区