Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Interactive Distributed systems are only slow if you command them to do things sequentially and wait for a round trip.

If you send the computation plan with the initial input request, they can be fast.

We can also program distributed systems to run a switch statement after each response. A state machine for every response. What if you could coordinate a computer to do things depending on result? And you can do this similar to Capnproto promise pipelining?

With promise pipelining you can say what operations you want to do when the operation completes against the output of the response from the server.

One of my ideas is the thought puzzle of extremely high performance computer with high latency.

You design sessions which decide what to do and what to do given what output. Then the computer automatically follows the sequence of commands depending on the output of the remote system.

I see it as chaining together promises that are typed. Imagine an advanced option Monad that captures every possible output state and let's you pattern match it.

When you next create a change for your CI system which needs to build a docker image, upload, prepare a Kubernetes manifest, run a data migration, run a redacted data import you can use this architecture.

Admittedly we need an elegant GUI for queuing responses of servers.

My idea was GUI thunking that is inspired by Haskell's thunks

https://github.com/samsquire/gui-thunks




Depends on how embarrassingly parallel (https://en.wikipedia.org/wiki/Embarrassingly_parallel) your problem is. If many individual operations depend on the results of previous operations, it'll be slow.


You are of course completely right.

How do you parallelise building a docker image, compilation, uploading to a server and deploying to Kubernetes?

I was trying to remove all round trips from the equation.


If they depend on each other, you don't. The best you can do is get all the data in the right place(s) to reduce latency and use caches to reduce duplication of effort.


The more complex the request you can make the larger the DOS attack surface is. It’s a tough problem. We need some more little languages like eBPF to send just enough conditional logic across.



I had not recalled that was Liskov's work. I do have a vague recollection of basically the same thing coming out of Microsoft Research in the late 90's, but I can't recall if that was a paper or a patent application.

Promise chaining is handy but unless the response to the first query is a naked value like an ID or a user name then you need logic to extract the 2nd question from the 1st answer, which is going to require running logic on the server and while not DDOSing yourself. There's a lot of relatively cool stuff that was done in the 80's and 90's that had not really absorbed the import of the Morris Worm.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: