Hacker News Reader

Comment by bsder | Hacker News Reader

I strongly disagree that we learned much of anything.

For example: hot upgrading. The fact that an Erlang process can tail call itself means that you can swap in a new process with the same signature at the tail call of the old process. Nobody else does this that I know of.

I can go on further. The whole set of behaviors encoded by the OTP libraries is also something that nobody else seems to do. Erlang's bit syntax is possibly the best out there even today.

I guess pattern matching finally made it to other languages. I would think that's probably about it from Erlang (pattern matching isn't exclusive to Erlang but it was one of the earlier languages with it).

None of the other programming languages seem to have learned much of anything from Erlang--and that's kind of sad.

View on HN

> For example: hot upgrading. The fact that an Erlang process can tail call itself means that you can swap in a new process with the same signature at the tail call of the old process. Nobody else does this that I know of

common lisp is in a league of its own when it comes to hot reloading and debugging

Question is if Common Lisp got the idea from Erlang, or vice-versa. Common Lisp first appeared in 1984 while Erlang appeared in 1986. If so, the original point of "None of the other programming languages seem to have learned much of anything from Erlang" might remain accurate.

In the 70s Ericsson programmed their telephone switches in a proprietary language called PLEX. It had hot code swapping, so when Joe Armstrong started working on Erlang to replace PLEX in the 80s this was a requirement. Dropping a few thousands of calls just to do an update simply wasn't an option.

On the other hand, even the first versions of lisps (as far as I can gather at least) had `eval`, meaning a running program could accept external output and update itself. And this was in the 60s.

The question remains :)

Lisp would also be able to compile code to assembler, run an assembler and load the generated code into the runtime.

I would think (without knowing too much about Erlang's mechanisms) that the mechanisms of Erlang are quite different from what a Lisp runtime typically does. The Lisp runtime is just one process. Erlang is concerned with multiple processes, which are strongly isolated.

Hot upgrading is not a good example. There are infinity ways to do accomplish the same in other ecosystems, a very common example: Upgrade nginx live and without dropping any connections.

Anyhow, instead of bolting that on to your project reinventing those patterns for the millionth time you can just adhere to ̶the c̶o̶n̶j̶o̶i̶n̶e̶d̶ ̶t̶r̶i̶a̶n̶g̶l̶e̶s̶ ̶o̶f̶ ̶s̶u̶c̶c̶e̶s̶s̶ the tenants of 12 factor apps: https://12factor.net/disposability

> None of the other programming languages seem to have learned much of anything from Erlang--and that's kind of sad.

Learn you some very basic devops and you can collect on those erlang-y benefits using whatever languages/tooling/paradigms you want. A lot of it is flat out built into and managed by ye cloud providers.

Infra people squint at something like Beam/OTP and see a "control plane".

> Upgrade nginx live and without dropping any connections.

You can do that, but you won't get the new behavior on the existing connections, only for new connections. Some http servers will also curtail keep-alive requests while draining the old server processes, so you still get to pay the cost of reestablishing long lived connections, if your use case includes those.

Erlang was originally either implemented in Prolog or was even a library / extension for Prolog, and its pattern matching functionality is just "because it was all Prolog and the developers were using Prolog", so it isn't really fair to give Erlang any credit at all for that as it wasn't even independently designed.

You can do hot loading in C with dlopen and friends, but you've got to be a lot more intentional, and have the right shape of program. I did it once for a networking proxy type thing where Erlang was inconvenient (I'd need to make NIFs to get at the data and didn't want to deal with that), but I had state I didn't want to lose or serialize while making changes to the code. Of course, I then proceded to make only one or two changes. ;)

Edit: or you can do it in C the more exciting way, by updating your mmaped libraries on disk. That'd take a lot of intentional effort to not just crash, which is what tends to happen when you accidentally update instead of replace mmaped libraries. (There's a reason to use install instead of cp)

> swap in a new process

Very technologically cool, but I'd much rather inject the new functionality into the source code. From there it can it make its way through the unit tests, integration tests, deployment, health/readiness checks, and if all that passes then I'll allow it to be called.

OTP allows multiple versions in concurrent upgrades across a cluster.

Additionally: testing, performance profiling, and debugging are natively supported.

Recommend reading:

"Designing Elixir Systems with OTP: Write Highly Scalable, Self-Healing Software with Layers" ( James Edward Gray, II, Bruce A. Tate)

Fargate allows multiple versions in concurrent upgrades across a cluster.

Additionally: testing, performance profiling, and debugging are natively supported.

Recommend reading:

"Amazon CloudWatch Container Insights for Amazon EKS Fargate using AWS Distro for OpenTelemetry" (https://aws.amazon.com/blogs/containers/introducing-amazon-c...)

One solution does not include metered connections, or Mr. Bezos compliance.

Cheers =)

Sure but that is just one example. There are lots of ways to roll your own similar setup on your own hardware. If you don't like Fargate you can go the k8s route, avoiding lock in is the whole point of it.

> Very technologically cool, but I'd much rather inject the new functionality into the source code.

Swapping in a new process and injecting the new functionality into the source code are not mutually exclusive. You can do both!

Erlang programmers are not idiots who would swap in new processes live without writing the source code for it and testing it. They write the code, the unit tests, the integration tests, deployment, health/readiness checks, and if all that passes then the deployment tools take care of swapping in the new process with zero downtime.

> Very technologically cool, but I'd much rather inject the new functionality into the source code. From there it can it make its way through the unit tests, integration tests, deployment, health/readiness checks, and if all that passes then I'll allow it to be called.

Generally, you do make the changes in source code, compile it, do all your pre-flight checks, and then hotload it. Honestly, sometimes the pre-flight check is just 'does it compile', but that's philisophical; you can put whatever process in place you want. But from my experience, it's much nicer to upgrade in place than start new, move traffic, drain old (not always in exactly that order). Sometimes, it's not realistic to avoid starting new and moving traffic, but it's nice when you can.

Most people aren't patching the VM bytecode by hand (to my knowledge).

There was that.. interview with a witch. I was a little enamoured by her.

https://aphyr.com/posts/341-hexing-the-technical-interview

Reply on news.ycombinator.com