1. 8

  2. 5

    This seems adjacent to, if not a reinvention of, the way we handle hot upgrades and code writing in Erlang OTP gen_servers.

    1. 2

      I had a very similar thought, but coming from Elixir, it seems even more obvious to me from that direction. Lots of folks have been reinventing OTP, however. I wonder if this has been studied as some sort of feature convergence.

    2. 2

      This part is interesting:

      In terms of deployed code on Earth, the split is about 90% imperative, 5% monadic, and 5% state machine. In Urbit, the split is about 90% state machine and 10% monadic. This is what I intend to explain and defend.

      Also I liked this from their “precepts” (https://urbit.org/blog/precepts/):

      Data is better than code. Stateless is better than stateful. Explicit state is better than implicit state.

      It seems like the language is unnecessarily obscure, but there are some good ideas underneath the syntax. It seems to be based on a good balance of informal and mathematical reasoning for correctness.

      1. 2

        I think this is the first time I’ve read something about Urbit that wasn’t shrouded in esoteric terms, and it actually taught me a thing or two as well.

        1. 1

          The “imperative”, “monadic”, “state machine” split is cute. Under this distinction, languages in the E family have only state-machine I/O, so I suspect that it is not fine-grained enough to say useful things about all languages. I’m also a little surprised that the author would draw this distinction, and then argue that typical complex systems are composed of a mix; is this distinction meant to help us categorize languages, or is it a critique of programming style? The reason why I dislike Python and C for I/O is not because we can build monads or state machines in those languages, but because we are forced to rely on “imperative” blocking I/O at the bottom of every abstraction.

          There are two kinds of state machines, and only one is covered here (Moore machines); the other kind, Mealy machines, have private state which mutates as data arrives. One of the difficulties of Hoon’s style is that mutation is itself an effect, and there’s something of an infinite regress when we imagine how to serialize a running Hoon process itself to disk.

          Edit: I had some fridge logic. Both Mealy and Moore machines each give a monad. Moore machines give the identity monad, but Mealy machines give the state-passing monad. Additionally, the flow of data under I/O actions gives an implicit free monad which reflects how data is being passed around. So what, exactly, is the difference between monadic and state-machine I/O? I’m not sure that there is one!

          Note that the Upgrade Problem is not quite tackled here; the object to be upgraded is explicitly identified and the schema changes are fully programmer-specified, which makes things quite a bit easier.