What is this, conceptual art?
/s
Show HN: A Lisp where each function call runs a Docker container
21–30 of 30 posts
Re: Show HN: A Lisp where each function call runs a Docker container
#22People 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 – th…
I too really want algebraic effects but the majority are panicans and exceptionauts. PL's will always cater to majority. We still don't have proper tail calls because the luddites want stack metaphors. Javanese & Gophers can't conceive of a world of pattern matching, sum types, and null/nil-safe code. Now we have machines writing code for us. It's over.
Re: Show HN: A Lisp where each function call runs a Docker container
#23Re: Show HN: A Lisp where each function call runs a Docker container
#24I 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 l…
This loses the "feature" of being able to write builtins in different languages/operating systems/whatever. Either way, I think a serious version of this would use threads. Concurrency is the real potential benefit imo.
I was getting warnings without that line and don't know how else to fix it (this is my first time using Docker). A PR would be welcome if there's a better way.
Re: Show HN: A Lisp where each function call runs a Docker container
#25People 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 – th…
I'm sure that would work just like how phone apps asking for permission to do each thing has resulted in no phone user ever getting pwned and doxxed by their apps - phone apps are completely safe now, yay!
Re: Show HN: A Lisp where each function call runs a Docker container
#26People 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 – th…
I'm sure that would work just like how phone apps asking for permission to do each thing has resulted in no phone user ever getting pwned and doxxed by their apps - phone apps are completely safe now, yay!
I think we're talking about fundamentally different things. :) You're talking about the UX of granting permissions, I'm talking about how permissions get implemented at the technical level, irrespective of how you arrived at them.
Surely your proposed solution is not "Don't implement a permission system to begin with"?
Re: Show HN: A Lisp where each function call runs a Docker container
#27Re: Show HN: A Lisp where each function call runs a Docker container
#28Earlier quoted context omitted.
I'm sure that would work just like how phone apps asking for permission to do each thing has resulted in no phone user ever getting pwned and doxxed by their apps - phone apps are completely safe now, yay!
I think we're talking about fundamentally different things. :) You're talking about the UX of granting permissions, I'm talking about how permissions get implemented at the technical level, irrespective of how you arrived at them. Surely your proposed solution is not "Don't implement a permission system to begin with"?
Sorry about the sarcasm in my reply.
I guess what I am saying is at the end of the day you need the program to do the thing. Whatever mutation it needs to do to accomplish the task, that's what you're going to allow. That's exactly what happens with phone app permissions. Everybody just lets Facebook use their microphone (not me of course, but most people).
What you describe would be super cool though. If every program let you know ahead of time what it was going to try to read and write in the world. That does indeed sound useful!
Re: Show HN: A Lisp where each function call runs a Docker container
#29Ah, the ultimate stack. The long sought for, and long waited for, final decoupling of function from efficiency from performance from environment from task completion.
Re: Show HN: A Lisp where each function call runs a Docker container
#30I'm impressed GitHub managed to handle this beast: https://github.com/a11ce/docker-lisp/actions/runs/2216831271... 500+ container invocations to compute factorial(3)
Why, I bet it could factor 15 or 21 better than the latest quantum computers!