最新

我一直在探索一种新的系统语言设计，围绕着一个严格的原则构建： 数据的生命周期与创建它的词法作用域完全一致。 外部作用域永远不能保留对内部分配的引用。 没有垃圾回收（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。欢迎反馈！

我不是技术专家，也不在科技行业工作，因此这是一个外部观察者的视角。关于通用人工智能（AGI）的市场宣传承诺了斯皮尔曼的g：一种能够适应新问题、未见问题的通用流动智能。然而，工程方面——特别是“专家混合模型”和独立模块——看起来与J.P.吉尔福德的智力结构完全相同。吉尔福德将智力视为大约150种具体的、独立的能力的集合。 问题不仅在于这些部分是如何拼接在一起的。我看到的问题是：当模型面临一个不符合其预定义部分的问题时，会发生什么？他们将如何确保输出不会显得支离破碎，而架构又依赖于在专门“专家”之间切换，而不是使用统一的推理核心？ 具体技能的集合（吉尔福德）与适应任何事物的能力（斯皮尔曼）并不相同。通过优化特定组件，我们正在构建一个在已知任务上表现出色的系统，但可能在真正的通用智能所需的流动推理方面根本缺乏能力。我并不是反对人工智能；我只是觉得我们可能需要重新审视我们的做法。我们不能指望在错误的高速公路上到达正确的目的地。