Hacker News new | ask | show | jobs
by wille92 3645 days ago
Can someone give a synopsis of Urbit? Every time Urbit comes up, I skim their website but get pretty lost in marketing-speak. I see a lot of "control your data", "digital freedom", and "general purpose computing" without any short, to the point explanation of what the heck it's all about.
11 comments

Animats has a great way to describe it ( https://news.ycombinator.com/item?id=11820643)

It has the cult-like approach of Xanadu - use new terminology, tie it to an economic model, and re-invent everything. Also, there seems to be a cult leader.

Jargon: noun (data), nock (interpreter), mint (compiler), span (type), twig (expression), gate (function), mold (constructor), core (object), mark (protocol). It's Newspeak for programmers.

The overall concept seems to be a federated social system, like Diaspora. Everybody has a online presence which they own. But you can take your ball and go home, moving your online presence somewhere else, and it still gets found by others. Somehow. (That's a hard problem at scale.)

There's a claim that nobody can create vast numbers of identities for spam purposes because there are only 2^32 possible human identities. (That number should have been at least as big as the population of the planet. 2^36, maybe.) Apparently you have to buy address space, which is a profit center for somebody.

There's a download, which gets you their "OS" (which runs on top of another OS), an interpreter for their Hoon language and access to their chat environment.

Not sure what to think of this, but someone put in a lot of work.

Re: the jargon, there's a technical reason for it. Urbit atoms—which are the Nock runtime's only non-product "type"—are a lot of things, but they're basically a union-type between a bit-string and a bignum (i.e. a way to talk about a set of packed bits and an arbitrary-length number interchangeably.)

Bignums themselves are somewhat expensive data structures to pass around, so runtimes that use them usually don't use them for everything; instead, they have an Integer type that has Bignum (data-structure on the stack, or pointer to data structure on the heap) and Fixnum (regular integer machine-register) implementations, and write a glue layer to treat the two interchangeably.

So, you've got a runtime where your only "type" is an integer, but it breaks down into "cheap integers" and "expensive integers."

Now, in most dynamic-language runtimes (i.e. runtimes where type-tagging and pattern-matching doesn't all happen at compile-time), you want a type that "represents itself" to use for type-tagging, dictionary keys, function references, etc. This is usually a Symbol or Interned String (or Atom!) type, with the runtime keeping a symbol table mapping fixnums ('cheap integers') to strings (which are effectively, in Nock, 'expensive integers'). You need this table, because dynamic language functions manipulate/build/pass around/compare a lot of symbols, and the interpreter would be really slow if you were passing and comparing 'expensive integers' by value.

But Nock can't really keep a symbol-table, because every "atom" ID embedded in a Nock program is a universal ID, a handle any other Nock runtime might be passed and attempt to manipulate. (And you can't even use a global symbol-table that uses hashing—i.e. a DHT—because Nock doesn't differentiate the "Symbol" atoms from any other atoms, so you'd have to treat every atom the same and hash them all—and, even pretending that's cheap, you're eventually going to get collisions that way.) The only symbol table that works in a globally-distributed system is one that maps bitstrings to themselves. And that's as good as no symbol table at all.

So what do you do when you can't make your strings ('expensive integers') into interned strings ('cheap integers')? Just use the cheap integers from the start! In Nock, this means that all the runtime-defined symbols—all the atoms in the language and the stdlib—are bitstrings that are short enough to be encoded directly as fixnums. Since Nock has the requirement of running on 32-bit machines, that means 32-bit bitstrings: four-ASCII-character strings. Thus most of the jargon.

Do note, it's not required to use four-letter names for "symbols" you manipulate in the Nock runtime; but doing otherwise means passing around 'expensive' handles instead of 'cheap' ones.

---

I find Urbit's solution here interesting—but they probably chose it for purity's sake.

I would like to contrast it to the implementation in Erlang's BEAM runtime (which also, coincidentally, has 'atoms', but where these are simply its particular symbol type):

• an atom table is kept by each "node", with no need for the atoms in each node to have identical mappings;

• atom IDs are mapped back to their original bitstrings when serializing any data structure including them, even if just for internal persistence;

• each distributed-RPC connection between nodes is stateful, keeping its own atom table (kept synchronized on both sides by additional messages) as a cache to speed up communication between nodes. This can be seen to be similar to a streaming compression algorithm's Huffman tree cache, but it's interesting to look at it as the connection being its own virtual 'node' that has this particular atom table, which both nodes are then modelling and translating to/from.

None of that strikes me as an explanation for the obtuse jargon in particular.
In summary: the runtime desires you to call things four-letter-words. So the creators have decided to make up new four-letter words for everything they have to refer to in code, rather than just, say, abbreviating perfectly good non-four-letter words.
You only covered atoms, actually. Nouns are a union between an atom and an ordered pair of nouns, which means that they shaped like binary trees. A struct of `[a b c d]` is actually laid out as `[a [b [c d]]]`
>That number should have been at least as big as the population of the planet.

Addresses can actually be up to 128-bit. I think the idea is that addresses longer than 32-bit are just assumed to be bots, but that convention would probably be changed if Urbit gets popular enough for the 32-bit limit to matter.

...if Urbit gets popular enough for the 32-bit limit to matter.

I'm trying to think of a 32-bit address space that was found to be too small... I know there was one, it's on the tip of my tongue...

That was an address space for computers, not people.
The stated reason is that Urbit addresses are for "responsible adults", and that each responsible adult will have 1 address. Each address has 96 bits worth of subordinate addresses, so you should be able to give all of your devices, dependants, etc an address.
It's Newspeak for programmers.

No, it's much uglier than Newspeak.[0]

[0]http://www.newspeaklanguage.org

I find the original blog posts [1] a really interesting read. Nowadays Urbit is indeed full of buzzwords, “your personal cloud computer” and the like. But initially, Urbit was this [2]:

> Urbit is a new programming and execution environment designed from scratch. Any resemblance to existing languages or operating systems is coincidental, cosmetic, or inevitable.

It was based on this idea: suppose that a different civilization (Martians specifically) had invented computing long before humans. Then by now they would have perfected it. What would their system look like? Urbit is an attempt to rethink computing without the bias of human research and our current intuition. At the heart of Urbit is Nock, a “functional assembly language”. Zero is intentionally used to denote “true” to defy programmer intuition.

[1]: https://moronlab.blogspot.com/2010/01/urbit-functional-progr... [2]: https://github.com/cgyarvin/urbit/blob/master/doc/book/0-int...

Zero is intentionally used to denote “true” to defy programmer intuition.

OK, that was just perverse. Except check out the latest iteration of point of sale credit card terminal keypads. "0" is Yes and "X" is no.

For unix processes, exit status zero is conventionally considered success and non-zero is failure.
Now that Urbit is not entirely vaporware any more they regret this, but reverting the decision is not worth the trouble:

https://www.reddit.com/r/urbit/comments/4okcm6/were_the_core...

There are more interesting insights in that thread about Urbit’s unorthodox decisions.

That's normal in Asia. (They swap everything in the UI when porting Playstation games over here.)
Indeed, ine may want to earch for "batsu and maru".
0 == true is also used in C error return values, where nonzero means "false" as in "did not succeed." So it's not without precedent.

It's not a terrible idea. In most types of computing there's often only one way for something to be true but N ways for it to be false.

This is really not the case.

The C language and the standard library are distinct things. C originally did not define any values at all for booleans (true / false), but later implementations did and even in the oldest C compilers (0 == 0) would evaluate to '1', which caused the most repeated lines of C preprocessor input ever written:

#define TRUE 1 #define FALSE 0

Guarded by some #ifdefs if your compiler supported that.

Some standard library functions return nonzero on error (which can be < 0 or > 0), zero on 'success' which is not the same as true, and others (annoyingly) return 1 on 'success' or 'true' (such as the isalpha function/macro).

So this is some kind of art project? I was trying to figure out why someone would actually want to use it, but maybe it is meant to be looked at and discussed instead of being used?
It definitely started out as one but--and this is one of my favorite things about programming-- it's very possible to be an art project and a... not-art project at the same time.
It's just an application server. It's a VM, it connects to other VMs, they run programs, sometimes locally, sometimes remotely, sometimes distributed.

This is all apparently very novel.

The novel bits are:

* Everything on the VM is purely functional, and inputs essentially cause transactions which can fail/succeed - the result being that it's supposedly easier to implement certain types of network protocols, specifically the ones that Ames implements

* A somewhat decent revision-controlled filesystem with push/pull/merge, static typing of files, and a built-in build system of sorts

And last but not least...

* Feudalism built into the core p2p protocol as an explicit design decision

Also, it's been under development for the better part of a decade.
So something like sandstorm with an autoscaler?
That's like saying a snowmobile is a horse on skis. This is more like a total re-implementation of computing based on a functional model and a re-implementation of networking based on a feudal/federated shared/distributed/content-addressable model.
Meh, it's a new VM and a dumb network topology. I don't know sandstorm so I'm not sure which of these you think is the horse in this analogy.
It's... uhh... art as software? Software as art?

But joking aside, about a month ago this well-articulated writeup was posted on their site: https://urbit.org/posts/overview/

There was an HN thread on it: https://news.ycombinator.com/item?id=11817721

The gist is it's some sort of distributed datastore network vaguely similar to IPFS [1], Freenet [2], but instead operates at a different level of abstraction from files. It ships with several other components, like an OS and a programming language, to flesh out that ecosystem.

[1] https://ipfs.io/#why [2] https://freenetproject.org/

My understanding is that the founder has some elitist ideas about separating and isolating the supposedly smarter people from everyone else. The opaqueness and complexity is a feature designed to keep out the riff raff.
The earliest Moldbug screeds I came across, nearly ten years ago, were accusations of elitism towards academic computer science, and he's continued espousing that view ever since, interleaved with his other political writings. An early iteration of the Urbit website was one long anti-elitist screed against the functional programming community.

A core axiom of Moldbug's philosophy is that the mathematicalization of computing is an elitist conspiracy. As an example, he thinks that the lambda calculus is intrinsically mathematical, hence elitist, whereas his own concatenative language is non-mathematical, hence non-elitist, by conforming to human nature. It's bizarre to say the least given that his proposed language has an obvious relationship to combinator calculi like SKI calculus, and you'll have to look long and hard to find anyone who thinks the SKI calculus is more intuitive than the lambda calculus.

Where "riff raff" is bots and spammers.
Interesting take: technical obscurantism as a kind of "captcha."

I'm jumping through the hoops of "Debianizing" something now, and I have to say the Debian project uses similar techniques to limit participation to the committed. The Debian packaging guidelines are very arcane and the docs are kind of scattered and the whole "experience" seems (probably unintentionally) built to keep casual "spam" out of the repo. Not necessarily a bad thing.

Oh, I misunderstood. Urbit just seems hard because it's weird. Having watched people learn the system, there are real advantages. Honestly writing documentation is just hard and we need to do a better job of it. We don't want to keep anyone out.
It's a functional (as in functional programming — immutable data, no side effects and so on) server/OS and (peer-to-peer, I think?) networking protocol, written in a dialect of APL[1] I call EOPL[0]. So far I believe there isn't any software on it besides a chat app, but the rather ambitious goal appears to be to eventually replace Unix and the TCP/IP stack.

[1] /s

[0] Extra-Obfuscated Perl-Lisp

I found this popehat article from 2013 very useful for understanding Urbit (its Pro-Urbit).

https://popehat.com/2013/12/06/nock-hoon-etc-for-non-vulcans...

FWIW, I would not assume that a Clark post means Popehat is "pro-Urbit" (to whatever extent it matters to you that a law blog might be "pro-Urbit").
May be its my lack of tact and precision, what I meant by pro-urbit, in this case was that the article was positive about urbit.
> fwiw, the clearest explanation of the point of urbit is this 5-minute talk by yarvin from 2013. (how he will actually get from point a to point asdfghjkl666 is another matter of course.) https://youtu.be/6S8JFoT6BEM

http://reddragdiva.tumblr.com/post/141832812938/argumate-all...

In one of the threads about the recent Ephemerum/DAO debacle someone explained everything in terms of Pokemons. The comment also applies here.

The real reason is probably to generate some buzz for Bitcoin, because some of the valley nouveau riche like to gamble and have long positions.