Side hustle update
Side hustle update
It’s only natural, once you start simplifying, to ask “what if we go all the way?” Right now we’re focused on reducing the connection error rate, or the number of times you open a repl and the Repl.it backend (we call it goval) cannot connect you to a container. Both goval and the workspace will retry, so the number of times you simply cannot get a container is low. (Though we’d like it to be lower!) Most of the times we cannot connect folks to a container, it’s because the container is on a machine that is taking a long time to shut down. In fact, the machine may be shutting down because it’s figured out it’s unhealthy, so it’s not surprise that everything takes a long time.
There are two ways to attack this problem. You can make it rarer for machines to become unhealthy and you can reduce the time between them becoming unhealthy and them shutting down. You want to make progress on both problems but I like to spend my free time thinking about how to shut repls down and start them up again instantly.
For services that run in the background, like a database server or a key-value store, this has been a solved problem for a long time: write updates to a log as quickly as possible, merging them into the main data structures regularly, and scan the log upon startup to make sure you take into account any updates that hadn’t been merged by shutdown time. I’d like to bring that approach to interpreters so that you can resume programs incredibly close to where you left off. I’ve been on the lookout for simple interpreters where I can understand the memory model and stumbled upon QuickJS which looks promising. It may be easier to take this and sandbox it (a la Deno or WebAssembly with WASI) than to start with a sandboxed runtime and understand the memory model. It compiles quickly too! I’ve built
qjsc in this repl out of the box easily. (Actually, you need to build
libquickjs.a, I’ll get to that tonight.)