Thanks to my sponsors: Manuel Hutter, Alex Krantz, jatescher, Lennart Oldenburg, Geoffroy Couprie, Philipp Gniewosz, Max Bruckner, Eugene Bulkin, Mark Old, Paige Ruten, Alan O'Donnell, David Souther, Paul Marques Mota, Torben Clasen, Corey Alexander, Tom Forbes, Blake Johnson, Johan Andersson, Ramen, Diego Roig and 235 more
3 min
Cut for time
👋 This page was last updated ~2 years ago. Just so you know.
This series has to end somewhere, so let's end it here!
However, here is a list of some things I'd like to come back to:
Bundling & TypeScript
Using a bundler like Parcel so I can write some of the client-side logic in TypeScript, have it take care of building the SCSS, etc.
I do that to great effect in another project of mine and I'd like to show you how I did it!
Nix, but this time for real
More nix usage. I still want to do dynamic linking — a debug build of futile
sits at >400MB right now. Stripping helps, a lot (so would compressing debug
info), and release builds are smaller, especially with opt-level = "s", this
is probably more on the C libraries I statically link against, than my Rust
code itself.
While I was finishing up this series, I wanted to look at why my executable was so large, looked at bloaty, realized I didn't feel like building it, noticed it was in nixpkgs, of course, and after a simple:
$ nix-shell -p bloaty
I could just... use it. It'll go out with the next garbage collection round. Nix is pretty neat.
More crate demos
I'd like to actually show how to use one of those fancy Rust GraphQL crates. They do really neat stuff!
Re bundling: did you know Parcel has its own Rust-powered CSS parser, transformer, bundler and minifier?
Making my life easier, still.
I still want to integrate the asset pipeline (salvage) within futile proper.
This might be doable without nix, but I consider it a prerequisite, due to the
sheer amount of dependencies.
We should improve the user experience somewhat
Improving search / login / feedback reporting / overall navigation of the site: I'm used to React and will probably reach for that (sorry, not going to wasm for that), but maybe it'd be interesting to explore some of the alternatives that "disappear at compile time" / don't use a virtual DOM?
I've tried loosely keeping track of the frontend discourse, but it's... a lot.
Another "Rust build performance" article?
Gaining back some build performance: a hot build of my website, in development, takes 5 seconds on a pretty good machine. I'd like to try some sort of "micro-service architecture" but it's just a bunch of binaries doing IPC between each other. Each target is built and linked independently, everyone's happy. I'm curious to see how that would perform!
All that and more.
Also, once I'm truly happy with the current state of things, I want to get into slightly more ambitious stuff — I've always wanted to do interactive courses, interactive anything to be honest.
A note on GitHub sponsors.
As a reminder, I've changed my goal on GitHub Sponsors to be: when there's 500
of you supporting me, I'll open source the code of futile, salvage, and
other closed-source Rust codebases I own.
Of course that'll create a maintenance burden, but we'll think about that if and when the goal is met.
In the meantime, I'd like to thank all of you for your renewed support as I'm now doing this full-time — your support counts more now than ever.
Until next time, take excellent care of yourselves!
Here's another article just for you:
Rust modules vs files
19 min
A while back, I asked on Twitter what people found confusing in Rust, and one of the top topics was "how the module system maps to files".
I remember struggling with that a lot when I first started Rust, so I'll try to explain it in a way that makes sense to me.
Important note
All that follows is written for Rust 2021 edition. I have no interest in learning (or teaching) the ins and outs of the previous version, especially because it was a lot more confusing to me.