The Universal Design | Hacker News Reader

The Universal Design

christine.website

35 pointsxena5 comments

Xena is right to note that this simple state-transformation function, f(event old-state) -> [actions new-state], is the obvious and eternal way to build a server. It's also worth noting that it's basically Haskell's State monad.

Whatever you call it, it's a design pattern, not a system service. Urbit on the outside, as an "operating function," is defined by the "universal design." But since it's a pattern rather than a service, it will tend to reappear at each layer of a layered system. Urbit on the outside uses this pattern and so do Urbit applications, but these are very different layers of Urbit.

At the application layer, a command to an IRC daemon is a great example. There still seems to be a good deal of boilerplate in the Lua code presented here. The attraction of the "universal design" is the goal of eliminating all, or almost all, boilerplate code in a network server daemon.

How would one go about that? First, be a single-level store, so the daemon is automatically a database. Second, make application messages are transactions with end-to-end acknowledgment, no return value, and exactly-once delivery. The message is automatically deserialized and validated, and passed to the application as a simple typed argument. If there's a problem with the operation, just crash; the result is delivered as a transaction failure with an annotated stack trace. Also, messages should be sent over an encrypted P2P network and authenticated by scarce, memorable identities...

On the other hand, I'm sure the Lua daemon is a lot faster!

(Event, State) -> (Actions, NewState) is indeed how Erlang/OTP applications and components have been structured for the last 20 years! Concrete existence proof.

>This design will also scale to running across multiple servers, and in general to any kind of computer, business or industry problem.

If I understand what you're getting at, you're saying that locking is the solution to all concurrency problems? This section is the most interesting to me, as I've been researching concurrency at a high level lately. I'm a little confused by your conclusion. It seems naïve to claim that multiple hosts can agree on what action to take "just" by using locks. What if a peer is holding a lock and becomes unreachable? What if the peer isn't dead and thinks it still has the lock? What if the core that is issuing the locks becomes unreachable?

I didn't see anything really interesting in there about concurrency or consensus beyond the naive. What she does talk about is almost a microservices pattern though, and that can be an awesome tool for solving certain kinds of problems. I don't think I agree that it's more useful than other tools across all problems though.

Beware a typo in this code: search for "mepliles". Unsurprisingly, the error is in an error handler, so it was assuredly never hit. This kind of thing has started making me yearn for type safety and static compilation.

Reply on news.ycombinator.com