The Personal Server: Urbit and Sandstorm

Playing around with Urbit and Sandstorm for the past week has been fun. My findings so far:

Sandstorm is by far the more immediately useful of the two. The apps are good if a bit neglected, and the whole thing is very approachable. Deploying a Hugo site on Sandstorm via the sandcats dns service took about 30 seconds. Pretty cool. If there was an easy bridge between a Sandstorm instance and Android, I think I’d have an ideal personal server.

In sharp contrast to Sandstorm, everything about Urbit is arcane. It feels like a piece of alien technology, which of course makes it quite fun. After the initial wonder wears off though, you realize that you have no idea what to do with the thing. The docs are extensive, at least compared to the last time I looked into the project. However, documentation is of limited use when dealing with alien technology. One first needs to speak the alien language.

Even if learning an alien language sounds fun to you, a less sexy barrier will get in your way. Urbit is slow as hell. It’s hard to tell exactly where the latency lives, but it seems to be both in the local interpreter and the network, which is unsurprising since the network is running on the interpreter.

If you thought you could bypass the runic language requirement and get a sense for the architecture from the codebase, well, I’ve got some bad news. The codebase is inscrutable. The style guide dictates that variable names should be three-letter monosyllables, with a (proprietary) type annotation at the end. It justifies this by comparing the system to the use of greek letters in mathematics, which sounds convincing on first pass. However, the reason greek letters (and all abstract symbols) work in math is firstly because they all have a distinctive look, and secondly because they almost always have a well-defined context, both syntactically and semantically. Unfortunately, gof, pro, bus, lof, tul, and hil all look pretty much the same in a monospaced font, and C doesn’t exactly lend itself to providing meaningful syntactic context.

On a brighter note, Hoon, the functional language which is the glue of Urbit, seems pretty cool. I don’t have enough of a functional background to critique it as a language, but the glyph-based syntax actually seems reasonable, if again, arcane. My experience at this point is limited to working through some of the tutorial docs in the repl. I still have no idea how to actually write, save (if such a concept exists), and run a hoon program, so take this bit for what it’s worth.

I’m worried that the promise of Urbit will ultimately be subsumed by the arcane design choices attached to it. If the goal is wide adoption, then an intermediate goal should be a minimally painful transition from the warm grasp of unixland. I know the ad copy talks about Urbit one day being “as easy to configure as an iPhone,” but until then, it would be cool to build, boot and immediately feel at home.

I’m also worried that the project is just too hard to contribute to. The current speed of the interpreter seems to preclude the active development of Hoon programs, at least if I understand what that entails. I don’t think I need to explain how the codebase issues brought up earlier make contributing harder. Thankfully the Urbit team has stated that making contribution easier is a priority, so maybe we’ll start to see more things getting farmed out on the issue tracker.