返回首页
最新
我一直在探索一种新的系统语言设计，围绕着一个严格的原则构建：
数据的生命周期与创建它的词法作用域完全一致。
外部作用域永远不能保留对内部分配的引用。
没有垃圾回收（GC）。
没有传统的Rust风格借用检查器。
没有隐式生命周期。
没有隐式引用计数。
当一个作用域退出时，内部分配的所有内容都会被确定性地释放。
---
以下是代码中的基本思想：
```rust
fn handler() {
let user = load_user(); // 任务作用域分配
CACHE.set(user); // 编译错误：从内部作用域逃逸
CACHE.set(user.clone()); // 显式逃逸
}
```
如果数据需要逃逸作用域，必须显式地克隆或移动。
编译器在编译时强制执行这些边界。
没有运行时的生命周期检查。
内存管理成为一种结构不变式。
程序结构使得错误使用无法表示，而不是依赖于运行时跟踪生命周期。
并发遵循相同的封闭规则。
```rust
fn fetch_all(ids: [Id]) -> Result<[User]> {
parallel {
let users = fetch_users(ids)?;
let prefs = fetch_prefs(ids)?;
}
merge(users, prefs)
}
```
如果任何分支失败，整个并行作用域将被取消，内部的所有分配都会被确定性地释放。
这在字面意义上是结构化并发：
当一个并行作用域退出（成功或失败）时，其内存会自动清理。
失败和重试也是显式控制流，而不是异常状态：
```rust
let result = restart {
process_request(req)?
}
```
重启会丢弃整个作用域，并从干净的状态重新尝试。
没有部分状态。
没有手动清理逻辑。
---
我认为这有意义的不同之处在于：
该模型是围绕封闭性构建的，而不是熵。
某些不安全状态的防止不是依靠约定或纪律，而是依靠结构。
这消除了：
* 隐式生命周期和隐藏的内存管理
* 内存泄漏和悬空指针（作用域是所有者）
* 跨不相关生命周期的共享可变状态
如果数据必须比作用域活得更久，这一事实必须在代码中显式体现。
---
在这个阶段我想要学习的内容：
1. 可扩展性。这个模型能否在长时间运行的高性能服务器中工作，而不依赖于GC或普遍的引用计数？
2. 效果隔离。I/O和副作用应如何与基于作用域的重试或取消交互？
3. 代际句柄。这个模型能否在不造成过多开销的情况下替代传统借用？
4. 失败模式。与Rust、Go或Erlang相比，这个模型在哪些方面会崩溃？
5. 可用性。哪些常见模式变得不可能，这些是有用的约束还是致命缺陷？
---
一些额外的想法，仍在探索中：
* 具有时代风格管理的结构化并发（没有全局原子操作）
* 每个核心严格固定的执行区域，具有无锁分配
* 仅在崩溃时重试，失败总是丢弃整个作用域
---
但核心问题是：
像这样的严格作用域封闭内存模型在实践中真的能有效工作吗，而不会悄然重新引入GC或传统的生命周期机制？
注意：这并不是“Rust但不同”或对旧系统的怀旧。
这是探索一种根本不同的思维方式来理解内存和并发的尝试。
我非常希望能得到关于这个模型的批评反馈——它在哪些方面有效，在哪些方面崩溃。
感谢阅读。
我之所以构建这个，是因为我想要一个简单的、类型安全的 Java 客户端，用于 Google Gemini，能够原生支持 ReAct 代理，而不需要 LangChain4j 的繁重框架。现在它还支持本地 ONNX 嵌入和 pgvector。欢迎反馈！