FRESH

Hacker News

Show HN: A Lisp where each function call runs a Docker container

82 points by a11ce

by codethief

2 subcomments

People here are laughing of course but I do think there is a deeper truth behind this that's worth exploring:
> 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.

by lioeters

0 subcomment

by teaearlgraycold

1 subcomments

I'm impressed GitHub managed to handle this beast:
https://github.com/a11ce/docker-lisp/actions/runs/2216831271...
500+ container invocations to compute factorial(3)

by piloto_ciego

3 subcomments

by waldrews

1 subcomments

well, 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....

by Nevermark

0 subcomment

Ah, the ultimate stack. The long sought for, and long waited for, final decoupling of function from efficiency from performance from environment from task completion.

by networked

0 subcomment

This is fun. The author may like https://skarnet.org/software/execline/ (can be containerized the same way?), https://github.com/darius/awklisp, and https://github.com/libriscv/libriscv + https://github.com/libriscv/libloong.

by nonameiguess

1 subcomments

I get that it's a shitpost, but if you want to take this at all seriously, a Linux container is just a Linux process in its own namespaces separate from the namespaces of its parent or at least separate from PID 1. If you're not actually doing anything requiring OCI bases and layering, as in, like any other sane program, all your functions have the same dependencies, spawn everything in the same mount namespaces at least and just use the host. Then you don't need to mount the docker socket recursively, you don't need docker or a socket at all. This isn't really as crazy as developers think it is because they think containers in Linux are just docker. You can make system calls from within the Lisp runtime itself, including unshare, and bam, you've got a container per function call without needing to shell out and accept all the overhead of a separate container runtime.
Also why are the image builds hard-coded for amd64? Are you really doing anything here that can't be done on arm?

by Pay08

0 subcomment

My first thought was a simple wrapper macro, but this is way more impressive and way more fun.

by Shorel

0 subcomment

by poppingtonic

0 subcomment

by andreamonaco

0 subcomment

by the_harpia_io

0 subcomment

honestly the isolation here is kind of interesting. each call gets a clean env - no shared state, no "function A leaked into B's heap" bugs. pure functions taken to the logical extreme.
cgi was mocked for fork-per-request. lambda said sure, vm-per-invocation. this is just the next step down that road

by nxobject

0 subcomment