Pragrammatic critique of Urbit
I really like the Urbit project. I don't know how long I've been following it now. It was definitely earlier than 2016 when I discovered it, probably even 2014.
I think #Urbit is fundamentally trying to address the right set of problems in a comprehensive, holistic way. The fact that the Internet is broken for anything but centralized silos. I am deeply enthusiastic and cheering for Urbit. I do want it to succeed!
But in this post, I'm going to focus on an honest critique. I've actually read a lot of interesting critique of Urbit over the years – all that I could get my hands on. Mine is going to be less ambitious, and mostly down to earth and pragmatic. I hope it won't come out to harsh.
Slow development speed
It's been years since I've been periodically trying out Urbit, reading about it and discussing it online. And to take a naive, unsophisticated perspective: I'd say that 4 years ago it was a weird IRC-like command line chat with great ambitions, and after that 4 years, it still is a weird IRC-like command line chat with great ambitions. Only a little less stable recently, but with Ethereum-based identity system.
I do realize that under the hood there was a lot of progress. And the Azimuth identity system is a great practical step forward toward a practical network. But this pace is worrying me. I do understand the “reinventing computing” takes time, on the other hand... how much? I don't know. I just feel like we need Urbit now, and the “hundred years computer” pitch is about the time it's going to get it to actually do something useful.
I really hope we will begin to see some practical progress this year. I am wondering sometimes about the financial realities of Urbit's and Tlon's future. How does it even pay the scandalously high San Francisco costs right now? Would it really survive in case of another global financial crisis or something like it?
Do they really have 100 years of a runway? ;)
Barriers to entry and oddity for the sake of oddity
Here, a gitter chat log from 2016, when I talk about trying to learn Urbit. 3 years later, I still want to learn Hoon. Because I wasn't able to so far!
I pride myself in being able to write code in pretty much all mainstream programming languages. I was able to write NixOS derivations after about half a day of toying with it. Without fake humility – I know I'm really capable of learning. And yet 3 years later, after many attempts and reading sessions... I still don't feel like I can write anything practical in Hoon.
And it's not even that Hoon is that different. I understand (I think) the event driven, purely functional, transactional, subject-oriented nature of Hoon and Urbit.
What is tiring me out every time is mostly the really arbitrary and bizarre syntax consisting of 2-glyph keywords and 4-character random words. Only in Urbit, a function is called ... a gate. A form of selector expression... a wing. A form of structure... a door. I don't buy the whole “it's better to have an abstract name with no meaning than a one that is not perfectly accurate” argument that I've seen repeated to justify it.
When trying to learn Hoon I quickly get distracted wondering if it's all just a really sophisticated practical joke, or maybe just a dedication&IQ test to keep “unworthy” people out.
I don't even understand why Nock and Hoon are really needed. Is it really necessary for “always upgradeable computer”? Wouldn't it be possible to take something like Wasm and slap it on top of the Azimuth and the overall network architecture, and run the events through that? Does it really have to be this odd lambda/math-rooted assembler that can't even run fast without “cheating”? I don't think so, but I reserve a right to be totally wrong about it.
Even if Urbit does show practical progress soon, how fast will the adoption be if only the geekiest of the geeky can learn it? Software lives and dies by adoption and popularity. If I can't learn Hoon in a reasonable time, how many people will have enough dedication to even try?
If I had any decision powers in Urbit project, I would push for one and one thing only: abolish this stupid naming system. Urbit functions can be called functions. Heaven is not going to fall apart just because they work somewhat different than function in other languages! And it will speed up adoption by years.
Good enough is the worst enemy of perfect
This one is just a derivative of two previous points. What is preventing a group of developers to take the good ideas of Urbit, but drop the ambitious yet difficult to achieve design goals, stop messing around with weird languages, base it all on existing tech (sandboxed runtime etc.) and just “eat Urbit's lunch”? It's hard enough to lunch of novel, unfamiliar tech, but it would be almost impossible if a more familiar and accessible tech already addressed most if not all pressing issues that your tech was trying to address.
From my perspective, this is not even that bad. I am interested in Urbit, because I want a version of the Internet that is not totally insecure and broken in many important ways, in which building p2p social applications is not only practical but actually easy. I want a reliable, private and easy to use p2p computer. If something else can deliver that, I want to hear about it.
Right now I am not aware of any projects like Urbit. But I actually wouldn't mind some competition.