Show HN: A Lisp where each function call runs a Docker container
11–20 of 30 posts
Re: Show HN: A Lisp where each function call runs a Docker container
#12I'm impressed GitHub managed to handle this beast: https://github.com/a11ce/docker-lisp/actions/runs/2216831271... 500+ container invocations to compute factorial(3)
Re: Show HN: A Lisp where each function call runs a Docker container
#13well, sure, that uses a large number of processing cycles for each small operation. But asking a frontier LLM to evaluate a lisp expression is more or less on the same scale (interesting empirical question whether it's more or less). And, if we count operations at the brain neuron level it would take to evaluate one mentally....
Re: Show HN: A Lisp where each function call runs a Docker container
#14well, sure, that uses a large number of processing cycles for each small operation. But asking a frontier LLM to evaluate a lisp expression is more or less on the same scale (interesting empirical question whether it's more or less). And, if we count operations at the brain neuron level it would take to evaluate one mentally....
I'm sure in the future there will be technology to evaluate simple Lisp expressions in only milliseconds of time, spending mere joules of energy.
Re: Show HN: A Lisp where each function call runs a Docker container
#15This is the most ridiculous thing I've ever seen and I love it.
Re: Show HN: A Lisp where each function call runs a Docker container
#16Re: Show HN: A Lisp where each function call runs a Docker container
#17Also why are the image builds hard-coded for amd64? Are you really doing anything here that can't be done on arm?
Re: Show HN: A Lisp where each function call runs a Docker container
#18> A Docker image is a piece of executable code that produces some output given some input.
The ideas behind containerization and sandboxing are rather closely related to functional programming and controlling side effects. If binaries always only read stdin and wrote to stdout, we wouldn't need sandboxes – they would be pure functions.
In the real world, though, binaries usually have side effects and I really wish we could control those in a more fine-grained manner. Ideally, binaries couldn't just do anything by default but actually had to declare all their side effects (i.e. accessing env variables, config, state, cache, logs, DBUS/Xserver/Wayland sockets, user data, shared libraries, system state, …), so that I could easily put them in a sandbox that's tailored to them.
Conversely, I'm waiting for the day when algebraic effects are so common in programming languages that I can safely execute an untrusted JavaScript function because I have tight control over what side effects it can trigger.