编程与软件工程gist.github.com
写给 Clojure 程序员的 Rust 指南
Rust for Clojurists
2015 — 2020，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 oakes 写的一篇长文，面向 Clojure 程序员介绍 Rust：从语法、类型系统、不可变性、并发和宏等角度逐项对比两种语言，帮 Lisp 使用者快速理解 Rust 的设计取舍。文中穿插了不少幽默吐槽（比如把 C/C++ 的 include 比作“穴居人”），但整体是一份认真的语言导览。
为什么经久不衰：它为“动态 Lisp 信徒”提供了一份诚实又带幽默的 Rust 入门对照，而动态语言与内存安全语言如何互补，至今仍是选型时的经典议题。
HN 评论精选
指出文章漏掉了 Lisp 的核心优势——运行时热替换，Rust 的静态类型和可变状态使其难以实现。
好文章。但他漏掉了最主要的好处，而且这实际上是我用任何 Lisp 的唯一原因：热替换，也就是在程序运行时直接修改代码。要让它真正可行需要两点：一是没有显式类型，Clojure 里一切都是列表或哈希表，运行时给任何东西加成员都没问题，而 Rust 在编译期做的大量静态检查让这不可行；二是完全不可变的数据结构，如果我的改动抛出异常，程序可以回退、丢弃正在构建的新状态，让我修正后再继续，仿佛从没提交过坏代码——而在 Rust 里异常意味着可能已在多处修改了状态，根本无法回到之前可工作的状态。
hacker_9查看英文原文
Good article. He missed out the main pro though (and literally the only reason I ever use any Lisp): hot swapping. The ability to change code on the fly as the program is running. For this to actually work you need 2 things: 1. No explicit types: Everything in Clojure is just a list or hash map, so I can add extra members to anything at runtime no problem. The amount of static checks Rust does at compile time makes this non viable. 2. Fully immutable data structures: If my changes cause exceptions, then the program can just rewind and throw away the new state it was building, let me fix the error I made, and then continue on as if I never committed the broken code. In Rust an exception would mean I've potentially mutated state in a bunch of places, and now can't get back to the previous working state at all.
REPL 驱动开发才是 Clojure 的核心优势，Rust 缺少同像性，短期内无法替代。
总体是好文章，但似乎漏掉了（至少对我来说）Clojure 及类似语言今天远胜其他语言的最重要一点：REPL 驱动的开发。这比任何“我们为什么爱 Clojure”的理由都重要。只要 Rust 不提供类似的 REPL 驱动开发，在同样任务上我就没有理由选 Rust 而非 Clojure；而由于最后一点（Rust 不是同像性的），这短期内不会发生。当然，做嵌入式开发时 Rust 可能比 Clojure 更合适，但今天它不会在同样任务上取代 Clojure。
diggan查看英文原文
Nice article in general, but seems to miss the most important point (at least for me) of why Clojure (and similar languages) are way better than anything else today: it's REPL driven development. Definitely more important for me than any of the other "why we love Clojure" points. As long as Rust doesn't offer something similar as the REPL driven development Clojure offers, there is zero reason of preferring Rust (for me) over Clojure for the same tasks. Which, because of the last point ("Rust is not homoiconic") won't happen any time soon. Now, if you need to do embedded system development, Rust might make more sense than Clojure, but it won't replace Clojure for the same tasks today.
以实战经验印证 Rust+Clojure 组合的价值，并预测借用检查等会成为通用语言特性。
我用 Rust 为高电流 LiFePO4 电池做远程监控和固件更新系统，涉及底层 STM32 和 ESP32 集成，后端用 Clojure、前端用 ClojureScript，可以印证这一点。Clojure 的动态性和 Rust 的内存安全是强有力的组合，尤其适合通过 websocket 把 EDN 数据流式传给 Clojure/ClojureScript 前端。不过两者都不是终点：我认为最终所有语言都会把内存生命周期管理和借用检查作为语言特性来做运行时优化，这方面有意思的是 Carp。Clojure 似乎在 Lisp 语言大战中胜出；Rust 若用 S 表达式本可以更强，它的宏语言相比 Lisp 是灾难，但我理解他们必须吸引嵌入式 C 人群。
pgt查看英文原文
Having built remote monitoring and firmware updating systems for high-current LiFePO4 batteries in Rust for low-level STM32 and ESP32 integrations, Clojure for backend and ClojureScript on the frontend - I can corroborate this. The dynamism of Clojure and the memory safety of Rust are a strong combination, especially for streaming EDN data over websockets to Clojure or ClojureScript frontend. However, neither Rust nor Clojure is the end-game. Eventually all languages will IMO adopt memory lifecycle management (lookahead guarantees) and borrow-checking as language features to do runtime optimization. An interesting language in this regard is Carp, a high-performance statically-typed Lisp implemented in Haskell with borrow-checking: https://github.com/carp-lang/Carp It's a shame they did not opt to follow Clojure syntax more closely, or it would make the transition much easier for the growing Clojure community. Clojure seems to be winning the Lisp language wars. Rust could have be so much more if it used S-expressions or M-expressions. The macro language is an abomination compared to Lisp, but I understand they had to lure the embedded C crowd.
Racket 与 Rust 同样是很好的搭配，交互性强且可通过 C ABI 调用 Rust。
我还发现 Racket 和 Rust 的搭配非常好，风格类似于写 Python、在需要速度时用翻译后的 C 代码扩展。优势是两者都支持函数式风格，而 Racket 比 Python 快得多。Racket 几乎和 Clojure 一样高度交互（虽不完全，它有编译期与运行期的概念分离），还能轻松调用 C ABI，Rust 正好提供这个。两者都适合写返回不可变结果的纯函数，风格很搭；跨语言调用比 Python/C 稍慢，但能带来不错的加速。Racket 的 places 支持近乎独立内存映像的并行，还有绿色线程，并且自带 GUI 工具包和图像数据类型等“电池”。
jnxx查看英文原文
What I also found is that Racket is a very good match to Rust, in a similar style as writing Python and extending it with translated C code where speed is needed. The advantage is that both languages allow for a functional style and Racket is much faster than Python. Racket is, almost like Clojure, highly interactive (though not completely so, it has a conceptual separation of compile time and run time), and on top of that, it can call easily into a C ABI, which Rust provides. Both languages (Rust and Racket) are well-suited for writing pure functions returning immutable results which allows for a nice match in style. Calling across the language boundary is a bit slower than in the Python/C case but it can achieve a decent speed-up. Racket's places allow for parallel execution with almost separate memory images, and it also has green threads. And Racket has batteries such as a GUI toolkit and image data types included which is really nice.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选