[jmull]

It good people are thinking about this problem, but this proposal doesn't address some fundamental issues. E.g,

- why developers/maintainers choose the package granularity they currently do. e.g., you can have tiny granular packages today (npm famously has single-simple-function packages, which is widely derided, BTW). Developers break down packages in a way that makes sense to them to best develop, test, maintain, and release the package. If you reduce the overhead of a small "grains" of package, developers might choose to go a little more granular, but not a lot.

- why people want or need to update. People want or need security updates. People want or need new features and functionality.

So even with this magically fully in-place (there's some tooling implied here), I don't think there would be much impact on updating.

(And people who tried to implement it or use packages that implemented it would be getting burned by version update mistakes -- this seems almost pathologically error-prone -- and when something does go wrong, it will take some new class of tool to even diagnose what went wrong where. People will end up with issues triggered by their personal upgrade path.)

BTW, patch updated don't have to be done at a source or function level at all. (e.g. upgrade from version x to x+1 could be expressed as a delta. Or x to x + 2 for that matter.) This has been popping up for decades, but it seems the practical value must not be worth the trouble because it doesn't seem to catch on in a big way.

[Joker_vD]

The really, really fundamental issue this proposal doesn't touch at all is that you also need to

- either version the data structures/classes/shapes of dictionaries/whatever that a function accepts/returns;

- or have converters between different data versions and use them inside your functions.

As I said in another topic on HN which was about that project that hoped to bring hot-code reloading in a C REPL or something: changing the code inside the running program is the least of the problems; flawlessly updating the data inside the running problem so that the new code could proceed to work on it — that's the hard problem (think e.g. about rolling back the update that threw away the bunch of fields).

[seanhunter]

Absolutely this. The edge cases are really the hard part here. As a real-world example, one of my worst ever days occurred when we essentially rolled out a routine update which changed how a date object was serialized. This had a very serious bug and needed to be rolled back. The problem was of course we "discovered" the bug when it serialized some important objects with broken dates. When we rolled back, of course the objects were still broken and also now we were on a previous version of the code that couldn't deserialize them. This included the tools that would normally be used to fix broken data so the data rollback which would normally be simple was anything but.

Unless these sorts of things are dealt with, any framework like this will just be solving the part of the problem that isn't really a problem.