no excerpts yet cause work destroyed me, but this just got posted on the orange site. apparently a couple of urbit devs realized urbit sucks actually. interestingly they correctly call out some of urbit’s worst points (like its incredibly high degree of centralization), but I get the strong feeling that this whole thing is an attempt to launder urbit’s reputation while swapping out the fascists in charge
e: I also have to point out that this is written from the insane perspective that anyone uses urbit for anything at all other than an incredibly inefficient message board and a set of interlocking crypto scams
e2: I didn’t link it initially, but the orange site thread where I found this has heated up significantly since then
There have actually been multiple attempts at doing actual computer science from a starting point of Urbit.
Here’s one I wrote up in 2017, whose proponents were so outraged at the Ethereum plan that they forked, and wrote their fork’s constitution in Lojban.
Oh hey, small world; I operated a star for that fork. However, I no longer think that Urbit’s codebase is worth reusing, and I’ve stopped participating. Instead, I developed a Hoon alternative (Cammy) and decided not to pursue Arvo compatibility.
I just want to say, as someone who’s pretty well-versed in functional programming and has a decent grasp of category theory, that wiki article is absolutely impenetrable to me. I get that it’s an esolang so the goal isn’t a broad audience, just thought I’d share my perception. It looks very cool still, and I do want to understand it.
Thanks! For an esolang, that is a compliment. Cammy does a lot of things differently, but it’s okay to just look at it as an alternative syntax for expressing diagrams. Bring your own Cartesian-closed category, etc.
how is the experience of developing for an Urbit-like ecosystem? everything I’ve seen as an outsider indicates it’s fairly painful, but from an esolang perspective I suppose the pain is the point
Not just development, but even just basic maintenance of a star is onerous. Worse, there’s no guide on how to do it: no notion of security and privacy, no data-integrity recommendations, no backups or testing, and almost no information on key management.
It’s so bad that, if you look at Cammy, you won’t see any sign of Urbit. You’ll just see a language which designates total functions, provably halting, with basic toolchains for compiling and running. No Arvo whatsoever. I did reuse the word “jet”, but I’ve provided an entire theory of jets and holes so that every Cammy jet is implementable in raw Cammy; there’s no C code.
Also, although it isn’t obvious from the esolang wiki, Cammy is designed to subvert copyright and punish folks who build up private repositories of Cammy code. I figure that if we can have fascist toolchains, then we can also have antifa toolchains.
Sorry for going NSFW, but I figure that my candor in the present will save somebody time and effort in the future.
this is really interesting! thank you for sharing; doing deep dives into urbit can be fairly mentally punishing so I appreciate the first-hand account
it sounds like nobody with experience running any kind of service in prod has had hands on urbit — the administrative bits you mentioned are all the basics you’d want to run a system at any scale, and it’s embarrassing that urbit has none of them after all these years
from what I’ve skimmed so far, Cammy is impressive! notably its wiki article explains everything in standard computer science terms (including explaining things in terms of lambda expressions, which I appreciate) and I get the impression a lot of work went into making it fairly comprehensible for an esolang (as opposed to Urbit, with the opposite goal). I’ll definitely take a closer look at this later tonight, as having a reference “hoon’s non-evil little brother” is definitely useful for understanding Urbit by contrast
there really should be more antifa software licenses in the world. I’ve been exploring options myself to represent similar ideas in the code I release