💾 Archived View for jsreed5.org › log › 2021 › 202111 › 20211117-urbit-and-technological-first-impre… captured on 2023-01-29 at 03:31:59. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
---
There are many things I like about Urbit, from the communities I've seen to the project's willingness to explore esoteric technological concepts. But almost from the very beginning, one aspect of Urbit has dominated my experience with it: it is very, very buggy.
Any piece of software is going to have its fair share of glitches, quirks and even broken functionality. Code is written primarily by humans, and humans are prone to making errors. And Urbit is certainly a very complex undertaking: it aims to rebuild computing environments from the ground up. Its stack includes a virtual machine, a self-contained programming language, an interpreter, programs, a Web interface, and even connections to the Bitcoin and Ethereum blockchains. That's an awful lot of stuff to reinvent, which means an awful lot of parts to debug.
This presents a major problem when bugs do occur. Error messages are printed in terms of Urbit's programming language Hoon; if one hasn't specifically worked with Hoon before, the errors are completely opaque. Even if one can read the code that gets dumped, to have a hope of beginning to solve the problem, one must be familiar with other parts of Urbit. This includes everything from the machine code Nock, to the virtual machine Vere, to the identity system Azimuth, to the command line utility Dojo, to the networking layer Ames, and beyond.
Developers for standard languages from C to Python are ubiquitous. Tutorials can be found all over the Internet, and millions of forum posts and StachExchange questions exist to solve almost any kind of programming problem. Since Hoon is designed for Urbit alone, only developers specifically working on Urbit can help solve any problems with it. Tutorials are also sparse--some information is only found within Urbit itself. This is a big limiting factor if a bug causes a ship not to be able to boot at all.
Often the suggested remedy for problems, and sometimes the only remedy, is to perform a personal breach. This rests all networking keys for one's ship, announces the new keys to the network, and wipes all information previously stored in the ship. Not only does this lead to local data loss, but if not all networking keys are copied correctly, the ship enters an inconsistent state and can no longer boot. This exact bug happened with my own planet a few days ago.
All this creates a frustrating experience for a new Urbit user. Bugs are always going to be found in software, but new users--especially technically-minded users--need to have a thorough point of reference to sort out problems. Opacity leads to confusion and discouragement. A lack of accessible help and support forces users to rely on GitHub issues, which are slow to resolve and often situation-specific.
My ship has been offline for the past two days. I've breached five times since I got my planet last year, and it's had constant problems regardless. I think I'm going to keep my planet offline until Urbit has had a chance to sort out some of its bigger bugs, then breach one more time and hope for the best.
In the meantime, if you'd like to reach out to me via a means other than e-mail, I suggest using Tox.
---
[Last updated: 2022-11-14]