| Techblog | https://utcc.utoronto.ca/~cks/space/blog/ |
| Github | https://github.com/siebenmann |
| Flickr | https://www.flickr.com/photos/22276923@N06/ |
Now I'm wondering if the Rust ecosystem has a solution for pre-compiled, serialized regular expressions. Well, a high quality, well regarded one; the Rust ecosystem has a lot of things in general.
It's a niche need so I suspect not, honestly.
Current status: wondering if there is a Go package that will build a serializable fast data structure for matching strings and regular expressions. You can pre-compile things in memory, but I don't think anything really supports serializing compiled REs to disk and then restoring them so you don't have to parse a giant pile of regexp text every time on startup.
Actually maybe regexp.syntax.Prog is serializable, since it doesn't seem to contain pointers or other troublesome things?
from my link log —
Practical antiforgery in software design.
https://hudlow.org/2026/practical-antiforgery
saved 2026-04-17 https://dotat.at/:/BD4M4.html
In general I continue to feel that 'software supply chain security', the EU CRA, and so on are all going to fail in practice, because the only way I see for them to succeed is for corporations to use a whole lot less FOSS and I don't think that's happening.
(Well, not unless corporations mass-rewrite their FOSS dependencies via LLM laundering but, you know, good luck with that actually running reliably in production and products.)
Overall results are for my "hello world" test:
static C < static Rust < dynamically linked C < dynamically linked Rust < (static) Go
Dynamic linking is the default for C and Rust, static linking is the default for Go on Linux and FreeBSD if you don't do anything that forces Go to dynamically link. The default Rust vs Go cases are basically neck and neck on FreeBSD, but static Rust beats (static) Go even on FreeBSD.
A follow-up surprise is that hyperfine says that the same "hello world" programs in Rust and Go do have clearly different runtimes under Linux (my initial testing was on FreeBSD, the machine I care about for this case¹). Color me surprised. A C program is faster, and a statically linked C program is fastest.
Today's vague surprise: the hyperfine timing tool can't detect a runtime difference between a 'hello world' program in Rust and Go. I would have guessed that Go's much heavier-weight runtime would have a detectable startup cost, especially since I'm printing something and that invokes various additional machinery, but hyperfine says it's in the noise in the microseconds.
(Hyperfine has absolutely no problem detecting Python's startup overhead, a Python hello world program is much slower.)
Switching servers is always a good time to update my intro. I’m a (recently) retired systems engineer who spent most of my career in the IT field. I live in the Greater Toronto Area (GTA).
As a engineer I am still interested in technology and its relationship with people and society. (And yes I think that LLMs suck). Environmental causes are close to my heart. (1/2)
Tony Finch
Jeff Hammond 🇨🇦