Hello and welcome to Linked List. I’m Wesley Moore and through this site I hope to bring you interesting posts on tech with a bit of commentary. Topics include open-source, programming, hardware, software, Linux, Rust, retro computing etc.

The site takes plenty of inspiration from John Gruber’s Daring Fireball, a site I’ve been reading for a couple of decades now. As time has gone on I’ve drifted away from the Apple ecosystem and I feel there is space for a Daring Fireball style blog covering topics outside Apple and mainstream tech news. Basically stuff that interests me—and hopefully you.

I expect the site will cover technology and software ecosystems with a slant toward open systems. If you’re a developer, technologist, Linux, BSD, UNIX user I think you’ll enjoy the site.

In addition to reading on the website you can also subscribe to the RSS feed or follow the Mastodon account, details of which are on the follow page. Thanks for stopping by.

Kirill Fedorov:

In this article I’ll discuss different strategies for incrementally adding Rust into a server written in another language, such as JavaScript, Python, Java, Go, PHP, Ruby, etc.

I think all of the strategies are good, but Tier 3 stands out as being the best bang for the buck. If you can use an off-the-shelf binding generator library then writing a native function in Rust is super easy and it can have a profound effect on performance.

This is an interesting case study to read alongside Nolan Lawson’s recent post: Why I’m skeptical of rewriting JavaScript tools in “faster” languages:

One reason for my skepticism is that I just don’t think we’ve exhausted all the possibilities of making JavaScript tools faster. Marvin Hagemeister has done an excellent job of demonstrating this, by showing how much low-hanging fruit there is in ESLint, Tailwind, etc.

In the browser world, JavaScript has proven itself to be “fast enough” for most workloads. Sure, WebAssembly exists, but I think it’s fair to say that it’s mostly used for niche, CPU-intensive tasks rather than for building a whole website. So why are JavaScript-based CLI tools rushing to throw JavaScript away?

Now I will admit the posts are talking about different applications: CLI tools vs. web servers but they both consider performance. In Kirill’s post the Rust rewrite has 4.93× the request throughput, which I think supports Nolan’s thesis. However, the Rust version does it using 13 MB of RAM compared to 1.35 GB for the node.js version!

Jan de Mooij writing on the SpiderMonkey blog:

In September, machine learning engineers at Mozilla filed a bug report indicating that Firefox was consuming excessive memory and CPU resources while running Microsoft’s ONNX Runtime (a machine learning library) compiled to WebAssembly.

The issue with the ONNX module was that the Ion compiler backend took a long time and used a lot of memory to compile it. On my Linux x64 machine, Ion-compiling this module took about 5 minutes and used more than 4 GB of memory.

⋮

With these changes, Ion can compile the ONNX Wasm module in less than 3.9 seconds on my machine, more than 75x faster than before these changes.

I find it satisfying reading about optimisations like this. The same end-state is achieved, but in vastly less time and space—it feels like magic.

Kevin Guthrie writing on the Cloudflare blog:

This small and pleasantly-readable function consumes more than 1.7% of pingora-origin’s total cpu time. To put that in perspective, the total cpu time consumed by pingora-origin is 40,000 compute-seconds per second. You can think of this as 40,000 saturated CPU cores fully dedicated to running pingora-origin. Of those 40,000, 1.7% (680) are only dedicated to evaluating clear_internal_headers. The function’s heavy usage and simplicity make it seem like a great place to start optimizing.

The scale of Cloudflare’s operation is staggering when put in terms like this.

Josh Aas writing on the Prossimo blog:

The River reverse proxy recently has come a long way since we announced the project in February.

River is a project of Prossimo, itself a project of the Internet Security Research Group (ISRG) project. ISRG are the folks behind Let’s Encrypt. The River reverse proxy is implemented in Rust.

Just about every significantly-sized deployment on the Internet makes use of reverse proxy software, and the most commonly deployed reverse proxy software is not memory safe. This means that most deployments have millions of lines of C and C++ handling incoming traffic at the edges of their networks, a risk that needs to be addressed if we are to have greater confidence in the security of the Internet.

Our own goal is to have River ready to replace Nginx and other reverse proxy software used by Let’s Encrypt within the next year, and we encourage other organizations to start considering where they might start to improve the security of their networks with memory safe proxy software.

That would constitute quite a significant production deployment for the project.