Clojure Reload
我使用 Clojure 三年了,作为脚本、后端服务以及界面描述语言,我用它构建了很多软件 —— 自底向上的,这些项目合起来的生产代码行数有 ~100 KLoc 之多。
每当闲时,总是试图为 Clojure 写点什么,但总是提笔又放下,次次搁置。它的乐趣,似在不言中:跨过函数式高山和 LISP 66 年的历史长河,穿越过标准库丛林和 Java 生态沼泽,这里的一切都是那么的不一样,哪怕是写了半辈子的非 LISP 系程序员,这里几乎没有任何的经验可以遵从,一切从头来。Clojure 的 Reddit 社区总为了吸纳新人而喋喋不休,但讨论来讨论去,最终的结论却是:这是一门注定小众的语言,第一次没有在它面前停留的人,或许永远不会体会到它的乐趣,而这乐趣又是无法言说的,因而错过便就永远错过了。
如果说上面的说法过于虚无缥缈,那么下面我将从实际的例子来 Clojure 的乐趣之一:开发体验。很多语言以软件工程和开发体验优先,而不更多的强调架构和学术性(比如 Java 和 Scala),这些语言往往受到开发者的欢迎,典型的比如 Rust 的生命周期、宏、异常处理、模式匹配和基于特质的现代面向对象系统,Kotlin 的协程、标准库、为 GUI 而生的语法糖以及扩展函数,Swift 令人洁癖的语法编译规则,为 SwiftUI 服务的包装器、宏系统、Actor 和 async/await 异步模型,甚至更极端的,Dart,一个专门为 Flutter 优化和进化的语言:可空类型、类构造器以及垃圾回收机制,以及 Flutter 自身毫秒级别的 WidgetTree 热更新。
Clojure 在其中独树一帜,其开发体验的根本在于 基于 S 表达式的函数式编程风格
。
几乎所有的解释型动态语言都有 REPL(Kotlin、Scala 等编译型语言也有,因为其本质可以通过 JVM 字节码解释运行),所谓 REPL,指的是 Read-Eval-Print Loop, 简单来说就是: 启动一个解释器,读取用户输入的表达式或语句,执行并打印出结果。这种机制可以很好的试验小片段代码,并观察其运行结果。REPL 并不罕见,浏览器控制台就是一个 JavaScript REPL,而 iPython 以及 Jupiter Notebook 则是 Python 的 REPL。
但尽管如此,REPL 的作用还是被大大低估了。曾经我在浏览器控制台上编写 JavaScript 代码时,一个前端同事还很惊讶的问我,为什么要在这里写程序?我觉得对于很多前端开发者,REPL 的使用频率可能如同这个小规模不严谨的观察所显示的那样,非常低。对于后端程序员而言,且不说 Scala 和 Kotlin,很多 Java 开发者甚至不清楚 JDK 中内置了一个叫做 JShell 的 REPL,在 IJ 中能够交互执行 Java 代码。
为什么?答案很简单,不流行的原因无外乎两点:门槛太高、收益太低
。实际上手就能发现,Web 控制台中的 REPL 并不好用,尽管它已经代表了当前网页运行 V8 虚拟机,能够调用已经初始化的类库和接口,但假如我们想要试验一个新的日期库,这里不能直接用 ESM 标准导入模块,而仅仅支持 eval 执行字符串形式的 JavaScript 代码,这显然和大部分基于模块的工程化开发工作流不符合。JShell 的低采纳也是同样的原因。即便是当前环境已经有了所有加载好的 API 接口,在 REPL 执行代码的功用也少得可怜:我们想要执行的代码往往是非结构化,且带有上下文的多行指令,要单独将其拎出来运行所要付出的努力很大,状态如何构造?上下文如何创建?有这功夫还不如写一个单元测试来的方便。对于前端而言,则是直接将结果打印在 Web 页面上来测试代码更简单。
Clojure 的 REPL 体验则完全是另外一番景象,甚至可以说,Clojure 开发体验的核心在于 REPL。有大量的库,比如 nREPL 等,支持通过 Socket 远程连接到运行着 Clojure 的 JVM,动态执行代码,类似于一个 Java 世界中更加全能的 Arthas。这是靠什么做到的呢?答案是 Clojure 语言本身:一种 LISP,因为 LISP 基于 S 表达式,所以在 REPL 中执行代码块非常方便,由于大部分 Clojure 代码都是函数式风格的,因此函数基本就是对于状态的映射 —— 返回另外一个状态,因此执行起来非常方便,至于上下文,启动的 JVM 本身已经提供。就实际而言,在 VSCode 中处理 Clojure 工程的典型方式是:启动一个 nREPL,将代码和其依赖全部加载到这个 JVM 虚拟机,之后在任意页面,在任意光标位置,点按多次 Ctrl + W
选中当前需要执行的 S 表达式,Alt + Enter
执行并得到结果,如果想要将整个文件加载并解释,只需要一次快捷键即可。
使用过 Rust 的开发者往往会不由自主的写测试,因为写单元测试太方便了,只需要在编写好的函数周围添加另一个函数,为其添加 #[test]
宏,即可运行测试代码,而对于 Clojure 而言,单元测试也常常位于源代码文件中,以 (comment )
的形式暴露,解释器不执行这个 S 表达式,但需要运行时,光标选中并直接发送到 REPL 执行即可,相比较测试需要每次启动,发送给 REPL 的代码总是执行在运行中的 JVM 虚拟机中,速度极快且状态得以保留,其方便程度相比 Jupyter Notebook 有过之而不及。
REPL 只是 Clojure 乐趣的表象,如果使用过 Clojure Web 框架或 ClojureScript Web 项目,你一定会惊叹于代码热更新的能力,远远超出 REPL 的地步:前/后端代码编辑后保存,界面/接口立刻所见即所得,哪怕项目再大也是如此。这是因为重载真正的核心,在于语言内建的 动态加载 机制。
Clojure 运行时的动态加载机制主要由如下三点构成:#’
读入宏、defonce
定义以及 (require ns-sym :reload)
重新加载命名空间接口。简单来说,Clojure 中的变量和函数基于命名空间区分,每个命名空间对应一个 Clojure 文件,这些变量和函数作为运行时中的 Var 对象,被 Namespace 对象管理。在 Clojure 中传递通过 defn
创建的函数(或其他匿名函数),本质上是传递函数的 Var 对象引用,而传递由 def
绑定的变量,则本质是对 Var 对象解引用得到值复制。读入宏 #'
的本质,就是获取一个绑定变量的 Var 引用,而 defonce
区别于 def
和 defn
在于其保证只被初始化一次,在重新加载时不变。这两个设计是为了重载命名空间服务的,当通过 (require ns-sym :reload)
重新载入命名空间时,Clojure 会重新执行命名空间中的所有代码,由于 defonce
保证其只被初始化一次,且 #'
读入宏则保证其返回的引用始终是同一个 Var 对象。你能想象到这多有用吗?defonce
通常用于存放状态,读入宏读入的变量则用于保证当此变量的值重新求值而变化时,对其引用始终能够得到最新的值(区别于很多语言中的 getter,读取 getter 每次都会重新计算它)。实现这一切的方式并不难,读入宏本质就是一个间接指针而已,Clojure 以运行时轻微的代价实现了代码热加载,同时保留状态和引用变化代码值的能力。
考虑一下 Web 后端开发,对于 Node.js 而言,通常是通过本地文件变更监听重启进程的方式实现“代码热加载”,对于大型项目而言,它非常慢。Rust 也是如此,当本地文件变更,通过 cargo watch 重新编译并运行,尽管编译是增量的 DEBUG 包,但对于大型项目,这一过程仍旧十分痛苦。而 Clojure 采用了什么方式呢?以 Luminus 框架为例,通过 REPL 启动了 Web 和 REPL 服务器后,开发模式下,中间件会在每次请求时检查源代码文件夹中文件是否变化,如果变化则读取其命名空间定义,构建依赖树,并对所有需要重新加载的命名空间进行重新加载(借助于 ns-loader 和 ring-reload 库,核心代码如下所示)。
(ns ring.middleware.reload
"Middleware that reloads modified namespaces on each request.
This middleware should be limited to use in development environments."
(:require [ns-tracker.core :refer [ns-tracker]]))
(defn- reloader [dirs retry?]
(let [modified-namespaces (ns-tracker dirs)
load-queue (java.util.concurrent.LinkedBlockingDeque.)]
(fn []
(locking load-queue
(doseq [ns-sym (reverse (modified-namespaces))]
(.push load-queue ns-sym))
(loop []
(when-let [ns-sym (.peek load-queue)]
(if retry?
(do (require ns-sym :reload) (.remove load-queue))
(do (.remove load-queue) (require ns-sym :reload)))
(recur)))))))
(defn wrap-reload
([handler]
(wrap-reload handler {}))
([handler options]
(let [reload! (reloader (:dirs options ["src"])
(:reload-compile-errors? options true))]
(fn
([request]
(reload!)
(handler request))
([request respond raise]
(reload!)
(handler request respond raise))))))
对于实际业务而言,需要热更新的往往是业务代码,其通过路由访问控制器方法,如下所示的路由,其通过 #'
读入宏提供,每次 Http 请求都会 deref 这个 Var 引用并访问路由表,从而找到控制器方法并执行实际业务逻辑,当文件变更,wrap-reload 会在新请求发送时将修改的文件和命名空间重新加载,这里的 app-routes 路由表也会更新,而并未停机的 Http 服务器则只需要数 ms 的时间即可访问到更改后的代码。
(mount/defstate app-routes
:start
(ring/ring-handler
(ring/router
["/api"
{:coercion spec-coercion/coercion
:middleware [auth/wrap-basic-auth
middleware/wrap-reload
middleware/wrap-as-async]}
["" {:no-doc true
:swagger {:info {:title "goods-api"
:description "https://mazhangjing.com"}}}
["/swagger.json"
{:get (swagger/create-swagger-handler)}]
["/api-docs/*"
{:get (swagger-ui/create-swagger-ui-handler
{:url "/api/swagger.json"
:config {:validator-url nil}})}]]])))
(defn app []
(middleware/wrap-base #'app-routes))
利用语言动态加载机制的 Web 框架,配合上 REPL,Clojure Web 后端的开发体验非常棒。大部分时候,开发者线上部署的时候,会留一个 nREPL 的端口,当需要定位 Bug 时直接连接到生产 JVM 虚拟机重载函数,添加日志打印,定位问题。当需要修复时,再次重载新的函数即可,而无需重启 JVM 虚拟机。当有新的功能整合,在不需要引入额外 jar 包依赖的情况下,编写的服务端代码直接 git pull
拉取并自动或手动重载即可注入字节码,Http 服务器在没有重启的情况下即可实现代码更新。这两者的结合真正体现了 Clojure 动态开发的能力,它完美契合项目的迭代进化,在我的经验中,上线项目往往在数月的时间里,进行大量的 Bug 修复和新功能合入,而服务却永不停机,始终在线。
对于 ClojureScript 的 Web 前端领域,社区在现有的 React.js 生态上结合 Clojure REPL 和动态加载机制实现了创新:如果更简单的 React 应用,使用 reagent
的 atom
管理自己创建的状态,只需要通过 defonce
声明就能确保重载时不变化。对于大型项目,re-frame
提供了中心化的状态管理,类似于 Redux
,其开发环境中的代码热更新机制和上面讲到的 Luminus 后端类似,这个中心化的状态本质是通过 defonce 创建并定义的,因此在重载代码时也不会状态丢失。下面的例子展示了一个 shadow-cljs 项目,开发环境重载后重新渲染了 React 组件树,注意 page 这个 Component Root 也是通过读入宏加载的,以便界面 UI 命名空间重新加载时,这里能够获取到最新数据。这里的 after-load
会告知 shadow-cljs,在每次有 reload 时都执行这里的代码,总和起来,这种设计使得状态不变的情况下,界面能够发生变化反映代码的更改。
(defonce ^:private state
(r/atom {:show-recent false
:show-change false
:change-url nil
:show-settings false
:show-ban false
:ban-url nil}))
(defn ^:dev/after-load mount-components []
(rf/clear-subscription-cache!)
(rdom/render [#'page] (.getElementById js/document "app")))
当然,这一切的设计本质是权衡和运行时性能损耗为代价的。正如同业界广为流传的一句话:每增加一层抽象,代码所反映的抽象和开发效率提升一个数量级,而运行效率则损失一个数量级。但我们欣喜地看到,得益于系统研发人员的努力,JVM 虚拟机通过 Hotspot 技术极大的降低了层级的性能损耗,以至于 Clojure 代码的运行性能和 Java 代码相差无几,而经过 JIT 编译的 Java 代码性能也非常出色。
尽管如此,差距依旧存在,在我实验的一个读取双 SQLite 数据库,一个做鉴权,一个做数据查询的例子中,基于 Actix 的 Rust 二进制 8MB,异步运行时单线程基线内存为 3MB,相比较之下,Luminus 框架的 Jar 包 40MB,加上 JRE 400MB,默认 Java 堆配置的基线占用内存为 300MB,至于运行速度,Clojure 大概能在 10ms 完成 SQL 查询并返回结果,而 Rust 只需要 6ms 左右。当然,这不是一个严谨的测试,Rust 手动内存管理和 0 拷贝的所有权数据的确提升了运行时性能,并带来了内存占用的亮眼表现,但 Clojure 也已经足够的好,毕竟,我在 30 分钟内实现了 Luminus 框架的自定义鉴权和数据读取,而 Rust 则用了 4 个小时。
虽然 Rust Web 后端目前体验已经很成熟,基于泛型的数据转换、提取、依赖注入非常方便,一点也不逊色于 Java 生态的 Sping Boot,但这本质上,只是一种风格偏好和抉择,每种语言都是图灵等价的实现,但一些确实比另一些更有乐趣,或者说拥有更高的开发生产力。
Clojure 官方给出的 Clojure 特性包含如下六点:
- 动态开发
- 函数式编程风格
- LISP
- 运行时多态
- 并发编程
- JVM 生态
本文主要介绍了前三点,它们是 Clojure 乐趣的核心体现。至于运行时多态、CSP、Actor 和 Futures 等并发编程模式以及不可变数据结构的内建支持,以及 JVM 丰富的生态,则是 Clojure 优势的另一面 —— 工程能力,毕竟真正的效率不仅在于自己写的有多好,还在于能够使用的工具和库有多少。
退一步讲,如果 Java 衰落了,Clojure 还会好吗?当然。由于 LISP 解释器实现起来太过于简单,实际上,有很多严肃和生产级别的 Clojure 运行时,比如基于 .Net 的 ClojureCLR, 基于 GraalVM SVM 的 babashka, 基于 Google Closure 编译到 JavaScript 的 ClojureScript, 编译到 Dart 的 ClojureDart,编译到 C++ 的 jank, 编译到 C 的 ClojureC, 编译到 ObjectC 的 ClojureM, 编译到 Go 的 gojure 。从这个角度讲,作为编程语言和生态的 LISP 已死,但亦然,作为抽象层和低层级语言交互界面的 LISP 也实现了永生。