Urbit in 2017
I find Urbit very confusing. It uses a bespoke virtual machine for a bespoke programming language, uses a bespoke approach to optimisation, uses another bespoke programming language which compiles down to the first, has a bespoke OS written in that second language, connects these OSes into a bespoke p2p network, all in order to.... what?<p>Their go-to example seems to be social networking with an interface to Twitter??<p>I <i>absolutely</i> get the &#x27;own your data&#x2F;compute&#x27; idea.<p>I think a bespoke OS is a decent approach, as it removes a lot of legacy complexity and allows a few carefully-chosen, simple, unified approaches to things like I&#x2F;O and addressing.<p>I like the use of a functional language, as it&#x27;s an extreme form of isolation&#x2F;sandboxing&#x2F;reproducibility which makes sense in an untrusted online world. I don&#x27;t see why a new language was invented though, when something like a subset of Scheme, Joy, plain lambda calculus, etc. would suffice.<p>I have absolutely no idea why they&#x27;ve invented a custom p2p network&#x2F;addressing system. I chalk this up to huris, along with their spiel about ASCII punctuation, etc.<p>I have absolutely no idea how this has anything to do with social media. I assume it&#x27;s just for buzzword value. I don&#x27;t use social media, but I imagine programming language theory isn&#x27;t its main appeal?<p>Even if we assume that all of Urbit&#x27;s ideas pan out: interacting with Twitter seems to <i>completely undermine</i> all of it!<p>- Twitter is centralised, whilst the point of Urbit&#x27;s network is decentralisation.<p>- No matter how much elaborate language machinery you build, there&#x27;s very little you can actually <i>do</i> with Twitter, since they keep their database secret.<p>- Despite all of the sandboxing, reproducibility, etc. Twitter will not execute any code that you try to send them. The only operations which can be performed are chosen by them, and exposed as API endpoints.<p>- Doing anything with Twitter throws purity out of the window, since they only interact via I&#x2F;O requests.<p>- No amount of fanciness in OS interfaces or language semantics can do anything to prevent Twitter modifying&#x2F;deleting&#x2F;overwriting&#x2F;etc. any of their data at any time, without any notification to anyone; hence there are very few guarantees that the OS or language can actually provide about such values (e.g. there&#x27;s no referential transparency, no way to know if a cache is invalid, no way to know if someone else will receive the same data you did, etc.).<p>- Whatever the resulting API looks like, it will be a constant source of incompatibility and churn, since Twitter are free to modify their API at any time. If some operation gets dropped, any applications which rely on it may break irreparably.<p>I get that the Twitter example seems to be along the lines of a minimum viable product, but it seems like a bad choice considering that it can&#x27;t really make use of any of Urbit&#x27;s features. It could be implemented as a big string of Javascript, with Urbit only being used to get it into the browser; the result would be about as integrated as any other approach.<p>A more relevant example might be a multiplayer game with a shared leaderboard, player chat and non-critical use of external APIs (e.g. gravatar for player pics), e.g. a clone of Words With Friends or maybe something with more animation.<p>The game itself would be a decent test of the programming languages, rather than just shuttling strings in&#x2F;out of Twitter. The interactivity and chat would test the latency. The leaderboard would test shared access to data. Using external APIs would test the data-shuttling, in a way that doesn&#x27;t much affect the application if the provider shuts down the API.