from urbit to rama

Red Planet 1: Urbit

What got me into Urbit was unquestionably ~timluc-miptev (Tim’s) Twitter threads. His thesis was that software was stuck, and Urbit was the only way to get it unstuck. The mobile mines had been “stripped bare,” and SaaS / the web had lost their luster since the days of Paul Graham. This was 100% true when it was written (July 2022, prior to GPT-4).

“Urbit has the strongest culture because it unites religious energy with technical power.” “Operating Systems are more important than people think.” “[Urbit] unlocks permissionless app innovation, in a way we haven’t seen in awhile or ever.” Boom: easy money.

In order to unlock this religious and technical power, I had to jump a few hurdles, contorting thoughts into a new runic language and peer-to-peer paradigm [1]. The gates were slammed, and I was in. To prove to myself that I actually had a clue what was going on, TomeDB was built. And my belief in the technical power was strengthened when the hour-long activity of deploying a self-hosted Uniswap via Urbit was considered significant in crypto land.

That was perhaps the peak; happy pills started wearing off and cracks in the armor began showing.

• I wondered why if this was “the moment” for Urbit, there weren’t many newcomers; on the contrary, most Urbiters had known about the project for a long time.
• Many Urbiters, from personal experience, enjoy too much the groupthink and sense of community. They irrationally defend the project instead of providing more helpful criticism and direction.
• Due to the deep complexity of the problems Urbit is trying to solve, core development roadmaps often slip.
• The same complexity, lack of performance and tooling causes Urbit companies’ to also fail in delivering or gaining users, some of which I saw firsthand.
• Groups who do have major criticisms about first principles chose exit over reform (Plunder, Uqbar) and their POVs read as more rational.

With the “alright, fine, I’ll let it go” moment being the person that got me into Urbit (Tim of Uqbar) pivoting away from it. [2]

What I’m looking for

I continue to be all-in on first principles and building new technical power. In an accelerating landscape and at a young age, you have to be; otherwise useless skills are being developed. The major concern is “failure” through no personal fault: spending a decade mastering something of no value when you wanted to blaze technology forward. A healthy dose of fear, akin to mastering Visual Basic in the age of the web, is deserved.

My interest in peer-to-peer systems and the “silver bullet” OS has waned [3]. In the age of semi-abundant free software (and now AI-based remixing of it), supercharging developer efficiency is higher leverage than a focus on user-owned software. As developers we hate “Sign in with Google,” but zoom out and it allows for seamless one-click onboarding and a familiar user experience that Urbit auth can’t compete against.

I very much liked Rich Hickey’s ethos (creator of Clojure), unlocking new technical power without throwing away the past. Clojure supports full Java interoperability but adds in functional programming, homoiconicity, subscriptions, dispatching on type (sound familiar, Hoon?). But people could actually migrate to it, and so it has had orders of magnitude more adoption than Urbit.

Languages by themselves aren’t that interesting in the age of big data. So who is bringing the ethos of radical simplification, at the big data systems level of abstraction, solving real problems without throwing the past away?

I bring you Nathan Marz of Red Planet Labs (RPL). [4]

Red Planet 2: Rama

Discussing Rama and how it works is beyond the scope of this article (stay tuned). In short, it’s a Java-based development platform that lets you intuitively express, build, and scale backends orders of magnitude more quickly and efficiently than stringing together different systems. Complexity is handled by RPL (>250k LOC, Clojure, macro-heavy codebase) so you don’t have to. Performance innovations include massive parallelization and processing code coexisting with data, avoiding lots of network latency / cost.

The knockout punch: with Rama, a Twitter-scale Mastodon clone was built in 9 man-months of effort. Disregarding the fact that Urbit cannot perform anywhere near Twitter scale (500M users, 20M writes/second) there’s also the cost angle to consider.

Rama’s demo at Twitter scale ran on ~80 r6gd.large AWS EC2 instances, costing around $4000 a month, plus networking and storage. To be generous, $40,000 a month all-in. If Urbit were to become “real” and not another centrally managed cloud service, everyone needs a Digital Ocean droplet or (better) Native Planet. DO costs $12/month to run an Urbit, so for 500M users we’re talking $6 billion a month. The Rama implementation costs 150,000 times less, is vastly simpler and more performant - easier to reason about and iterate on in the startup space, where speed is everything. Even if we move the decimal a place or two (i.e. New Mars), Urbit is still f**ked by comparison.

More justification is not necessary if we’re talking about new technical power. I have no opinion or obligation towards decentralization; great in theory (maybe necessary in certain circumstances) but doesn’t add up when it has such massive tradeoffs in cost, performance, and development speed.

Acknowledging the importance of founders, two other reasons to favor Rama:

• Marz has a more impressive CS track record: lead engineer @BackType (acq. Twitter), creator of Apache Storm, the “Hadoop of realtime processing.”
• Marz is (presumably) just getting started, Yarvin left Urbit in 2019.

---

[1] I had learned a handful of languages by then, but Hoon was the only one that felt like learning to program all over again. Like the first time, the experience was “this is crazy hard” right up until “this isn’t bad”. It’s not as bad as it first appears though: I think any decent programmer could learn Hoon whereas maybe they couldn’t program effectively in Haskell.

[2] My somewhat nuanced opinion is not really “Urbit bad” or “Urbit good.” The project is moving in the right direction and is poised to continue capturing value from crypto, as crypto continues to thrash around and fail to deliver. There’s a lot of money and sunk cost there to absorb: “blockchain maximalism” isn’t working, and Urbit’s hybrid approach is a viable answer to it.

Decentralization or ponzi-esque value generation did not interest me, though, what did was unlocking new power (the indisputable kind that my Mom could understand), which seems less likely on a reasonable timeframe due to recent learnings. Key word being “reasonable timeframe:” Urbit has lots of extremely talented people who I’m honored to have worked with, and they aren’t going anywhere, so speaking 5-10 years out I make no claim they won’t be successful.

[3] This is due in large part to learning from and watching Urbit community members grapple with technical decisions like Ames’ exactly-once messaging semantics. Zorp cited a paper called End-to-end Arguments in System Design to justify relaxing Urbit’s constraints: the paper describes how a system cannot fully solve most application-level requirements without unacceptable tradeoffs, such as high latency in communication. Which makes sense but also killed the desire to use Urbit! The main point was supposed to be that Urbit solved those things for you.

I also attribute some blog posts by Joel Spolsky (StackOverflow cofounder) on backwards compatibility and the danger of full rewrites.

[4] Besides the martian computing analogy, other similarities exist: its decade-long development cycle, research-heavy implementation and new system analogies.