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.
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.
None of these make use of monads or anything rooted in category theory.
https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_sy...
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.
Bullshit.
https://groups.csail.mit.edu/tds/papers/Lynch/jacm85.pdf
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."
~ http://bravenewgeek.com/you-cannot-have-exactly-once-deliver...
This is A) not an impressive problem to solve, and B) not actually a problem in Haskell or Elm.
