Hacker News Reader

Comment by pfych | Hacker News Reader

Glad to see a bit of conversation here about Urbit and competitors. I had a brief go at Urbit, running it on my server and interacting with the community. While it was an interesting take on networking and when it worked it worked great, when it didn't work, it was a fucking nightmare to fix, my planet is still stuck after an update and I inevitably gave up.

I'm glad to see Plunder having another go at the ideas Urbit had, some of it was really interesting and it'll be cool to see how these ex-devs run with it.

View on HN

I am biased with my own opinion of Urbit, as I’ve been visited by similar muses desiring similar results. Urbit to me today in its path and form resemble an ontological existential crisis resembling sleight of hand resulting in incompatible execution with what the vision was. It probably did not help to have the visionary spirit literally lost due to various reasons one may argue to various character issues.

The idea of Urbit is very interesting, the initial older premise was sound. The current execution is a fallacy of its own goals. It does not replace computing. It does not even proxy it. It literally is built on top of everything else which it directly against the impetus of the project in the first place.

A total new way to solve computation with no baggage was a great vision; especially one that was a sort of Maxwell’s minimally defined set of functions that represent computing forever and ever in the most reducible form. The ideas still have legs. The project doesn’t. It forked into a territory that is unable to fix itself. It would have to abandon all “jets” and all bs cryptohype nuisance as well.

Love the original design.

I ditto a lot of the opinions stated here. The vision of redesigning computing and networking was novel. But as a developer, when I started diving into it and writing code to interact with it, I started to see all the cracks. Its a shame.

> especially one that was a sort of Maxwell’s minimally defined set of functions that represent computing forever and ever in the most reducible form.

Can you elaborate?

Not OP, and I don't understand Urbit particularly well, but I think this part of the doc is the salient feature:

> The data model of Nock is the noun (*), which is either a natural number (@, called an "atom") or a pair of nouns

> The noun is famously simple; it competes with the list as the simplest possible recursive datatype

All code and all data is like that. So to me it's basically a Lisp-y networked operating system.

This also makes it very inefficient, which the doc explains. But the idea is to build everything on top of the most minimal axioms, which never change.

This just describes Lisp (itself a materialization of the lambda calculus, which is your "Maxwell equations of computing")?!

It specifically refuted lambda calculus as both minimal and rigorous due to the stipulation of code as data vs data as code. Nouns also being more general than lists.

sort of, in theory, but in most practical lisp/scheme implementations, certain values are opaque primitives. often functions are opaque. hashmaps, etc, are often primitives which don't have a "dependable formal representation". this means they cannot be e.g. serialized and coherently transmitted between processes.

Urbit solved this with nouns, which is arguably a substantial innovation. PLAN (in the author's view, which I find convincing) improves on this: https://git.sr.ht/~plan/plunder/tree/master/item/doc/PLAN.md

This looks really weird to me. I very much doubt this can be made into something practically useful.

Have you seen Unison[1]?

Unison seems like a much more interesting approach to making functions "serializable" and functional programming acquiring distributed capabilities almost transparently.

[1] https://www.unisonweb.org/

Hashed computations including functions distributed over something like DHT is a great concept with a lot of potential for a new form of computation.

I can’t find the doc or post but it’s old. It’s 10 lines of code that resemble all ops you need for computation. Pseudo code but it refers to itself in an interesting Quine way.

http://moronlab.blogspot.com/2010/01/urbit-functional-progra... Isn’t the link I was looking for but I think it’s the blog.

See here https://news.ycombinator.com/item?id=37061786

Hmm ... I haven't looked at Urbit in years, but this doc was pretty well written -- and it makes me curious about a Unix-y and loosely coupled version of the system.

It always seemed a big no-no to couple the VM and OS to the language. Language diversity is a good thing.

What would it take to build something with the interesting properties of Urbit on a more normal, not-purposefully-obscure stack?

As far as I understand, Guix has deterministically built the whole ecosystem from a 357 byte bootstrap

https://guix.gnu.org/en/blog/2023/the-full-source-bootstrap-...

OK so now you have, C compilers, Python, JavaScript, etc.

---

Now what do you need to do to Linux? Do you need to get rid of time() and rand() ? (Not sure if Urbit is functional like that)

---

What about the networking? The whole network has a single state?

So is this like if you had all of these separate Linux systems all writing to one big distributed git repository or something? I never really understood how the networking is done.

---

This leaves the identity parts; I would also leave out the crypto parts too ...

But as far as language / OS / networking, I'm sorta interested in what a "conventional" system of this type would look like. I actually think it has some practical applications for some kind of functional distro like Guix (since these distros all become networked systems eventually -- they are not really single-machine systems)

I also wonder if this already exists -- are there "non-obscure" and "non-ideological" systems like this? When you add some language diversity, it becomes more interesting to me.

yeah, Urbit seems to be an uncredited crib of the original Nix paper https://reddragdiva.tumblr.com/post/724590682207141888/so-it...

Nix was novel because it brought reproducibility, immutability, etc. to a real system running on Linux -- but if you don't have the Linux constraint, then the ideas go back MUCH further

And Nix is a package manager / build system, while Urbit is more of a "distributed Lisp OS", with networking and identity

Or at least, I'd like to read a post that's not so clearly driven by personal animosity :-P

---

FWIW I briefly worked on Google's Bazel in ~2006, and all the Nix ideas were there, but nobody referenced Nix. They referenced Vesta (and other systems):

https://en.wikipedia.org/wiki/Vesta_(software_configuration_...

from 1993. Bazel is way faster and more distributed than Nix, probably because it's just had much more engineering effort behind it.

Urbit (also a real system running on Linux) is an obfuscated implementation of a lot of ideas going back to Lisp machines - but it seems proximately to be a Nix crib.

The key point is really that Urbit is not a fount of hitherto unknown novelty, however Yarvin paints it (2010):

> So we have the Urbit problem: a frozen, universal, static functional namespace. In other words: a standard static functional namespace. Perhaps we are getting further into the rocket-science department. It is not hard to write a functional namespace. But how can we standardize a functional namespace? You will search the RFC Editor's shelves in vain for anything even remotely like Urbit.

http://moronlab.blogspot.com/2010/01/urbit-functional-progra...

As you note, this claim of novelty is nonsense.

New basic computing primitives are like punk rock bands: the first few are fresh and exciting, the ten thousandth is … not. Turing machines and Lisp were new and interesting, Urbit is Yarvin’s favourite toy language.

Urbit does well-understood things, badly.

To be clear, I was asking for a distillation of the novel parts of Urbit, without all the obscurantism (and I do think there is novelty; the Plunder project seems to be evidence of that)

I don't agree with the post that says it's a derivative of Nix. Nix is interesting, and there are some common ideas, but it doesn't make any sense to say Urbit derives from it

The 2010 post cites Arc and VPRI as other "software from scratch" efforts

What other "software from scratch" efforts have extended into the realm of networking?

Nix/Guix don't tackle that problem or claim to -- e.g. it doesn't make sense to write a chat app "running in" Nix/Guix because they are package managers, not OSes. The OS is Linux; the networking stack is the Internet.

---

It's also an open question how self-hosted Urbit really is though ... if there's not an instantiation of it that's outside of Unix/Windows/the Internet, then I would say it falls short of "software from scratch". Also, it seems like the current dev process leans heavily on cloud software; it's not really self-hosted or self-sustaining.

Is it really a computer, or is it an app running inside existing computers?

The uxn system that's gotten a bunch of attention on HN is interesting because it does run on hardware, divorced from Unix/Windows - https://100r.co/site/uxn.html (but it also doesn't tackle networking)

It literally is built on top of everything else which it directly against the impetus of the project in the first place.

This is a critique that boils down to "they haven't achieved their actual goal in full yet".

What do you want? They have to start somewhere, and when you are reimagining an existing system from the ground up, there will necessarily be usage of existing tools even if your goal is to eventually supplant them. The whole point of something like jets is because you have to interact with what exists right here right now, at least with this there is a bright line between the new stuff (running purely in a nock/hoon VM), the bridge code, and the runtime for what ever operating system.

The fact that something like https://github.com/mopfel-winrux/NockPU (nock in hardware) is even possible is amazing.

My point was that it is ontologically opposed to its purpose and inception. It was on track and sent off the rails. It required a start, it changed its direction, and is no longer the same project in spirit. Urbit as the original idea which was not supposed to change has changed and more specifically Tlon is responsible for the change of direction which they’ve even forked into multiple teams now.

There existed at some point progress towards the vision of Urbit, and as of now it is so far beyond that scope it has retreated from a static namespace of computational vapor ware into perpetual “non-maxwellian” ever-growing “ball of mud” bolted onto the status-quo of today with ever increasing complexity.

\(-.-)/

Reply on news.ycombinator.com