5 ms·

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

by bsder 4y ago

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.

saurik 4y ago
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.
medo-bear 4y ago
> 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
- capableweb 4y ago
  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.
  - stevan 4y ago
    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.
    - capableweb 4y ago
      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 :)
      - lispm 4y ago
        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.
mrkeen 4y ago
> 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.
- Joel_Mckay 4y ago
  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)
  - recuter 4y ago
    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-cloudwatch-container-insights-for-amazon-eks-fargate-using-aws-distro-for-opentelemetry https://aws.amazon.com/blogs/containers/introducing-amazon-c...)
    - Joel_Mckay 4y ago
      One solution does not include metered connections, or Mr. Bezos compliance. Cheers =)
      - recuter 4y ago
        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.
- distcs 4y ago
  > 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.
recuter 4y ago
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 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".
- toast0 4y ago
  > 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.
toast0 4y ago
> 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. 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)

by bsder 4y ago

saurik 4y ago

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.

medo-bear 4y ago

capableweb 4y ago
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.
- stevan 4y ago
  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.
  - capableweb 4y ago
    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 :)
    - lispm 4y ago
      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.

mrkeen 4y ago

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

Joel_Mckay 4y ago
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)
- recuter 4y ago
  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-cloudwatch-container-insights-for-amazon-eks-fargate-using-aws-distro-for-opentelemetry https://aws.amazon.com/blogs/containers/introducing-amazon-c...)
  - Joel_Mckay 4y ago
    One solution does not include metered connections, or Mr. Bezos compliance. Cheers =)
    - recuter 4y ago
      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.
distcs 4y ago
> 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.

recuter 4y ago

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 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".

toast0 4y ago
> 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.

toast0 4y ago

> 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. 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)