Jekyll2026-04-14T03:07:57+00:00https://blog.hollandgibson.com/feed.xmlHolland’s BlogThe intersection of leadership, software engineering, and life.Consider targeting wasm32v1-none2026-04-13T00:00:00+00:002026-04-13T00:00:00+00:00https://blog.hollandgibson.com/2026/04/13/targeting-wasm32v1
Table of Contents

You are targeting the wrong kind of wasm

When building WebAssembly (wasm) projects, especially with rust, most advice is to build to wasm32-unknown-unknown. This is generally bad advice. With relatively simple changes you can use the compiler to your advantage rather than letting it lie to you.

This is part 2 of my rust-wasm journey, see part 1 here

The problem

The issue is that running something like:

cargo build --release --target wasm32-unknown-unknown

… ends up having the compiler shift many kinds of error to runtime instead of compile time.

One of the biggest benefits to using a language like rust is that you can make illegal states unrepresentable.[1] This allows you to have the compiler stop you from making errors quickly and early in the design process. So when you want to use rust to build a wasm library for the web, you shouldn’t have to give up on all the benefits of "compiler-driven-development".

This is compounded by the fact that testing dynamic libraries (wasm is by definition a dynamic library) is not straightforward at all. So you may be fairly deep into coding or design and not realize you are trying to use something that will almost never work on the web.

You will be better served by instead targeting wasm32v1-none for the web. More on how to do that later.

Small note: wasm for the web vs others

Most wasm is built for the web, and that’s what this blog post is discussing. If you are building a wasm library as a plugin, or something to run in a "web worker" type setup, then you are probably aren’t targeting the wasm32-unknown-unknown target anyway. You are probably building for the wasm32-wasip2 or similar target, and swapping to one of those targets gets you largely the same benefit of targeting wasm32v1-none.

Shooting yourself in the foot

The problem is that wasm32-unknown-unknown includes the std library, but most of the std library is unusable in a wasm context. There’s no filesystem, no I/O, no threads, etc. This is (sort of) the point: the wasm sandbox can’t get into any trouble so from a consumer perspective, they can download and run wasm code without having to worry about it installing a rootkit or malware or something.

A somewhat fair reason for this situation’s existence is because wasm32-unknown-unknown is meant to be easy, and does not only target the web.

The big things missing

std in rust contains a fair amount of things that won’t work on the web. These are:

  • I/O:

    • std::fs - there’s no filesystem

    • std::net - network calls are not permitted

  • Concurrency:

    • std::thread (or any non-std equivalent like tokio::task) - mainstream wasm is only single-threaded for now [2]

    • std::sync::Mutex (they sort of work, but not correctly)

  • Time

    • std::time::Instant - there’s no clock available and besides, even timing in JavaScript (js) has all sorts of limitations

    • SystemTime - you have to access time via js

  • Operating system

    • std::env - environment variables don’t exist in a wasm context

    • std::process - there’s no shell (like bash) available

There are others but they are not easy to discover and the wasm32-unknown-unknown target gets active maintenance anyway, but these big gaps are unlikely to change anytime soon.

Can’t you just…​ not use those calls?

Just don’t write code using any of these prohibited actions, you might think. For simple wasm libraries this is actually quite feasible. But once you start pulling in libraries, it can become very difficult to tell if a transitive dependency is going to try to do a network call or something else that won’t work before you ship your code.

Example

I have created a demonstration project that compiles but will absolutely not work on the web: https://codeberg.org/humble_proton/blog-demos/src/branch/main/targeting_wasm32v1_none/stub_example

For clarity here is a snippet of the wasm code, which compiles (and even passes unit tests):

use std::time::{SystemTime, UNIX_EPOCH};
use wasm_bindgen::prelude::wasm_bindgen;

#[wasm_bindgen]
pub fn epoch_secs() -> u64 {
    SystemTime::now()
        .duration_since(UNIX_EPOCH)
        .expect("Time went backwards!")
        .as_secs()
}

After it is loaded into a webpage, if you try to call this function you end up with an error message like: "unreachable executed" in firefox.[3]

>> wasm.epoch_secs()
Uncaught RuntimeError: unreachable executed
    epoch_secs http://[::1]:8000/target/pkg/stub_example.js:11
    <anonymous> debugger eval code:1
stub_example_bg.wasm:38494:1

This is not a fun way to be writing code!

Solutions

Option 1: Use wasm32v1-none

There is a straightforward solution: compile for the wasm32v1-none target instead. Unfortunately, straightforward does not mean simple - this is not a drop in fix if you already have a large project. The good news is that wasm32v1-none (in rust at least) still uses wasm32-unknown-unknown in the LLVM backend, so all other tools, browsers, etc still work exactly the same.[4]

The main benefit is that wasm32v1-none does not include the std library. It only includes core and alloc. Furthermore it only encompasses the W3C WebAssembly Core 1.0 spec with one W3C proposal: Mutable Global variable import & export. This means that this target is highly compatible across browsers. In short, if you can compile to this target, this wasm will run on the web!

As a bonus, you can still use any of the W3C proposals that LLVM supports like reference types, multi-value, fixed width SIMD, etc - these are just a short Cargo.toml config away.

Compiling the stub_example from with wasm32v1-none correctly fails:

$ cargo build --release --target wasm32v1-none
   Compiling wasm-bindgen-shared v0.2.114
   Compiling unicode-ident v1.0.24
   Compiling cfg-if v1.0.4
   Compiling once_cell v1.21.4
   Compiling wasm-bindgen v0.2.114
error[E0463]: can't find crate for `std`
  --> /Users/humble_proton/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wasm-bindgen-0.2.114/src/lib.rs:53:1
   |
53 | extern crate std;
   | ^^^^^^^^^^^^^^^^^ can't find crate
   |
   = note: the `wasm32v1-none` target may not support the standard library

Indeed it does not support std!

How to exclude std

If you are unfamiliar with no_std build in rust, you just need to do a few steps (that are mostly copy and paste):

First you should exclude the std feature of wasm-bindgen (and any other crates) in your Cargo.toml:

[dependencies]
wasm-bindgen = { version = "0.2.114", default-features = false } (1)
1 This should match the version of wasm-bindgen installed on your workstation.

Then you need to do just a bit of ceremony (this is less scary than it looks) to tell the compiler you want to use the alloc crate (which usually isn’t available in #[no_std] environments, but is here). Then specify a heap allocator[5] and specify a panic handler.

#![no_std]

// Link the allocator and import the heap types: Vec, Rc, String, etc.
extern crate alloc;

use alloc::format;
use alloc::string::String;
use wasm_bindgen::prelude::wasm_bindgen;

// You can use DLmalloc just like `std` does, but we can do better (1)
// https://github.com/SFBdragon/talc/blob/master/talc/README_WASM.md
#[cfg(all(not(target_feature = "atomics"), target_family = "wasm"))]
#[global_allocator]
static TALC: talc::wasm::WasmDynamicTalc = talc::wasm::new_wasm_dynamic_allocator();

#[cfg(target_family = "wasm")]
#[panic_handler]
// A panic results in a trap on wasm anyway so we can cut out the panic handler
// with wasm-bindgen later. We'll keep the standard panic handler on non-wasm
// builds (like `cargo test`) (2)
fn panic(_info: &core::panic::PanicInfo) -> ! {
    core::arch::wasm32::unreachable()
}

#[wasm_bindgen]
pub fn join_strings(a: &str, b: &str) -> String {
    format!("{a}{b}")
}

#[cfg(test)]
mod tests {
    use super::*;
    use crate::alloc::string::ToString;

    // Tests run on native arch; the logic is target-agnostic since we only use
    // `alloc`
    #[test]
    fn duplicate_string() {
        let input = "abc";
        let result = join_strings(input, input);
        assert_eq!(result, "abcabc".to_string());
    }
}
1 See: talc’s wasm readme
2 Copying directly from the rustc book: "[wasm32v1-none] is compiled with -Cpanic=abort by default. Using -Cpanic=unwind would require using the WebAssembly exception-handling proposal stabilized mid-2025, and if that’s desired then you most likely don’t want to use this target and instead want to use wasm32-unknown-unknown instead."

Additional benefits

By excluding std you end up with a few nice side-benefits. For one, your WASM blobs are smaller and probably more effecient because you are doing fewer and less allocations and when you do allocate you are using a better allocator. Another benefit is that #[no_std] crates tend to be smaller and "do less" than the bigger crates. This leads us to the downsides though:

Pitfalls

Unfortunately, this approach may not be feasible for some projects. For crates to support #[no_std], they usually have to be built with that in mind from the beginning and many if not most "batteries included" type crates assume you in a std library environment, making compiling them without std close to impossible. It is much easier start a new WASM project with this approach than it is to migrate a WASM project to a #[no_std] style dynamic library.

Option 2: Better testing

Improved testing is always an improvement to the overall system. There’s no such thing as a test you get for free, and tests are an overhead on development - they require maintenance and they only help improve the system, not actually fix anything. Of course catching bugs early is much more effective than catching them in production (or even worse, having a customer report it to you because you didn’t catch it).

Testing is only as good as your coverage[6] and the logic/assumptions it validates. The compiler can catch bugs as you write them, whereas tests only catch bugs after you’ve written them (unless you are a strict Test-Driven-Development developer). However, we do have a way to test the existing WASM dynamic library in situ, with a wasm executor which is a huge improvement to the alternative of doing unit tests with your computer’s architecture (i.e. when you run cargo test).

The only real method for this option is the admittedly experimental wasm-bindgen-test. Their documentation on usage is pretty good, so I’ll only briefly summarize what we do.

Running wasm-bindgen-test

A complete example can be found at my codeberg blog-demos repo.

First, add a "rlib" type of library build. That is in your Cargo.toml:

[lib]
crate-type = ["cdylib", "rlib"]

This will allow you to run integration tests.

Secondly, add the wasm-bindgen-test crate to your project:

cargo add --dev wasm-bindgen-test

Thirdly, write your integration tests in tests/wasm.rs. For example:

use wasm_bindgen_test::*;

// Run tests in a browser (remove this to run in Node.js/headless)
wasm_bindgen_test_configure!(run_in_browser);

use stub_example::time::measure_delay_ms;

#[wasm_bindgen_test]
pub fn check_delay_test() {
    # measure_delay_ms() uses time which isn't available on wasm
    assert!(measure_delay_ms() > 1);
}

Then you can run the tests:

# check for logic bugs first, running your other tests:
cargo test --release
# check for wasm errors:
wasm-pack test --firefox # or safari, or chrome

Open a browser to http://127.0.0.1:8000 and you’ll see output like:

Loading Wasm module...

running 2 tests
test check_delay_test ... FAIL

failures:

---- check_delay_test output ----
    error output:
        panicked at /rustc/4a4ef493e3a1488c6e321570238084b38948f6db/library/std/src/sys/pal/wasm/../unsupported/time.rs:13:9:
        time not implemented on this platform

        Stack:

        __wbg_get_imports/__wbg_new_d6846beabaecc372/<@http://127.0.0.1:8000/wasm-bindgen-test:375:25
        logError@http://127.0.0.1:8000/wasm-bindgen-test:705:18
        __wbg_new_d6846beabaecc372@http://127.0.0.1:8000/wasm-bindgen-test:374:57

The important line is: time not implemented on this platform

You can also run in --headless mode which doesn’t require a manual step of refreshing the browser page, but headless mode doesn’t capture output when the code panicks (or at least I couldn’t figure out how to get it to work). If there’s a logic bug that only exists in the wasm version, the output in headless mode is probably enough - you can always try headless mode first.

Additional benefits

You can use all the crates you want, even if they have functions that would execute unsupported system calls. As long as your code doesn’t launch those functions, you can run in the browser without problems!

Pitfalls

Larger wasm bundles.

Safety is reliant on you writing good tests - which is not as great a strategy when compared to compiler-enforced checks. We could accomplish largely the same thing in TypeScript or JavaScript and avoid this whole wasm mess!

Conclusion

By default, you should start rust wasm projects with wasm32v1-none instead of wasm32-unknown-unknown - this trims the size of your wasm bundle and gives you better safety guarantees. If you are working with existing projects (especially ones with lots of imported crates) then I would recommend integrating wasm-pack testing into your workflow, this isn’t as seamless and integrated as targeting wasm32v1-none but you can still check that you aren’t calling non-existing functions if you get good test coverage. If you know about other languages compiling to wasm like C or GoLang, you may want to consider wasm32v1-none for much of the same reasons.

1. I am not the first person to think about this, I learned it from https://geeklaunch.io/blog/make-invalid-states-unrepresentable/ and from https://www.youtube.com/@NoBoilerplate
2. The Web Workers kind of thread management is available across all major browsers, but this has very different semantics than the standard rust threads, so you’d need to use a specialty library like wasm-bindgen-rayon or do it manually with enabling of nightly features.
3. Tested in Firefox 149.0 on MacOS, but this should be the same on all browsers.
4. See the rustc page on wasm32v1-none for more information.
5. I suggest using talc, which is designed for wasm in mind and outperforms the default allocator, DLmalloc. If you have to add one anyway, why not just use a better one?
6. There’s a lot more to testing than seeking 100% "coverage", but going from very low coverage to "mostly covered" is pretty good - I personally shoot for 85%.
]]>Holland GibsonDIY rust on the web2026-04-02T00:00:00+00:002026-04-02T00:00:00+00:00https://blog.hollandgibson.com/2026/04/02/rust-wasm
Table of Contents

Rust and WASM

Rust as a low-level language makes it a great candidate for WASM compilation. There’s no garbage collector to contend with, but there’s also many fewer footguns than, say, C++ (or so I hear). Rust can easily compile to wasm32 targets, has strong typing, has a great DevX, and is high performance. It is also just a lot nicer to work with than JavaScript (js), at least in my opinion.

The wasm-bindgen book is fantastic (and I borrow many ideas from that book here), but it skips a couple steps and some explanation so this blog post can help go over starting a rust-wasm project from scratch.

WASM in 2026

WASM in (early) 2026 means a developer must accept the following:

  • no direct DOM access from WASM

  • single-threaded only

  • high performance (low overhead) js-wasm function calls

  • lower performance js-wasm data passing (all objects get re-encoded)

  • 32-bit architecture

Getting started

You can follow along and see working examples at https://codeberg.org/humble_proton/blog-demos

Requirements

  • rust and cargo toolchain installed (go to rustup.rs)

  • wasm-bindgen-cli installed: cargo binstall wasm-bindgen-cli

    • binstall and install are interchangeable but binstall is better if you have it installed[1]

  • wasm32-unknown-unknown target available. I.e. rustup target add wasm32-unknown-unknown

Without frameworks, how does rust run on the web?

There’s essentially only 1 absolutely required crate, but an additional 2 are very useful.

  1. wasm-bindgen - library and tools for generating bindings for the web

Then there are 2 crates for importing APIs,

  1. web-sys - imports for all of the Web APIs. Things like File, Clipboard, HtmlElement, Window to name a few.

  2. js-sys - imports for all the JS APIs, like Promise, Array, BigInt, etc.

Creating a bare bones project

This is the shortest amount of steps from empty directory to working web demo.

  1. Create the project: cargo init minimal_wasm_demo --lib

  2. Change the project to a dynamic library (in the Cargo.toml):

[lib]
crate-type = ["cdylib"]

  1. add the wasm bindgen crate: cargo add wasm-bindgen

  2. in the src/lib.rs file:

    1. add use wasm_bindgen::prelude::wasm_bindgen; to the top.

    2. add #[wasm_bindgen] before the pub fn add(left: u64, right: u64) function that was created for you in step 1. This is what tells the wasm-bindgen CLI tool that the adder function should be accessible from JavaScript.

  3. cargo build --release --target wasm32-unknown-unknown

  4. wasm-bindgen target/wasm32-unknown-unknown/release/minimal.wasm --out-dir target/pkg --typescript --target web - This generates the bindings and "glue" code to/from js.

Success!

You now have 4 files in your target/pkg directory

  1. _.js - javascript bindings.

  2. _.d.ts - typescript header file for the wasm bindings.

  3. _.wasm - the wasm file!

  4. _.wasm.d.ts - the typescript header file for the wasm functions.

Exploring the results

To avoid CORS problems, you must use a simple web server.

python3 -m http.server

or if you don’t have python3 installed:

cargo binstall miniserve
miniserve . --index "index.html" -p 8000

The console window will show 1 + 2 = 3 if everything is working correctly.

Improving file sizes

The above example results in a 1.2KB wasm file and 3.8KB js file. We can do things ranging from very easy to not-very-easy to optimize the artifacts.

File size is not the only metric that matters, but it usually is the most important. Having a function execute a few more bytecode-level instructions is not humanly perceptible unless you are doing a ton of processing, so sacrificing a few milliseconds of execution time is better than sacrificing many milliseconds in just http transit time[2].

Furthermore, some optimizations don’t even affect the performance of the wasm object at all, and everyone must download your wasm file to their browser to do anything with it.

Lastly, size optimizations are like any other kind of software optimization:

  1. Judge via objective benchmarks (in this case, file size)

  2. Let the compiler/profiler tell you where to optimize (check each optimization to make sure each successive optimization helps rather than hurts!)

  3. Consider what you lose by optimizing (this is typically "readability", but in this case you probably aren’t reading the WAT[3] version of your wasm binary, so this shouldn’t matter as much)

Step 0 - gzip

Nearly every web server uses gzip to compress data before sending it to the client, so this should be essentially automatic. Check that your server does this and call it a day.

For example, we are now left with (roughly) an 844 byte wasm file. That’s about a savings of 30% in this case.

Step 1 - compilation options

At the expense of longer compilation times, we can compile with LTO enabled which improves memory layout and locality (among many other things:[4]

Add:

[profile.release]
lto = true

to the Cargo.toml.

Optimize for size over speed

We can also inform LLVM to compile rust with overall layout optimizations. There are two main options for opt-level:

  • "s": optimize for binary size

  • "z": optimize for binary size, but also turn off loop vectorization (i.e. more aggressive, performance impacts)

Loop vectorization can also increase file size in some cases, so remember point #2 of optimizations mentioned above, check each compiler option!

Add:

[profile.release]
opt-level = "z"

to the Cargo.toml.

Results

So we are left with:

[profile.release]
lto = true
opt-level = "z"

in the Cargo.toml.

This results in a 655 Byte wasm file (939 Bytes before gzip compression). For this very bare-bones project, there are no loops so there’s no difference between s and z optimization levels.

Step 2 - wasm-opt

Installation

Another tool we can use is the wasm-opt tool, available from the "binaryen" project. Download the appropriate release from their latest GitHub releases and expand it to a known place on your system (I put mine at $HOME/Applications/binaryen), then add the bin folder to your $PATH (if you are unsure what this means, see this StackOverflow answer).

I’m using version 128 for the purposes of this post:

$ wasm-opt --version
wasm-opt version 128 (version_128)

Usage

wasm-opt --help explains everything, but a short synopsis is:

# Optimize for size.
wasm-opt -Os -o output.wasm input.wasm

# Optimize aggressively for size.
wasm-opt -Oz -o output.wasm input.wasm

# Optimize for speed.
wasm-opt -O -o output.wasm input.wasm

# Optimize aggressively for speed.
wasm-opt -O3 -o output.wasm input.wasm

Results

This should be ran after wasm-pack.

We end up with a 611 Byte wasm file (800 Bytes before gzip compression).

Optimization summary

So, we can shave off a fair amount of code size with just running some basic commands.

We started with just a --release build and wasm-pack resulted in a 1.2KB wasm file. After changing the compiler flags, and running wasm-opt we are left with an 800 Byte wasm file, that’s roughly 35% size for free![5] Gzip compression (added by the server automatically) compresses this even further.

Note that these optimizations were chosen because they didn’t require any changes to our code, no restrictions to rust features, etc.

There are more…​ advanced optimizations we can perform, but that is outside the scope of this blog post.

If you want to look into them yourself, try:

References and Continued Learning

  • wasm-bindgen book (successor to the rustwasm project)

  • wasm-pack is another useful CLI tool that can streamline a lot of the process used in this post. Install with: cargo install wasm-pack or follow their directions.

Addendum

This is the WAT version of the result from step 2 of the optimizations looks like:

(module
 (type $0 (func))
 (type $1 (func (param i64 i64) (result i64)))
 (import "./minimal_bg.js" "__wbindgen_init_externref_table" (func $fimport$0))
 (memory $0 17)
 (data $0 (i32.const 1048576) "\c0\00/Users/humble_proton/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wasm-bindgen-0.2.114/src/externref.rs\00/rust/deps/dlmalloc-0.2.11/src/dlmalloc.rs\00RefCell already borrowedassertion failed: psize >= size + min_overhead\00r\00\10\00*\00\00\00\b1\04\00\00\t\00\00\00assertion failed: psize <= size + max_overhead\00\00r\00\10\00*\00\00\00\b7\04\00\00\r\00\00\00\02\00\10\00o\00\00\00\7f\00\00\00\11\00\00\00\02\00\10\00o\00\00\00\8c\00\00\00\11")
 (data $1 (i32.const 1048916) "\04")
 (table $0 1024 externref)
 (export "memory" (memory $0))
 (export "add" (func $0))
 (export "__wbindgen_externrefs" (table $0))
 (export "__wbindgen_start" (func $fimport$0))
 (func $0 (param $0 i64) (param $1 i64) (result i64)
  (i64.add
   (local.get $0)
   (local.get $1)
  )
 )
 ;; custom section "producers", size 114
 ;; features section: mutable-globals, nontrapping-float-to-int, bulk-memory, sign-ext, reference-types, multivalue, bulk-memory-opt, call-indirect-overlong
)
1. You should use cargo binstall …​ as a drop-in replacement for cargo install, as cargo-binstall is a LOT faster in most circumstances and will still revert to compiling from source if the pre-compiled binaries aren’t available.
2. See: https://rustwasm.github.io/book/reference/code-size.html#why-care-about-code-size for more information.
3. WAT or WebAssembly Text Format is like an assembly version of your .wasm binary, see the Addendum for an example from this blog post.
4. Wikipedia and the LLVM LTO page have more info about what LTO does. In short, a lot and there’s a good case to be made that all production software should have LTO enabled.)
5. Our final result may have slightly worse performance (or it might not).
]]>Holland GibsonWhere are they?2025-01-30T00:00:00+00:002025-01-30T00:00:00+00:00https://blog.hollandgibson.com/2025/01/30/we-should-have-this-by-now
Table of Contents

Intro

It’s 2025[1], and there are a number of problems that seem tractable but somehow we haven’t solved them yet. This is especially true when it comes to tools and processes. You can think of this post as sort of my wishlist, because I don’t quite have the time to fix any of them myself.

AST-aware code revision control

What we currently have

Git 1.0.0 was released in 2005, subversion’s 1.0.0 in 2004, and mercurial’s 1.0 in 2008. Those 3 version/revision control systems represent essentially all (>98%) professional developers[2]. There are a few promising new tools, but they haven’t changed the way we reason about changes.

There’s Pijul which is patch-based, rather than snapshot based like the "main three" above. This improves how to understand how the tool internally represents the state of code and changes, but doesn’t fundamentally change anything.

Meta/Facebook released (GPLv2) their internal VCS (version control system) tool, Sapling, which is the result of supercharging mercurial to work in a top-down, monolithic (monorepo) collection of a very large amount of code. Facebook apparently uses a giant monorepo, and at their scale Git or Mercurial just wouldn’t cut it.[3] They (like many modern alternatives to git) also added some quality of life improvements, namely around conflict resolution, speed, and fixing accidents.footnote[See Meta’s 2022 blog post about Sapling for more details. While I welcome improving the UX of Git, this is still just an iterative improvement.

Then there’s Fossil, which is like a self-hosted GitHub-lite or Gitea except that the versioning control applies to tickets, wiki, docs, etc rather than just the code. I’m a big proponent of putting everything in version control[4] so that is closer to a fundamental shift, but there’s nothing stopping you from doing all that tracking in plain-text in your git repo right now. Additionally Fossil tracks changes much more like a database tracks changes: atomic and consistent (i.e. cannot be revised). Small wonder the most famous user of Fossil is SQLite.

There are other tools like Jujutsu, or Breezy and others, but they all appear to focus on git-compatibility or some combination of the "main three" I listed above.

AST-aware

All modern code can be represented as an abstract syntax tree (AST), and some tools like tree-sitter exist to create that tree in just about all languages people are writing code in. Why then, is there not a VCS that operates on those constructs rather than the strings or bytes that the code lives on disk as?

For example, this code:

const x = 3;
const y = 2;
let a = x - (y + 5);

roughly becomes:

Diagram

Combining an AST with some additional metadata (for organizing and readability) and a strong, automatic formatter should result in consistent code without requiring completely new Integrated Developer Editors (IDEs). Although I would expect the advent of AST-aware VCS to also motivate the creation of AST-targeted IDEs that operate on the tree rather than files on disk too. Code could be consistently "rendered" to a bunch of source files, etc. Changes would be tracked much closer to what the language understands rather than what changes on disk.

Just look at what the diff or patch looks like when moving code to a new file[5], or when trying to rename a variable resulting in the conversation degrading to "you’re holding it wrong".

We have the technology now, so where is it?

Better formal methods

A blackboard full of diagrams and equations written in chalk.
Photo by Dan Cristian Pădureț on Unsplash


Formal methods are fantastic for eliminating errors. They are truly amazing if you can work in the way that works best with formal methods. You can either write the mathematical proofs first, and generate the code. Or, you can write your proofs/contracts alongside your code and (usually with some extra help from you) get the theorem prover to give you a certificate of correctness.

Formal methods can give a very high degree of certainty that your software will perform correctly (although speed/efficiency is not addressed). Their use in critical applications like avionics or security libraries is a boon for all of us. Unfortunately formal methods aren’t user friendly enough.[6] Using formal methods requires learning at least new ways of writing out your proofs alongside or instead of your code and interactively generating proofs on existing code is not feasible right now.

What I want is to be able to specify the contracts of each function using the programming language, and having the compiler or some sort of helper give guarantees and ensure correctness without having to jump through hoops. Things like bounded-numbers, strong-typing, semantic[7] or refined types are available now but not always all in the same language[8]. and they aren’t enough yet. Perhaps LLMs can help with this, so I have a bit more hope that formal methods can become easier to use.

Dependency capability limits

Stacks and stacks of paperwork.
Photo by Wesley Tingey on Unsplash


Transitive dependencies are a security nightmare[9]. Between the xz supply chain attack and npm’s left-pad incident, there is much to fear when it comes to the security of your software supply chain. However, the absolutely huge performance bonus you get from using well-managed and well-optimized libraries are too important to leave behind. So what then?

Why then, can we not limit the capabilities of dependencies? I would love to say in (i.e. configure) my Cargo.toml to prohibit the reqwest crate from accessing the disk and prohibit the serde crate from doing anything on the network. Even better, it would be amazing to fully specify the limits to the dependencies from my code to a highly precise degree, like compile time guarantees that the disk access is read-only in a specific spot, or sandbox, etc.

We have things like wasm that are a start, but they don’t give you any control besides giving you a relatively safe sandbox to run other people’s code in.

This gets a little complicated because the problem of someone linking to another binary or writing assembly, both of which have appropriate uses, can be used to bypass via obfuscation most checks I would think of being possible currently. I think a new high-level language is needed to demonstrate how nice this could be. A language where the capabilities are detected by the compiler and clearly (automatically) documented so automated enforcement is possible.

Bonus - Clocks

Ok this isn’t really something that will help a software developer, but I am frustrated that so many clocks are out of sync. Between kitchen appliances, wall clocks, car clocks, etc I just assume that they are +/- a few minutes of the actual time. Why are we still setting clocks manually? I own a radio-synchronized wrist-watch[10], some radio synchronized wall clocks, some GPS-synced clocks but getting anything remotely nice in any device that provides it’s own clock is extremely difficult. I mean $1000 ovens can’t even be bothered to put a quartz oscillator for their clock[11]!

it’s been over 60 years since WWVB (the NIST time clock for the US/Cananda) officially launched and 45 ish years since GPS was available to civilians. Why aren’t these more available and just included in things?

The main problem I see is that there’s no cheap, accurate, reliable way to get time signals - GPS and WWVB (or equivalent) don’t work super well through walls, after all. But we all (mostly) have WiFi. Surely there’s space in the access point beacons[12] for adding some world time (a sort of up-time of the WiFi access point is already present) to those packets. That way you could get internet time without ever connecting to the internet!

1. or 12,025 HCE
2. In StackOverflow’s 2022 Developer Survey only 1.38% of "professional developers" don’t use Git, SVN, or Mercurial as their primary version control
3. To be fair, Git was designed for an email, patch-based workflow well before anyone had ever coined the term 'monorepo'.
4. Someday I’ll explain
5. This is not the best example because the filenames are de-facto modules in python and this technically results in a different structure, but there is no real change because a test got moved from one file to another. The function itself is the same, but git can only see them as completely separate changes.
6. Hillel Wayne in his formal methods blog post lists great reasons why formal methods don’t work.
7. Or "human-centric types"
8. I’m aware of some refined types in rust, like uom but not language-wide constructs
9. Laurence Tratt gives an exquisite analysis of this problem on his blog. I definitely took some inspiration from that post here
10. A Casio LCW-M100TS, an amazing watch
11. They just use the mains frequency, which is not very precise
12. There’s a whole vendor-specific payload section to the 802.11 beacon frames, and clearly plenty of room to put a time signal. An access point could emit a beacon, say once a minute, containing the linux epoch and most devices could ignore it, but clocks could listen for that beacon and correct their clock.
]]>Holland GibsonHow to be a parent (or loved one) in the hospital2024-11-20T00:00:00+00:002024-11-20T00:00:00+00:00https://blog.hollandgibson.com/2024/11/20/being-a-parent-in-the-hospital
Table of Contents

Something is wrong. You don’t know why your love is crying. They’re feeling worse and worse and you can’t make it better. In a panic you bring them to the emergency department, wait too long to get seen, and finally get taken to a sterile, but busy area. A few people with stethoscopes ask a lot of questions, and thank goodness, it wasn’t just you. Something is wrong and they say they’re going to figure it out.

Active ICU room, many doctors and nurses wearing masks standing over a patient
Photo by JC Gellidon on Unsplash

You’d think being the in a hospital would mean having lots of people take care of you so the only thing you have to worry about is following instructions and making sure the rest of your life doesn’t fall apart. In my experience, this is only part of the deal.

Having spent close to 90 days (and most of those nights) in the hospital as a healthy parent of a sick child over the last year or so, I’ve started jotting down reminders on all the things that I need to do while in the hospital.

I hope this post helps anyone who finds themselves or is with someone in the hospital and helps you get the best treatment possible.

Of course these are only my experiences, but we were at the best children’s hospital in the state, one that happens to be tied to an R-1 research university as well.

Things the providers don’t do

  • coordinate with other teams

  • check for new notes after rounds

  • think very hard about patient-comfort

Not coordinating with other teams

I had naively assumed that the providers and professionals in the pediatric ICU would be a well-oiled machine that worked hand-in-hand with their counterparts: the cardiology team talked to the neurology team, and the charge nurse knew both of their updates.

I think that the providers (doctors, nurse practitioners, nurses, therapists, etc) each work on finding solutions to things that they are uniquely educated to do. Of course there is a lot of overlap in their expertise. As an example: despite it being something the nurses do more often, just about any provider can (and will) adjust the air flow to the nasal cannula as needed. That doesn’t mean that they all are trying to do the same thing.

One team may be focused on reducing the dependence on the "low flow" oxygen support, while another may be trying to keep all the stats (heart rate, blood pressure, O2 sats, etc) in a good place so the patient can recover enough for a big upcoming event, for example.

The system generally in place to get everyone in sync is "rounds." This is where at least 1 representative from every team is present to coordinate on the plan of care. The problem with this system is that one cannot be on rounds all day long. At some point they have to, you know, practice medicine. Write orders, review results of tests and all that other stuff.

In-between rounds, as lab results come in and stats change, the plan rightfully adjusts. However, this is where the discrepancies originate. Which leads me to the next point:

Checking for new notes after rounds

Generally, the providers review notes prior-to rounds, during rounds, and when they are expecting something (like the results of the ultrasound they ordered). A part of practicing modern medicine (I think, at least) is do record notes after every update in the computer system. This gives a very robust, high fidelity record of the treatment and plan for any patient. Any provider can log in to see everyone’s notes. A new specialist can get called and know most of what they need to know before they even get to the room!

However, just like a provider can’t spend all day on rounds, they can’t spend all day reading and writing notes (not to mention that the hospital can’t directly bill the time spent writing/reading notes - but that is a discussion point for another time). So, an individual coming in may not know everything they might want to know. Or worse, may have missed rounds for one reason or another and may be actively trying to achieve something counter-productive to the plan.

The plan can change on a dime with just one test result or one new symptom. But when all they think about is tackling the "problem" they sometimes can forget about the patient.

Putting the patient first

I won’t belabor this point. "Patient-first" care is the standard way of practicing medicine in the USA. Sometimes though, the small things just aren’t as important to the people trying to solve the bigger problems.

They don’t know when the pain is getting worse, or how long it’s been since the patient last had a meal or got to sleep. This is another, perhaps more specific to my experience, problem. The hospital makes it very difficult to get sleep or eat well. Try doing those things poorly during normal times and see how you feel. Now imagine being in a lot of pain, and adding that discomfort to the list. Eating and sleeping right are pivotal to recovery and there are often small changes that can be done to vastly improve the experience at the hospital. For example, waking up to get weighed at 3am because that’s a better time for the nurse is completely unacceptable, that can wait.

OK so knowing all this, what can we do?

Things you can/should do

  • back-brief[1] each provider

  • ask about 1.5 times as many questions as you think you need to

  • advocate for the patient

The good news is that a non-patient (you or another loved one) in the room can help cover these gaps and improve the care the patient gets. My strategy was to try to learn as much as possible about the plan of care and be vocal whenever I wasn’t sure they were doing the right thing.

It is hard to be an advocate (for me at least) when you have dozens of people with decades of time spent learning/practicing medicine saying things confidently. However, as the parent of a patient (or you if you are the patient) you are ultimately the one who has the authority to reject any treatment they give you. I didn’t have any moral or religious qualms with any of the treatments suggested in our hospital stays, and I don’t think I ever outright rejected a treatment they recommended.

I asked a lot of questions to understand, and asked a few questions to make sure the provider knew what the other provider (that probably left just minutes ago) told me. More than a few times, the provider changed what they were doing after that. Most of the time, they were polite and confirmed that they knew what I was talking about.

Parting notes

I spent all this time focusing on gaps and problems that can happen on a hospital stay. I have the utmost respect for the professionals who spend their lives trying to help others get well. They will make much more a difference in people’s lives than the code I’ve written ever will. I have never wished that our providers had more experience or were better at what they do, but that doesn’t mean that there aren’t ways to improve the treatment for someone you love.

If you follow absolutely none of this advice, you will probably still have a satisfactory experience at the hospital. But if given the chance to get your loved one better care, wouldn’t you? Some of this advice may be useless or worse in a situation you find yourself in, so you should also exercise judgment in following them too. Good luck! I hope you never find yourself in the position to learn these things first hand, but if you do - if I can help, believe me you can too.

1. I use the Army’s definition of this as they describe it in their "Mission Command" publications. Essentially, you explain to the presenter (probably the most senior person present) what you understand their plan/briefing to be - proving you understood what they described to you
]]>Holland Gibson