Hacker News Reader

Comment by VikingCoder | Hacker News Reader

I've thought about similar stuff, but I'm on a slightly different path.

I'm picturing a long-running server, and people wanting to run experiments on it. Like, the next time an HTTP GET comes in, please use my new code.

In my head, I had imagined that there would be a versioned method table for each function (or at least each function that I wanted to be versionable.) I would compile my new version of the code, and then dynamically link it in, and then use some experimentation flag to say which version of the system the execution should follow.

So, it's a bit like Git. Each object is versioned, and you can request a snapshot of the entire tree, at a particular version. And because you can walk the tree of function calls, you can have a root version, etc.

It's super cool to see people experimenting with this.

View on HN

Erlang has it built-in, or you can roll it manually, like in [0]. But the biggest problem is not changing the code, it's changing the layout of already existing data — throwing it away is equivalent to killing the process and starting it from scratch. It can't be done automatically, you, as a programmer, must supply an upgrader (and downgrader, for rollbacks) written manually by yourself.

[0] https://joearms.github.io/published/2013-11-21-My-favorite-e...

Sure, I get that - which is why I'm thinking about the HTTP GET scenario, because each Request is almost entirely stateless on entry. Sure, it builds up state, but that could all be in an Arena with the scope of the Request.

What state builds up on an HTTP GEat that isn’t bound to the servicing call stack?

If you're dynamically building a page, you'll have state while you're building and rendering it. SQL queries, etc.

Isn't this what rolling updates in container-based deployment systems (e.g., Kubernetes) do? And also the reason we have CI/CD pipelines and micro-services (to decouple processing from data).

So basically, in your example, change the code that handles GET and then trigger the CI/CD. Your code will be compiled, containerised then a rolling update is started to replace the old version of the running web server with the new one.

What you're describing works great if the server is running at head.

I'd like the server to be able to execute a code path which mimics my Git branch, and on the next request to execute a code path which mimics your Git branch.

If you and I have two different versions of f(), I'd like them both to be available to be executed, based on some flag or condition.

As we merge our branches, f() will collapse back into the CI/CD pipeline you imagine, yes.

You might have a look at Java's JMX and how it integrates with things like Spring, Tomcat, etc. It's pretty close to what you're describing, where you could have runtime configurable dynamic behavior and a framework to manage it.

Redbean (part of the often discussed comopolitan c library) does something like that.

I feel like this is rebuilding erlang in some aspects? Erlang has hot module replacement

Reply on news.ycombinator.com