Ask HN: Composing programs from global function registry – is it viable?
3 comments
Could that be implemented as a subset with a little bit of metadata of e.g. go packages?
They can be limited to a single function, there is a quasi naming standard via git URIs, and mod.sum contains hashes, albeit locally, but there is a beta for a public database https://sum.golang.org.
They can be limited to a single function, there is a quasi naming standard via git URIs, and mod.sum contains hashes, albeit locally, but there is a beta for a public database https://sum.golang.org.
Yeah, the idea is to reduce distribution unit to single function, you could technically do that with any language, some are just better fit I guess.
Ah, ok. I guess with the solution I had in mind you could not simply replace a function without recompiling. So an interpreted language might be better suited.
- have a globally available (s3, cdn and whatnot) registry of functions
- each function is a tuple (name, dependencies, arity/spec/something about types, source, compiled bytecode)
- functions are referenced loosely by name and strictly by sha of that tuple directly in the code
Why would anyone do that?
- you no longer have to deal with dependencies - they are inferred from functions you reference/require in your code
- your build process becomes simpler and faster - dependencies are all pulled at boot time (or constructed locally at deployment site) from the registry
- your deployment becomes much more granular - down to single function that can be swapped during runtime if the language is right (erlang, clojure, anything that's functional and dynamic enough?), can't get any closer to zero downtime deployments without hassle
- when bug is found in one of the functions or a change is needed for any other reason, a new function gets published in the registry and it has new sha - amazing for discovering vulnerabilities, auditing and having reproducible builds
now tell me that this has been around since 50s and why it can't work.