
Ask HN: Composing programs from global function registry – is it viable? - keymone
Here&#x27;s a rough idea:<p>- have a globally available (s3, cdn and whatnot) registry of functions<p>- each function is a tuple (name, dependencies, arity&#x2F;spec&#x2F;something about types, source, compiled bytecode)<p>- functions are referenced loosely by name and strictly by sha of that tuple directly in the code<p>Why would anyone do that?<p>- you no longer have to deal with dependencies - they are inferred from functions you reference&#x2F;require in  your code<p>- your build process becomes simpler and faster - dependencies are all pulled at boot time (or constructed locally at deployment site) from the registry<p>- 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&#x27;s functional and dynamic enough?), can&#x27;t get any  closer to zero downtime deployments without hassle<p>- 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<p>now tell me that this has been around since 50s and why it can&#x27;t work.
======
jraedisch
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](https://sum.golang.org).

~~~
keymone
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.

~~~
jraedisch
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.

