九年来，我一贯用Hakyll作为静态站点的天生工具。再往前追溯，我紧张用的是 Jekyll，动态页面大概是用 Perl 加 Mojolicious 和 PHP 加 Kohana 来实现。但我对这些只有模糊的印象，当时还没有 git，以是很多开拓痕迹都找不到了。
如今，我终于下定决心，打算转向自己用Rust亲手编写的自定义站点天生器。通过此番重写，我紧张是想办理以下三个问题：
第一，越来越慢的速率。在我的低配条记本电脑上，完全站点的重修大概要 75 秒（不涉及编译，纯挚只是站点天生）。我这博客上一共只有 240 篇帖子，以是该当不至于这么慢才对。虽然已经配备了不错的缓存系统，并且只在编辑期间对帖子变更实行更新的 watch 命令，但全体实行速率还是太慢了。
第二，外部依赖项。虽然站点天生器本身是用 Haskell 编写的，但除了浩瀚 Haskell 库之外，个中还包含其他依赖项。我的博客助手脚本是用 Perl 编写的，我利用 sassc 进行 sass 转换，还利用 Python 的 pygments 实现语法高亮，并利用 s3cmd 将天生的站点上传至 S3。管理和更新这么多依赖项真的很烦人，我想摆脱麻烦，专心回归到博客内容上来。
第三，设置问题。跟大量依赖项干系，我的博客网站有时候会宕机，必须得花韶光调试和修复。有时候我脑筋里刚有点灵感，系统就崩溃了，必须赶紧把网站天生器换掉。
有些朋友可能会问，这么大略的网站还有什么可崩溃的？紧张还是更新的锅，每每会以意想不到的办法引发问题。例如：
在更新 GHC 之后，它无法找到 cabal 包。在运行 Haskell 二进制文件时，系统提示：
[ERROR] Prelude.read: no parse（只涌如今台式机上，在我的低配条记本上倒是运行良好。）
或者因此下 Perl 缺点：
Magic.c: loadable library and perl binaries are mismatched (got handshake key 0xcd00080, needed 0xeb00080)（只涌如今条记本上，在台式机上运行良好。）
当 Hakyll 的不同版本间发生 Pandoc 参数变更时，就会毁坏 Atom 提要中的代码渲染效果。我知道这些并不是太大的问题，可我只希望轻轻松松写个博文，以是能正常运行才是头号目标。Haskell 引发了我的精神内耗实在我还挺喜好 Haskell 的，特殊是它纯函数的部分。其余，我也很喜好 Hakyll 对站点配置利用的声明性方法。以天生静态（即独立页面）为例：
match "static/.markdown" $ do route staticRoute compile $ pandocCompiler streams >>= loadAndApplyTemplate "templates/static.html" siteCtx >>= loadAndApplyTemplate "templates/site.html" siteCtx >>= deIndexUrls
复制代码
就算看不懂 $ 和 >>=分别代表什么，仍旧能看出我们是在从 static/ 文件夹中查找文件，再把这些文件发送至 pandocCompiler （以转换原始的 markdown 格式）、再发送至模板，之后取消索引 urls（以避免链接以 index.html 结尾）。
多么大略，多么明了！
但我已经很多年没用过 Haskell 了，以是每当须要在网站上添加轻微繁芜点的功能，都须要耗费巨大的精力。
例如，我想在帖子中添加下一篇/上一篇的链接，却难以轻松实现。末了，我不得不拿出韶光重新学习了 Haskell 和 Hakyll。纵然如此，我琢磨出的办理方案也非常慢，是依赖线性搜索来查找下一篇/上一篇帖子。直到现在，我也不知道要怎么以精确的设置办法通过 Hakyll 实现这个功能。
相信各位大牛肯定有好办法，但对我来说这么一项小功能耗费的精神也太多了，其实受不了。
为什么选择 Rust？我喜好用 Rust，偏好基本足以决定这类业余项目的实现方法。Rust 的性能很强，文本转换该当也正是它所善于的任务。Cargo 让人非常省心。在安装了 Rust 之后，就可以实行 cargo build 并等待运行结果。为什么要重新发明轮子？由于我想发挥主不雅观能动性，试试自己能编写出若何的静态站点天生器。这事该当不是特殊难，我能借助它完备掌握自己的博客网站，享受远超现成天生器的功能灵巧性。当然，我也知道 cobalt 这类工具能合营任意措辞对页面进行灵巧的类型转换。我只是想在灵巧之余，享受一下办理问题的乐趣。关于履行的细节，因受篇幅所限，我没办法在文章中完全回顾全体构建过程。感兴趣的朋友可以点击此处（https://github.com/treeman/jonashietala）查看项目源代码。
将“硬骨头”各个击破起初，我很担心没法重现自己熟习的各种 Hakyll 功能，例如模板引擎、多种措辞的语法高亮显示，或者自动重新天生编辑的页面并充当文件做事器的 watch 命令，有了它我才能边写作边在浏览器中查看帖子。
但事实证明，每块“硬骨头”都有对应的空想的工具。下面来看我利用的几个效果拔群的库：
利用 tera 作为模板引擎。它比 Hakyll 更强大，由于它能实行循环等繁芜操作：
<div class="post-footer"> <nav class="tag-links"> Posted in {% for tag in tags %}{% if loop.index0 > 0 %}, {% endif %}<a href="{{ tag.href }}">{{ tag.name }}</a>{% endfor %}. </nav></div>
复制代码
利用 pulldown-cmark 来解析 Markdown。对付 Markdown 的标准语法规范 CommonMark，pulldown-cmark 的表现真的很棒。虽然速率更快，但它的支持范围不像 Pandoc 那么广泛，以是我还得合营其他功能进行支持性扩展。这个问题稍后再谈。用 syntect 实现语法高亮，能够支持 Sublime Text 语法。用 yaml-front-matter 解析帖子中的元数据。用 grass 作为纯 Rust 中的 Sass 编译器。用 axum 创建卖力在本地托管站点的静态文件做事器。用 hotwatch 监控文件变更，这样就能在文件内容变革时更新页面。用 scraper 解析天生的 html。我的某些测试和特定转换中须要用到。用 rust-s3 将天生的站点上传至 S3 存储端。纵然有了这些库，我的 Rust 源文件本身还是超过了 6000 行。必须承认，Rust 代码可能有点冗长，再加上我自己的水平也不高，但这个项目的编写事情量还是比预期要多不少。（但彷佛软件项目都是这样……）Markdown 转换
虽然在帖子里只利用标准 markdown 能免去这一步，但多年以来我的帖子已经涉及大量 pulldown-cmark 无法支持的功能和扩展，以是只能亲手编码来办理。
预处理我设置了一个预处理步骤，用以创建包含多个图像的图形。这是个通用的处理步骤，详细形式如下：
::: <type><content>:::
复制代码
我将它用于不同类型的图像凑集，例如 Flex, Figure 以及 Gallery。下面来看示例：
::: Flex/images/img1.png/images/img2.png/images/img3.png Figcaption goes here:::
复制代码
它会被转换为：
<figure class="flex-33"><img src="/images/img1.png" /><img src="/images/img2.png" /><img src="/images/img3.png" /><figcaption>Figcaption goes here</figcaption></figure>
复制代码
这是怎么实现的？当然是用正则表达式啦！
use lazy_static::lazy_static;use regex::{Captures, Regex};use std::borrow::Cow; lazy_static! { static ref BLOCK: Regex = Regex::new( r#"(?xsm) ^ # Opening ::: :{3} \s+ # Parsing id type (?P<id>\w+) \s $ # Content inside (?P<content>.+?) # Ending ::: ^:::$ "# ) .unwrap();} pub fn parse_fenced_blocks(s: &str) -> Cow<str> { BLOCK.replace_all(s, |caps: &Captures| -> String { parse_block( caps.name("id").unwrap().as_str(), caps.name("content").unwrap().as_str(), ) })} fn parse_block(id: &str, content: &str) -> String { ...}
复制代码
（图像和图形解析部分太长了，以是咱们直接跳过好了。）
扩展 pulldown-cmark我还用自己的转换扩展了 pulldown-cmark：
// Issue a warning during the build process if any markdown link is broken.let transformed = Parser::new_with_broken_link_callback(s, Options::all(), Some(&mut cb));// Demote headers (eg h1 -> h2), give them an "id" and an "a" tag.let transformed = TransformHeaders::new(transformed);// Convert standalone images to figures.let transformed = AutoFigures::new(transformed);// Embed raw youtube links using iframes.let transformed = EmbedYoutube::new(transformed);// Syntax highlighting.let transformed = CodeBlockSyntaxHighlight::new(transformed);let transformed = InlineCodeSyntaxHighlight::new(transformed);// Parse `{ :attr }` attributes for blockquotes, to generate asides for instance.let transformed = QuoteAttrs::new(transformed);// parse `{ .class }` attributes for tables, to allow styling for tables.let transformed = TableAttrs::new(transformed);
复制代码
我以前也做过标题降级和嵌入裸 YouTube 链接之类的考试测验，实现起来相称大略。不过现在想想，在预处理或后处理步骤中嵌入 YouTube 链接可能会更好。
Pandoc 能够支持向任意元素添加属性和类，这可太实用了。以是下面这部分：
{ height=100 }
复制代码
可以转换成这个样子：
<figure> <img src="/images/img1.png" height="100"></figure>
复制代码
这项功能随处都有用到，以是我决定在 Rust 中重新实现，只是这次要用一种不那么笼统和老套的办法。
我在 Pandoc 中用到的另一项冲突功能，便是评估 html 标签内的 markdown。现在的呈现效果有问题：
<aside>My [link][link_ref]</aside>
复制代码
我起初是打算在通用预处理步骤中实现这项功能的，但后来我总会忘却引用链接。因此在以下示例中：
::: AsideMy [link][link_ref]::: [link_ref]: /some/path
复制代码
link 就不再被转化为链接了，所有解析都只在:::内完成。
> Some text{ :notice }
复制代码
这样会调用一个关照解析器，它会在以上示例中创建一个 <aside>标签（而非 <blockquote> 标签），同时保留已解析的 markdown。
虽然现有 crate 会利用 syntect 添加代码高亮，但我还是自己编写了一个功能，把它打包在<code>标签中以支持内联代码高亮。例如，“Inside row: let x = 2;”会显示为：
Inside row: `let x = 2;`rust
复制代码
性能提升我没花太多韶光来优化性能，但还是创造了两个性能要点。
首先，如果利用 syntect 并包含自定义语法，那就该当把 SyntaxSet 压缩为二进制格式。
另一点便是利用 rayon 实现并行化渲染。所谓渲染，便是指 markdown 解析、运用模板和创建输出文件的过程。Rayon 的强大之处，在于它在实行这项任务时的效率只受限于 CPU 性能，而且易用性非常好（只要代码构造精确）。下面是渲染的简化示例：
fn render(&self) -> Result<()> { let mut items = Vec::new(); // Add posts, archives, and all other files that should be generated here. for post in &self.content.posts { items.push(post.as_ref()); } // Render all items. items .iter() .try_for_each(|item| self.render_item(item))}
复制代码
要实现并行化，我们只须要将 iter() 变动为 par_iter()：
use rayon::iter::{IntoParallelRefIterator, ParallelIterator}; items .par_iter() // This line .try_for_each(|item| self.render_item(item))
复制代码
这就成了，非常大略！
我也承认，这里的性能提升非常有限，真正的性能改进紧张还是来自我利用的库。例如，我的旧站点利用由 Python 编写的外部 pygments 进程来实现语法高亮，而现在的替代方案是 Rust 编写的高亮器。后者不仅速率快得多，而且并行化难度也更低。
健全性检讨掩护自己的网站，我才创造原来开拓项目这么随意马虎出错。比如一不留神就链接到了不存在的页面或图像，或者没有利用[my link][todo]来定义链接引用，而且在发布前还总是忘却更新。
以是，除了测试 watch 命令等基本功能之外，我还解析了全体站点，并检讨所有内部链接是否存在且精确（也会验证/blog/my-post#some-title 中的 some-title 部分）。外部链接也是要检讨的，但我在这里利用的是手动命令。
在文章的开头，我列出了自己之前的一些设置问题。下面咱们就看看详细办理得怎么样。在天生过程中，我也采纳了比较严苛的检讨标准，尽可能避免遗漏各种稀奇古怪的缺点。
效果如何？在文章的开头，我列出了之前设置中的一些问题。下面咱们就一起来看详细办理得怎么样。
性能方面现在，还是那台低配条记本电脑，完全的站点重修（不包含编译韶光）只须要 4 秒。性能一下子提升了 18 倍，这个成绩算是相称不错了。当然，这里面肯定还有进步空间——比如，我利用 rayon 处理文件 IO，如果采纳异步机制肯定还能再优化一些；而且我也没有利用缓存系统，以是每次构建时都得重新天生所有文件（但通过不雅观察，我创造构建过程还挺智能的）。
请把稳，我不是说 Rust 就一定比 Haskell 更快，这里比较的只是两种详细实现。相信肯定有高手能在 Haskell 中实现同样的速率提升。
单一依赖现在我的所有功能都在 Rust 中实现，不须要安装和掩护任何外部脚本/工具。Cargo 不添麻烦只要在系统里用上 Rust，cargo build 就永久服帖服帖、不添麻烦。我以为这可能便是低调的 Rust 最突出的上风之一——build 系统不给人找事。
大家用不动手动查找丢失的依赖项，捐躯某些子功能来实现跨平台，或者在构建系统自动拉取更新时造成毁坏。往椅子里一躺，等着代码编译完造诣行。
Rust 治好了我的精神内耗虽然我创造在 Rust 当中，创建系列文章或者上一篇/下一篇链接之类的功能确实更轻松，但我并不是想说 Rust 就比 Haskell 更大略易用。我的意思是，Rust 对我个人来说比 Haskell 更随意马虎理解。
而个中最大的差异，很可能在于实践履历。我最近一贯在用 Rust，而从小十年前利用 Haskell 完成网站创建以来，我就险些没跟 Haskell 打过什么交道。以是如果我也十年不打仗 Rust，那再次利用起来肯定也是痛楚万分。
总体来说，我对自己的这次考试测验非常满意。这是个好玩又有益的项目，虽然事情量超出了我的预期，但也确实肃清了长期困扰我的老大难问题。希望我的经历对各位有所帮助。
原文链接：
https://www.jonashietala.se/blog/2022/08/29/rewriting_my_blog_in_rust_for_fun_and_profit/
