Cut for time
Thanks to my sponsors: SeniorMars, James Brown, Enrico Zschemisch, Guy Waldman, David Barsky, Jan-Stefan Janetzky, Alex Krantz, Adam Lassek, Tanner Muro, Thehbadger, Zachary Myers, Johnathan Pagnutti, Chris Walker, L0r3m1p5um, Laine Taffin Altman, Hadrien G., Olly Swanson, Diego Roig, Matt Heise, FELIX and 254 more
👋 This page was last updated ~3 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!
Did you know I also make videos? Check them out on PeerTube and also YouTube!
Here's another article just for you:
Proc macro support in rust-analyzer for nightly rustc versions
I don’t mean to complain. Doing software engineering for a living is a situation of extreme privilege. But there’s something to be said about how alienating it can be at times.
Once, just once, I want to be able to answer someone’s “what are you working on?” question with “see that house? it wasn’t there last year. I built that”.
Instead for now, I have to answer with: “well you see… support for proc macros was broken in rust-analyzer for folks who used a nightly rustc toolchain, due to incompatibilities in the bridge (which is an unstable interface in the first place), and it’s bound to stay broken for the foreseeable future, not specifically because of technical challenges, but mostly because of human and organizational challenges, and I think I’ve found a way forward that will benefit everyone.”