Urbit has been around for a few years and has done nothing to clear up the confusion around it. I think at this point it is safe to say that any claims of Urbit being a revolutionary form of computing are hogwash.
This is probably similar to how Scientology got started. Nobody really believes in it, but are too afraid to strongly denounce it because they don't want to be the one who "doesn't get it." So they all just go along and get sucked further along down the rabbit hole. The difference between Scientology and Urbit is that Scientology managed to rope in a few celebrities and gained some sustaining mass. If Urbit wants to make it big, they should pay Zuckerberg and Musk to evangelize it, and then everyone will be falling all over themselves to be part of it.
My main claim was that Urbit isn't revolutionary. It is really just a Unix server and programming language.
However, in an attempt to seem more sophisticated they invented new words so that nobody could figure out what it was. Urbit is purposely obtuse in their terminology, when they really could just use words that programmers already know and use. Here's some examples from the documentation you linked:
"A value in Hoon is called a noun" - or you could just call it a value.
"A gate is a Hoon function" - or you could just call it a function.
"A core has no exact equivalent in conventional languages, but the closest equivalent is an object. An object has methods; a core has functionally computed attributes (arms). An arm that produces a gate is the Hoon equivalent of a conventional method;" - or you could just say that objects in Hoon (the language) can have methods and attributes, and you would never need to invent the core/arm/gate terminology.
They try to give themselves an out by saying stuff like "Hoon has concepts like all these abstractions, but they remain false cognates." When you dig into it, the only unique things are the words. It's like children trying to come up with a code- "instead of door we'll say blorp and instead of close we'll say bleep. Now bleep the blorp before we continue inventing our code.
> "A value in Hoon is called a noun" - or you could just call it a value.
A "value" sounds like an abstract concept. A noun is one of two things: a natural number or a pair of nouns. Calling it a "value" makes it sound much more abstract than it is.
> "A core has no exact equivalent in conventional languages, but the closest equivalent is an object. An object has methods; a core has functionally computed attributes (arms). An arm that produces a gate is the Hoon equivalent of a conventional method;" - or you could just say that objects in Hoon (the language) can have methods and attributes, and you would never need to invent the core/arm/gate terminology.
A core is not an object in any meaningful sense. You can create stuff that looks like objects with them, but they're used for a lot more than that. For example, all gates/functions are cores, but there's no sense in which you'd call those "objects".
> They try to give themselves an out by saying stuff like "Hoon has concepts like all these abstractions, but they remain false cognates." When you dig into it, the only unique things are the words. It's like children trying to come up with a code- "instead of door we'll say blorp and instead of close we'll say bleep. Now bleep the blorp before we continue inventing our code.
The thing about revolutionary concepts is that their underlying principles are different than what you're used to, so if they look similar on the surface, you're lulled into thinking they're basically the same. But anyone who's put significant effort into programming in Urbit will tell you the system is fundamentally different. Not in the sense of "you could never understand what's going on here"; but rather, "we made these few different design decisions in the beginning, and that permeates everything".
For example, all gates/functions are cores, but there's no sense in which you'd call those "objects".
To me, all you're doing here is describing an object-based language in which functions are first-class. Obviously, Urbit didn't invent this concept. Its predecessors used normal names for these terms. Why does Urbit invent new ones?
We could productively stay focused on just this one example, and see if there's a better reason for Urbit to call its objects "cores" and its methods or attached functions or computed attributes "arms".
> To me, all you're doing here is describing an object-based language in which functions are first-class. Obviously, Urbit didn't invent this concept. Its predecessors used normal names for these terms. Why does Urbit invent new ones?
That's a pretty (unintentionally) misleading description of it. What is an object? An Urbit function has basically nothing that an OOP object has. No class, no inheritance, no attributes, and no methods. It's just a way of encapsulating a formula (VM assembly expression) in a way that's convenient to call with formulas. It uses the the "core" pattern because it's convenient.
"Arm" is a pretty specific term that refers to the way an "element" of a core is represented in the core. When you want to map a particular use of cores to its underlying representation in the "core" pattern, you want to be able to talk about specific data structures.
In general, Urbit errs on the sides of giving names to concepts that could only otherwise be described in multiple sentences. Most projects just don't give names to those concepts. Urbit needs better human descriptions of its concepts, but using traditional names for them would be misleading.
They absolutely do, with their own terms. Isn't an S-expression just a list? Isn't a method just a "member function", which is really just a function, which is really just a subroutine? Every language comes up with its own terms, especially for things that are a little different from previous work.
Urbit isn't trying to solve many new problems; it's trying to solve old problems in different ways. They just want to be able to talk about the constructs in their solutions.
Right, I get that. So I guess my question is: in what ways justifying new terminology are the approaches taken by Urbit different? And whether or not they're different enough from prior art to merit obscure new terms, are those differences worthwhile, or are they different for the sake of being different? Because not all of the last 30 odd years of systems and programming research was pointless.
> not all of the last 30 odd years of systems and programming research was pointless.
Indeed, which is why it's a shame our primary server OSes (Unix-likes) can't incorporate them. Urbit can.
As for what are the approaches different, there have been many words spilled over that, but here's a few examples to wit, most of which exist in one or two other systems, but aren't widely used:
- All events are transactions, down to the VM level. There's no concept of an event that left garbage around because power was cut or the machine was rebooted. You can always crash an event, making it as if it never happened.
- Single-level store. Never worry about ORM because your in-memory state never goes away (because all events are transactions).
- Persistent connections with exactly-once messaging. Disconnection is just seen as long latency.
- Strict, purely functional language with a strong type system but no Hindley-Milner (so you don't need category theory).
- Sane indentation for a functional language, known as "backstep".
- The file system is a typed revision control system, which allows intelligent diffs on types other than plain text.
Most, if not all, of these, have been described in research, but nobody's bothered to build a system with them.
HM is a type system that also gives you an algorithm to infer types without having to do the "List<Integer> foo = new ArrayList<Integer>()" dance from languages without type inference. That's it. It has nothing to do with category theory.
Optionals are also "applicative", but Haskellers used them for a long time before applicative functors became popular. A concept can support a certain way of thinking about it without everyone needing to think that way :)
Unless you and Yarvin really think there's a valid answer to the 2 Generals problem... Im sure there's a Fields medal in there if you do.
"Every major message queue in existence which provides any guarantees will market itself as at-least-once delivery. If it claims exactly-once, it’s because they are lying to your face in hopes that you will buy it or they themselves do not understand distributed systems. Either way, it’s not a good indicator."
> FLP and the Two Generals Problem are not design complexities, they are impossibility results.
Two generals, in its impossible form, isn't applicable here. For example, this proof[0] depends on the deterministic form being impossible to solve in a finite number of messages. But why would we care about doing it in a finite number of messages? By that measure, at-least-once delivery is impossible too, yet neither you nor the blogger seem to have a problem with that. The solution is easy and common: send a message, ack new messages, retry if you don't receive an ack, never ack an ack, and always ack a dupe. As long as you aren't disconnected forever, this will give you at least once delivery.
FLP only applies in the case of faulty processes. Specifically, FLP arises because the faulty process must either (1) ack the message before handling it, or (2) handle it before acking it. (1) fails if it crashes after acking before handling, causing it to forget it ever received the message (at-most-once). (2) fails if it handles the message, but doesn't persist that fact to disk, so that when the dupe is received it doesn't know it already handled it (at-least-once).
Urbit processes events transactionally (like a database), so you're guaranteed that if you received an ack it's because the other person has persisted that message or its results, and it won't forget about (i.e. they've persisted any state changes related to it). No faulty process, no problem. FLP impossibily doesn't apply.
I suggest actually learning about proposed solutions to problems rather than recalling that someone convinced you they were impossible to solve. Proofs are powerful because they're incontrovertibly true, but they only apply if their conditions are met.
But that doesn't mean we can't provide systems where, for all practical purposes, it is a guarantee.
Another way to think about it: SHA1 cannot provide a unique hash for every possible set of content - there are overlaps. This is the pigeonhole principle.
Yet, we have entire systems designed around assuming SHA1 is and will always be a unique hash for a piece of content (Git), and, for all practical purposes, it is a guarantee good enough to work despite that.
From all reference I have read, the phrase "exactly-once messaging" does not have a strict technical definition. Neither of your links define or use the exact term "exactly-once messaging". If you can point me to a definition of this specific phrase's standard terminology, I would be grateful. But, I cannot find one.
I don't understand why you address me with such a hostile tone. What have I done to deserve this? You accuse me of playing word games, but this is not my intent. I am just trying to have a conversation about the technical aspects of a system.
I want to give urbit a try. I have a planet, but last time I fired it up the latency was so bad that I wasn't having fun. I'll try again sometime.
I can even get behind runes, and I set up abbreviations in Emacs to learn their names. And generally, I like the philosophy of language where short, one syllable, old/middle English words are used in place of the less familiar Latin/Greek derived words. I don't have a problem with revising our existing vocabulary in this way.
But the attitude to type theory strikes me as anti intellectual, precisely because we get nonsense claims about Hindley Milner requiring category theory. This sort of misinformation does no good for anyone.
None whatsoever. Hindley-Milner is in fact used widely in language design because of its relatively good error messages (as well as ease of implementation). Also it really doesn't have much to do with category theory.
> A core is not an object in any meaningful sense. You can create stuff that looks like objects with them, but they're used for a lot more than that. For example, all gates/functions are cores, but there's no sense in which you'd call those "objects".
In many, many languages, a function is also an object.
The whole reason Urbit exists is that Unix + the internet is broken and needs a complete overhaul
Re: the different names, there are slight differences between gates and functions, but I agree they're not important enough to merit the change in name. But hey, it takes a purist to spend 15 years rewriting the whole stack from scratch!
So instead, I should load up Urbit, locate on a planet, spin up a garglemitz on the spitzenspeil with the hoon japing over the nock.
If you add Xenu, Body Thetans, e-meters, I think you might be on to something!
--------------------
No seriously. There are wrong things with the monolothic kernel as well as microkernels. Theyre design tradeoffs. But none of the existing, well established methods throw away the language of computing of the last 60 years. Some tech stacks may add a new type, but they are able to describe why a new classification is needed, and how it fits iin the existing model.
What Urbit is doing, is polluting the namespace by turning existing nomenclature into some sort of technofreakish cult. Up is now down. Down is now blarbbliboop. And anyone questioning the "Master" is berated and denigrated by means of 'lack of intelligence'. You all should be defending your way and means.
Because in my eyes, you all are wrong until you can start integrating standard and normal nomenclature - because it's hiding something unsavory.
Best comment so far - you put words on what disturbs me so much about Urbit. It takes the technobabble to a whole new level. I don't care if they succeed, I want no part of it.
Given my proclivities in the occult, I do indeed have to watch out for real life cults. Now, I know this document is primarily for esoteric religion, it also very much applies to cults in other senses. But there's a few that really sticks out with me.
To me, this is a damning list of reasoning that Urbit should be considered a Cult, and thusly stayed away from. The only exception I give is, is to peeling back their crypto-jargon for any new concepts of computer science we in the larger community should document, understand, and use.
Interacting with this community only leads to poisonous cult mindsets that can easily damage your mind. Beware.
1. Wisdom/Knowledge Claimed by leader(s); amount of infallibility declared or implied about decisions or doctrinal/scriptural interpretations; number and degree of unverified and/or unverifiable credentials claimed.
Go look up anyone under Curtis Yarvin. Even in the HN thread. He is "The Master", and you are just too stupid to understand his pure clear thought.
2. Wisdom/Knowledge Credited to leader(s) by members; amount of trust in decisions or doctrinal/scriptural interpretations made by leader(s); amount of hostility by members towards internal or external critics and/or towards verification efforts.
The evidence here is the appropriate HN posts, that give scorn for highlighting major issues with the language, choices in the network architecture, and choices elsewhere in Urbit as a whole. Anyone questioning anything with Urbit is either attacked, derided, ignored, or pushed aside usinng "Whataboutism".
3. Dogma: Rigidity of reality concepts taught; amount of doctrinal inflexibility or “fundamentalism;” hostility towards relativism and situationalism.
You need to Arvo the hoon into the lolwut iron branch thats in a wet case. WHAT HOW DARE YOU NOT UNDERSTAND. You're just stupid, I guess.
4. Censorship: Amount of control over members’ access to outside opinions on group, its doctrines or leader(s).
By definition, they all use Urbit to communicate. I looked in Freenode #urbit , and its something "superior" called tahc.. Yet if you look how Urbit works, any higher class user can disable sub-users' accounts. They call them stars/planets. Whatever. But your superior owners of your network block/address can censor you. And since it's federated, NOT decentralized or distributed, your id is easily blocked.
5. Isolation: Amount of effort to keep members from communicating with non-members, including family, friends and lovers.
Insert all the completely new jargon. Instead, it separates users from IT anywhere else. This is the same thing Scientology does, so people feel special and "connected" only within their clique. Of course it doesn't translate out, so it can be used as a differentiator of "Those who know".
6. Dropout Control: Intensity of efforts directed at preventing or returning dropouts.
Lockin is their way of handling this. Obviously they aren't holding guns to your head. But it's more of not wanting to cut losses because there "could" be something.
7. Grimness: Amount of disapproval concerning jokes about the group, its doctrines or its leader(s).
Mencius Moldbug / Curtis Yarvin. I need say no more.
Full disclaimer: I recently started working for Urbit, but have been involved in its community for about a year and a half now.
It pains me to see people paint the project and its people in this light. I don't know if I'm taking the bait here or playing into your cards or whatever, but I want to try and clear some things up.
> He is "The Master", and you are just too stupid to understand his pure clear thought.
Not really. He's actually been really helpful in explaining some of the decisions that were made in the past to me, and it never felt like my say in discussions regarding ongoing work didn't matter.
> Anyone questioning anything with Urbit is either attacked, derided, ignored, or pushed aside
> You're just stupid, I guess.
I don't know what communities you've been in that people just go "you're stupid" when you don't understand something. In my experience with Urbit's chat rooms (and the forums, subreddit, etc.), people are generally friendly and understanding of the struggles that come with jumping into an entirely new stack like this. We know things can be confusing, we know it's hard when you're just starting out. We're also very much ready to help, and do care about discussing concerns and criticism.
I'd be willing to go so far as to say that, right now, Urbit's community is one of the nicest on the internet, but of course that's a tough comparison.
Aside, maybe interesting: the arcane naming of the Hoon stdlib is getting rewritten to be much more sensical and easily understandable. Why? Some community members were displeased, and someone took it upon themselves to make the rewrite happen. We're happily merging that in once it's done.
> By definition, they all use Urbit to communicate.
And you can reach us without even installing Urbit on your machine. Take a look at http://urbit.org/stream/
> any higher class user can disable sub-users' accounts
"Disable" isn't the right word here. A higher class can choose to stop helping a sub-user with peer discovery and to stop providing software updates to them. But if a sub-user is not content with the service their parent is providing, and/or they feel like they were unjustly blocked, they are free to find a parent that wants to adopt them.
Using that mechanism, communities that oppose each other can cleanly separate and continue doing their own thing without any bloodshed on either side.
> not wanting to cut losses because there "could" be something.
Doesn't this apply to pretty much anything happening in the decentralization and crypto spaces right now?
> I need say no more.
Well, I've never experienced "disapproval concerning jokes about the group". We're not above joking about the weirdness of our own system, it's something we're very much aware of.
> It pains me to see people paint the project and its people in this light. I don't know if I'm taking the bait here or playing into your cards or whatever, but I want to try and clear some things up.
Indeed not. I looked at Urbit as a way to do untrusted computation spread across multiple nodes. Think of a distributed Lambda not dissimilar to that of IPFS, but for computation. I tried to give it a fair shake. However roadblocks were everywhere. I would have to throw out most of my computing knowledge and start over to even analyze it. And writing programs in Hoon is ridiculous. My current tooling - nonfunctional. It not only disregards current nomenclature, but any sort of tooling I have to develop, make, and troubleshoot.
In the end, the further I try to get the 10,000 mile view, its just a federated system with a screwy network topology. And as tptacek has noted, the base code has very strongly written "bad choices", CS-wise.
> I don't know what communities you've been in that people just go "you're stupid" when you don't understand something. In my experience with Urbit's chat rooms (and the forums, subreddit, etc.), people are generally friendly and understanding of the struggles that come with jumping into an entirely new stack like this. We know things can be confusing, we know it's hard when you're just starting out. We're also very much ready to help, and do care about discussing concerns and criticism.
My experiences with Urbit have been primary documentation (which I am told elsewhere is the last place to look ?! ), people who show up from the "woodwork" on any thread that mentions Urbit, and some very hostile conversations on the 'web primarily discussing Yarvin's statements.
And unlike libraries like JQuery or Node.js , I can use them without being "part" of the community. I import them, load them, and use them. No muss, no fuss. Whereas, Urbit's community is inexorably tied to the foreign code and systems. I cannot simply download and use it - there's tons of content that is shared within the community. In coded language of Urbit, no less.
To understand, I have to use. To use, I have to understand. Both of these are going to take a great amount of time; and the knowledge here is non-transferable.
And strangely, once people start using that language, they seem to fail to explain the fundamental principles on which they rest on. I note this as the same type of trap that esoteric and religious cults use. They fail to explain what their terms really mean - and then it is a mixture of giving up, ignoring them, anger, or derision.
> And you can reach us without even installing Urbit on your machine. Take a look at http://urbit.org/stream/
Thank you. I saw that earlier. It looks something like Disqus or IRC on a website. It's obviously done with Urbit, but alas, it still doesn't help with deciphering any of the nomenclature.
> "Disable" isn't the right word here. A higher class can choose to stop helping a sub-user with peer discovery and to stop providing software updates to them. But if a sub-user is not content with the service their parent is providing, and/or they feel like they were unjustly blocked, they are free to find a parent that wants to adopt them.
So it's not true that Tlon can't just say $user's compute node is hereby expelled? Because my initial understanding was that Yarvin implemented instead of Galaxies/Stars/Planets, it was Dukes/Generals/Earls, and his compute node was the unique role of "Prince" - with the ability to expel anyone he saw fit.
> Doesn't this apply to pretty much anything happening in the decentralization and crypto spaces right now?
Indeed.. But that's a whole other ball game there. And yes, some of the cryptocurrencies most certainly have their own very cult-like status and effects. But you and I digress. I'm only here speaking of Urbit.
Ideally, what I want is the following:
1. Provide first principles how the system works. Use standard topologies, algorithms, and other established analytical methods.
2. Disambiguate the coded words describing primitives in the language. If the VM is emulating a non-Von-Neumann architecture, discuss it!
3. Network Protocol analysis: these should be well documented and established. I'm guessing they're also written in Hoon, which means they're nigh unreadable and excludes any existing tooling.
4. Fully document and vet the mathematical principles in the implemented crypto. Because I dont trust black box systems - and yes, Hoon is most certainly "black box" for 99.99% of programmers.
I'm sure there's something in Urbit that isn't documented elsewhere, or a algorithm that the world outside Urbit hasn't seen. Im interested in seeing they get their rightful place as part of mathematical tools we all use. In that end, Urbit is a neat project.
But for the reasons I've highlighted, I believe it would be an error to put any sort of time in this system outside of a curiosity.
Please identify one concrete computing action that I cannot do with Linux/Windows/Mac that Urbit enables.
In other words, what is Urbit's "Killer Feature"? Cause I'm not seeing one.
And a runner up question: Is Urbit still heavily dependent on unreleased root node code? In other words, is this distributed computing just a load of hype covering over a overly complicated star topology?
The best way i've found to describe Urbit as a product is a decentralized, open source version of WeChat. No, nobody really cares about privacy, but I think the argument is that for the consumer there is the potential for a way better experience. If all of your data is in one place, as a consumer, you only ever need to enter it once. More interestingly, all of your apps can work together in a seamless way that's currently impossible with the current paradigm. Your maps app has ubers and lyfts driving around on it, with yelp/opentable postings on all restaurants, etc.
On the developer side, you save so much time not reimplementing identity, payments, reputation, etc., everytime. There are more reasons why Urbit is better for developers, but I won't go into them here. Checkout the whitepaper...it's a little dense, but there is logic there:
Now, to your question. WeChat won at chat and once they owned communication / identity, it was fairly easy to move into payments and everything else. Urbit has a classic chicken & egg problem: its tech is designed to be better at doing everything for everybody. The current stack is already much more robust and better suited than urbit for most if not all one-off 'killer apps.'
So, you're right, they need to find the first killer app, equivalent to WeChat's 'chat'. I've been following the project for years, and the answer to this question has eluded me. However, recently, I finally heard the first solution which felt like the completely right solution to me, and I believe they're pursuing it.
Yes, some of the language is pompous and unnecessarily 'verbose'(being generous). Yes, they could do a better job explaining the problem in laymen's terms. However, I can tell you that the people behind this project are very intelligent and very serious. And, of course a little crazy..but you have to be a little bit to attempt something on this magnitude...right?
> Is Urbit still heavily dependent on unreleased root node code? In other words, is this distributed computing just a load of hype covering over a overly complicated star topology?
Urbit has always been fully open source as far as I know (at least since 2013). It is true that Tlon runs some of the galaxies and stars that most people use, but that's just because other galaxy owners haven't decided it's worth it to do so (because Tlon is doing a great job of it).
So, there are absolutely no "Killer Features" then? That was my primary question, which you refused to answer.
That's what I suspected.
Edit: Quote from your post-- "However, recently, I finally heard the first solution which felt like the completely right solution to me, and I believe they're pursuing it."
This is probably similar to how Scientology got started. Nobody really believes in it, but are too afraid to strongly denounce it because they don't want to be the one who "doesn't get it." So they all just go along and get sucked further along down the rabbit hole. The difference between Scientology and Urbit is that Scientology managed to rope in a few celebrities and gained some sustaining mass. If Urbit wants to make it big, they should pay Zuckerberg and Musk to evangelize it, and then everyone will be falling all over themselves to be part of it.