I have enough savings to buy a modest cottage and to last me a year or two being frugal. After that it’s anyone’s guess, but I am beyond excited not having to program for a living any more, just on what feels meaningful, in complete autonomy.
Projects lined up: a Erlang-like microkernel/runtime I have been designing for the past 4 years, a series of small games that I have been itching to work on, then, of course, the lifelong project of living in a rural house. Stretch goal if I win the lottery: build a solar farm.
Maybe I will be so lucky never to have had to use LLMs in my work. You guys have fun without me. :-P
Word of advice.
Get a part time job where you can keep your skills up-to-date because from personal experience personal projects on GitHub will not be enough to land a job in two years. Make sure for every penny you spend you are earning equal.
The two years are going to fly by.
EDIT: I'm not joking about taking this serious. You want to be working when people start losing their jobs to AI. Most likely this is going to end with society rethinking distribution but you are going to need to be able to survive the changes and 2 - 3 years is not enough wealth.
My solution was getting a part-time job (non tech) but also had to significantly change my spending habits which was not easy.
I have a very niche set of skills so I could up until 6 months ago pick up contract work anytime I needed. Despite being one of the best in the world at what I did, I can't compete anyone with $400 in tokens using Codex or Claude Code. I'm pivoting quickly but the sentiment is "Oh, shit, this is coming fast and heavy!"
Sure it's not 'the smart thing to do' but if it makes you happy and you're still not far worse of than most people...
I don't want to step on your design process, but if you want to explore some microkernels to run beam, I can link you to mine and another one that I ran into recently. Asking before linking, because sometimes you'd rather not look.
2. I'm not exactly looking to recreate the BEAM. I'm building a message-passing microkernel built on my interpretation of capabilities: they replace PIDs in a way that they basically become akin to object pointers, with all the extensibility and security. It's a pretty wild prototype, with a ring-0 kernel that's less than 2k lines which only deals with paging and interrupts, and the userspace is one-scheduler-per-core and a stackless design on a linear address space. A design goal is MAXIMUM performance and simplicity: in most cases a sending a message to another capability is no heavier than a function call, unless the destination is currently busy.
Processes just export a
void handle(void *cap_private_state, msg_t message)
Here's my thing: Crazierl https://github.com/russor/crazierl/ demo (desktop recommended) at https://crazierl.org/demo/
Here's the other one: Tyn https://github.com/tyn-os/kernel
I haven't studied Tyn, I think from the high level we both have the same goals; enough kernel to run BEAM, and then BEAM does the rest. I wrote in C because learning Rust and bare metal OS stuff at the same time seemed like too much. Crazierl does much less in my kernel; my kernel handles time keeping, memory paging, interrupts, fallback console output, and a simple read only filesystem. Tyn includes device drivers and tcp/ip in the kernel as well. Crazierl runs BEAM compiled for FreeBSD and Tyn runs BEAM compiled for Linux (musl). Crazierl is x86 32-bit, Tyn is x86 64-bit.
IMHO, regardless of what your eventual target is, I would consider running on x86 with bios boot, because it means you can run in v86, which is handy for sending links to demos.
I think building a multiboot capable OS and relying on other people's loaders is a good step to reduce effort.
Starting with serial console also helps a little. VGA text isn't too bad, but UEFI (or other) framebuffer means you need a font renderer and all that. That might be fun and interesting, but it doesn't need to be in the critical path.
If you want to run on hardware, test frequently. Most of the emulators aren't super accurate in early boot, and let you get away with stuff that won't run on hardware. Serial console helps here, because on a pc, writing to the serial port is easy and your output will stay in the terminal even if the pc reboots.
Fully automated PXE boot is helpful too, if you get into a boot loop, it just keeps pulling the latest, and you can push a new binary and wait for the output without having to touch the device under test. Also handy once you get it working a bit... just reboot to pull in new code.
I ended up coming back as a contractor, but have repeated the cycle 3-4 times since then. It's a strange one.
All this to say, a person trained to work for someone else 40 hours a week for all their adult life is not able to self-direct and find meaning without a lot of introspection and readjusting.