Wouter van Oortmerssen

Working on the game Voxile. Prev. Wasm / FlatBuffers / games&VR at Google. Made TreeSheets, PLs (Goose, Lobster, False, Amiga E) and game engines (Cube..).

[Wouter van Oortmerssen @wvo]

After 8+ years at Google, I'm leaving to start my own gamedev company!

[Dan Levine @daniel_levine]

Some startups make unbelievable financial returns, but most don't. I'm fortunate enough to have a reasonably good track record as an investor, but I never know which will be which deterministically.

I realized that fact a long time ago and resolved to try to work with founders that I love in a deep and intangible way. Folks I wake up wanting to help every day. People I try to help however I can, whether it's a weekday or weekend, a personal matter or a work one, a happy situation or a sad one.

I want to work with founders where I deeply care and enjoy the holistic journey, no matter the outcome. I optimistically believe if I do that, the aggregate returns will take care of themselves. That's the beauty of real venture capital.

@stevekrouse is a real one. I loved every minute of Val Town and I'm excited to continue the journey with him for another few decades if he'll have me

[Wouter van Oortmerssen @wvo]

@lucasmeijer Though I presume that path is really hard, because you'd want to test against some representative set of C/C++/Rust/Zig/.. Goose? programs to know you're not regressing, and some of these less useful looking passes are indeed not needed. Or regain speed elsewhere.

[Wouter van Oortmerssen @wvo]

@lucasmeijer A non-1:1 translation would first analyze what we do different first: see which passes are actually necessary, and see which passes can use improved algorithms and so forth. Can we make something that on average generates same runtime speed but way simpler?

[Wouter van Oortmerssen @wvo]

@_mackenziebowes Yes, you could have gotten a lot of the speedup in other ways too.. still, nice work :)

[Mackenzie (6’6”) @_mackenziebowes]

software factory rewrote part of @tobi's qmd in @wvo's goose, speeding up indexing by ~30x.

also wrote a LoRA trainer that uses ~5x less memory than PyTorch and completes runs ~80% faster.

this weekend. since saturday morning.

[Wouter van Oortmerssen @wvo]

@johnzabroski @kellabyte Current thinking: https://t.co/heJfbfuw9b

[Wouter van Oortmerssen @wvo]

@johnzabroski @kellabyte yes, that is the idea.. in our design so that is a special loop type that asks the compiler to check there are no inter-loop dependencies, and thus multiple iterations of the loop can be run at once in SIMD

[Wouter van Oortmerssen @wvo]

@johnzabroski @kellabyte Thing is, we already don't have an "OO heap", Goose is a very much not-OO language :)

[Wouter van Oortmerssen @wvo]

@lucasmeijer @dhh Let's do it! Will DM.

[Wouter van Oortmerssen @wvo]

Woah, Goose leads significantly in speed, and by a lot more in memory, in @DHH's Campfire port comparison!

[Kait Kasak @KaitKasak]

@dhh A bit late to the party, but Campfire in Goose is now in the shared harness (PR #13), matching Rails (main) response for response.

- Posting: 1.26x Jai, 1.74x Rust
- Pages: on par with Jai, 8-9x Rust
- Memory posting: 16 MiB vs Jai 77, Rust 90, Rails 889

https://t.co/M2zOHNhkLE

[Wouter van Oortmerssen @wvo]

@lucasmeijer @dhh Een kleine wereld :)

[Wouter van Oortmerssen @wvo]

@lucasmeijer @dhh Yup when I first worked on Goose I thought, who wants a new language in 2026? Does AI make languages irrelevant? Turns out, if it offers something new, a lot of people care, in fact, moreso now, as "does my code run faster in Goose" can now be answered in no time.

[Wouter van Oortmerssen @wvo]

This on top of @KaitKasak 's web framework libs for Goose, e.g. https://t.co/BPUPkQkVUE

[Wouter van Oortmerssen @wvo]

Not bad for a new programming language released just a month ago :)
https://t.co/rO5puQQPzK

[Wouter van Oortmerssen @wvo]

Goose: my latest programming language. Safer, faster and less memory than Rust/C++ for algorithms where tightly packed, flat data structures matter.

It can represent more kinds of data structures as flat, pointer-free bytes than any language I know.

https://t.co/qqC3RFD0BS
1/

[Wouter van Oortmerssen @wvo]

@lcamtuf I so want one. I've searched for these in past and even had a hw friend prototype one haha.

The pseudo is probably a better UI for most.. mine was purely logarithmic.

[Wouter van Oortmerssen @wvo]

@johnzabroski @kellabyte Beyond that, explicit SIMD is always an option, but first looking into more of ISPC style functionality.

[Wouter van Oortmerssen @wvo]

@johnzabroski @kellabyte Goose currently has no explicit SIMD yet, it only has `simd` functions which will use the max SIMD the machine has, plus we have some "assist the auto vectorizer" functionality for that. So not "supporting" 16bit SIMD means auto vectorizing is not working.

[Wouter van Oortmerssen @wvo]

@0xTMK @alec93 Here are some initial directions: https://t.co/rUxSodUkdj

[Wouter van Oortmerssen @wvo]

Wow, Carmack just describes a programming system that matches Goose almost exactly. Address space reservation for huge stacks with safe lifetime management.

[John Carmack @ID_AA_Carmack]

I always thought it was a shame that modest default stack setups made alloca() a generally-frowned-upon technique in C/C++. With 64 bit architectures, give every stack a virtual address space equal to the physical memory by default!

You can do a surprisingly good job of memory management with just the stack, and I contend that it has both correctness and performance advantages.

Allocations are a trivial pointer adjustment, and frees are literally free. Keeping everything linearly packed is friendlier for all layers of the cache hierarchy, and it makes keeping everything in huge / gigantic pages easy.

Leaving temporary intermediate blocks on the stack can seem wasteful, but unless you are dealing with algorithms that make > O(n) temporary allocations, it is usually not a big deal.

Static analysis can check if you store a stack pointer into a structure deeper in the stack, which is a use-after-free, and then memory management correctness is guaranteed.

The discipline of caller-allocates-return is awkward in some dynamic cases. It would take a change in low level calling conventions, but you could plausibly have functions that return with the stack extended from where it was when they were called. I’m not holding my breath for that.

It isn’t obvious if having AI coding agents makes discussions of software architecture more or less important!