2022-06-17.01
Discover more from hrbrmstr's Daily Drop
mold
mold is "a faster drop-in replacement for existing Unix linkers. It is several times faster than the LLVM lld linker, the second-fastest open-source linker which I originally created a few years ago. mold is designed to increase developer productivity by reducing build time, especially in rapid debug-edit-rebuild cycles."
I'm willing to bet that a fair chunk of readers live in interpreter land for most of the time they need to perform computing tasks. If that's true, then you've got to be asking yourselves "why is hrbrmstr telling us about a new linker?". Because it's cool!
Sure, we have GNU's ld and LLVM's lld, and all the tools we rely on compile and link fine now, so what's the big deal?
This is the big deal:
We really shouldn't assume that we have access to maxed out Mac Studios (like GreyNoise was kind enough to provide) so we can burn through Makefiles at warp speed. Having talented folks work on optimizing something as foundational as linking compiled program bits together is crucial to making the most of what we currently have and for advancing our tradecraft.
This is why Rui Ueyama, mold's creator, created a new linker:
Even though lld has significantly improved the situation, linking is still one of the slowest steps in a build. It is especially annoying when I changed one line of code and had to wait for a few seconds or even more for a linker to complete. It should be instantaneous. There's a need for a faster linker.
The number of cores on a PC has increased a lot lately, and this trend is expected to continue. However, the existing linkers can't take the advantage of the trend because they don't scale well for more cores. I have a 64-core/128-thread machine, so my goal is to create a linker that uses the CPU nicely. mold should be much faster than other linkers on 4 or 8-core machines too, though.
It looks to me that the designs of the existing linkers are somewhat too similar, and I believe there are a lot of drastically different designs that haven't been explored yet. Developers generally don't care about linkers as long as they work correctly, and they don't even think about creating a new one. So there may be lots of low hanging fruits there in this area.
I highly encourage folks to carve out some weekend reading time to dive into the design and implementation of mold. Hopefully it will be as inspiring to you as it was to me.
wails
Since I was mean to Electron and snarky to Tauri yesterday, I should round out the week by giving some tough love to Wails [GH], especially since it's about to turn v2.
Wails aims to make it easy for Go programmers to create lightweight desktop applications or add a front-end to their existing applications. The toolchain lets you bundle an HTML/JS/CSS front-end elements in an applications, without resorting to creating a server and opening a browser to view it.
Honestly, its hard to beat on Wails too much given that Xbar is written in it and it sure feels like a native macOS app (to me). Part of the reason for this is that Wails uses a purpose built library for handling native elements such as Window, Menus, Dialogs, etc.
Like Tauri, Wails does not embed a browser engine, so it truly is much lighter weight than nasty, brutish, and fat Electron apps.
This is the Wails team describing the the underbelly of Wails apps:
A Wails application is a standard Go application, with a webkit frontend. The Go part of the application consists of the application code and a runtime library that provides a number of useful operations, like controlling the application window. The frontend is a webkit window that will display the frontend assets. Also available to the frontend is a Javascript version of the runtime library. Finally, it is possible to bind Go methods to the frontend, and these will appear as Javascript methods that can be called, just as if they were local Javascript methods.
Their guide is great, and if you're already a Go aficionado, this may be your gateway drug to building robust, native-feeling desktop apps.
Oblivious HTTP
In a previous edition I noted my 💙 for some recent IETF HTTP RFC focus. We'll round out today's edition with a look at the "Oblivious HTTP Application Intermediation" RFC proposal.
The RFC's abstract says that the RFC's intent is to "[describe] a system for the forwarding of encrypted HTTP messages. This allows a client to make multiple requests of a server without the server being able to link those requests to the client or to identify the requests as having come from the same client.".
You provide tons of information to web servers when you make web requests, and at some point it's trivial to correlate your actions associated with IP addresses you use. Some of this has been made worse by the "encrypt everything" do-gooders (who seem to care more about being right than causing harm in other ways), since HTTPS sessions last a while, and tearing them and firing up new ones adds non-trivial overhead (honestly, I think the "encrypt everything" folks have also made global warming worse as well).
Proxies and onion routing help with privacy, but the performance can be terrible, even in the best of setups.
Oblivious HTTP aims to solve these problems through a method of encapsulation for binary HTTP messages using Hybrid Public Key Encryption (HPKE). This combination is designed to protect the content of both requests and responses, enabling a deployment architecture that can separate the identity of a requester from the request.
This solution requires servers and proxies to work together and explicitly support it. It has real performance gains over a single HTTP session per-request. If you dig into the details, you'll see that web requests will be difficult to be uniquely attributed to you or linked with other requests, even if you don't fully trust your intermediary.
It's a great RFC, a neat proposal for increased privacy, and a solid read for a lazy Sunday afternoon.
FIN
Have a great weekend, and here's wising all daD's a Happy daD's Day! ☮