Thanks to my sponsors: Boris Dolgov, Isak Sunde Singh, Antoine Rouaze, Daniel Strittmatter, Cole Kurkowski, Dom, Tyler Schmidtke, Johan Saf, Lucille Blumire, Tyler Bloom, Geoffroy Couprie, Neil Blakey-Milner, Ben Wishovich, Chris Emery, Alan O'Donnell, Andronik, Alex Krantz, James Rhodes, Mathias Brossard, Steven McGuire and 230 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:
My ideal Rust workflow
56 min
Writing Rust is pretty neat. But you know what's even neater? Continuously testing Rust, releasing Rust, and eventually, shipping Rust to production. And for that, we want more than plug-in for a code editor.
We want... a workflow.
Why I specifically care about this
Cool bear's hot tip
This gets pretty long, so if all you want is the advice, feel free to directly.