6 ms·

I have a ton of respect for José Valim and the Elixir core team, I have to say: Elixir just doesn’t mesh well with the kind of infrastructure tooling that’s bec

I have a ton of respect for José Valim and the Elixir core team, I have to say: Elixir just doesn’t mesh well with the kind of infrastructure tooling that’s become standard today. The ecosystem has been growing impressively and there’s a lot to admire, but its philosophy often feels at odds with containerized, Kubernetes-based deployments. Elixir promotes a "do it all in one place" model—concurrency, distribution, fault tolerance—which can be powerful, but when you try to shoehorn that into a world built around ephemeral containers and orchestration, it starts to crack. The abstractions don’t always translate cleanly. This opinion comes from experience: we’ve been migrating a fairly complex Elixir codebase to Go. It’s a language our team knows well and scales reliably in modern infra. At the end of the day, don’t get too attached to any language. Choose what aligns with your team’s strengths and your production reality.

ch4s3 1y ago
If you can't get Elixir to work well in k8s, you're simply doing it wrong. Yeah you can build a lot of what k8s offers on the BEAM on a bare server but you don't have to at all. Elixir offers modern telemetry that works really well with pretty much any monitoring tool, and give you a lot of introspection into the internals of the VM if you need it. "Let it fail" works just fine in k8s, you can run a supervision tree in a container and have it manage process restarts internally just fine, its just an added layer of fault tolerance. Sure, you can't easily have long running stateful processes if you're doing a lot of blue-green deployments, but you probably don't need to do that most of the time. If you don't know Elixir and the BEAM well, of course you're going to have a bad time. That's true of any language.
- benmmurphy 1y ago
  phoenix live view is effectively built around the assumption that the server process never dies and never restarts. its a very dubious model for a production deployment. > what happens when the server restarts / connection is lost / server dies? > you lose all of the current client state but you can work around this by persisting all the client state somewhere. > oh, so why am i using live view again?
  - ch4s3 1y ago
    > phoenix live view is effectively built around the assumption that the server process never dies and never restarts. Not exactly, it's built to hold state in memory by default but doesn't assume how you want to handle deploys or server restarts. There's a built in restore mechanism for forms and it's trivial to shuffle state off to either the client/redis/your db[1]. You'd have the same problem if you were storing all your state in memory for any web application regardless of your library choice. Or you conversely have the problem that refreshing the page trashes client state. So there are two thinks here, you don't have to use live_view to use elixir or phoenix, and if you do you just need to actually think about how you're solving problems. The state can get trashed anywhere for any number of reasons. Tossing on the client and forgetting about it just moves the problem. [1] https://hexdocs.pm/phoenix_live_view/deployments.html https://hexdocs.pm/phoenix_live_view/deployments.html
    - benmmurphy 1y ago
      the way live-view is sold is some kind of alternative to writing javascript. if you have a very rich client side application then you can easily end up with a bunch of state which would be in the clients memory but now is in the servers memory. but if its in the servers memory the data ends up being much more fragile because any failure of the client or the server means the live view state is lost. whereas if the data was just in client memory then it would only be lost if there is a problem in the browser. ideally people would write applications that are tolerant to both faults. but i think in practice live-view practitioners just ignore the problem and then you are left in a worse situation. i realize there is still a dataloss problem when there is state on the client but there is a lot of simple stuff that causes problems if you are effectively reloading the page if the server disappears due to a redeploy or a crash. for example i'm reading an email in my message client. i've scrolled half-way down the email. but now the server crashes i reconnect to live view and my scroll position when reading the email is reset. when i look at live view i feel like its written by people that have never deployed something in production. of course this is not really true but i feel like it would be better if live-view people were more honest about the tradeoffs. its a very complicated situation and having some bad outcomes might be worth the increase in developer productivity but i feel like live-view people just ignore the bad outcomes. also, take a cloud deployment. websockets seem to be an inherent problem in cloud deployments especially AWS. as far as i know AWS does not expose some event to a instance that is part of a load balancer that it is about to die. ideally if you have a websocket instance with a client and you realize you are scheduled to be reaped you would message the client that it needs to reconnect. then the client would reconnect to a server that would not be reaped and everything would be dandy. but AWS doesn't seem to have this functionality (or its not easy to implement!) but more importantly live view does not expose any kind of hooks so you can have 'safe' server redeployment out of the box.
jon-wood 1y ago
Sure, if your a company which is fully bought into ephemeral containers running on Kubernetes then Elixir is probably not going to be a great fit for you. I have once introduced it into a company like that and eventually the same thing happened, the application got rewritten in a language that fits the paradigm better. If I were starting a new company today though I'd probably go with Elixir, and then I simply wouldn't bother with containers, Kubernetes, and schedulers. Just run some servers and run the application on them, let them cluster, and generally lean into the advantages.
- em-bee 1y ago
  most people/companies who think they need kubernetes don't actually need it. you are not google or amazon. and with erlang/elixir that's likely even more true.
- asa400 1y ago
  > if your a company which is fully bought into ephemeral containers running on Kubernetes then Elixir is probably not going to be a great fit for you As a community, we have got to stop saying this stuff. It's false. Nothing about Elixir or k8s precludes using the other. Elixir applications can and do run just fine in containers and k8s deployments. In fact, they're complementary: https://dashbit.co/blog/kubernetes-and-the-erlang-vm-orchestration-on-the-large-and-the-small https://dashbit.co/blog/kubernetes-and-the-erlang-vm-orchest...
Towaway69 1y ago
Elixir has a Ruby on Rails approach which is kind of all in one. Not everyone’s cup of hot chocolate. Erlang is low level, lightweight processes and message passing - perfect for micro-services and containerisation. What Erlang lacks are high level web-oriented packages, i.e. markdown conversion, CSS and JavaScript packaging, REST (not quite true: cowboy is fantastic) - for which though Erlang was never intended. However the cool thing is that you can combine both in the same project, allowing you to have high level Elixir and low-level process management in one project. This is possible because both use the same virtual machine - BEAM.
- davidw 1y ago
  Erlang isn't really that much lower level than Elixir. The Elixir syntax is just a bit different and they've improved a few things like string handling. Processes are still processes.
lknuth 1y ago
We look at K8s more like "the Cloud Operating System". Many of its capabilities are more valuable for other runtimes, but that doesn't mean that Elixir is a bad fit with it. For example, the Erlang VM clustering can make use of K8s for Service Discovery. You can do ephemeral containers and use readiness probes to create a " hand over" period where new instances can sync their data from old, about-to-be-replaced instances.
sisve 1y ago
Did you do hot updates? I ser that is mention in the post, but I thought the community has walked away from it? Or at least that its mixed feelings about it?

ch4s3 1y ago

If you can't get Elixir to work well in k8s, you're simply doing it wrong. Yeah you can build a lot of what k8s offers on the BEAM on a bare server but you don't have to at all. Elixir offers modern telemetry that works really well with pretty much any monitoring tool, and give you a lot of introspection into the internals of the VM if you need it. "Let it fail" works just fine in k8s, you can run a supervision tree in a container and have it manage process restarts internally just fine, its just an added layer of fault tolerance. Sure, you can't easily have long running stateful processes if you're doing a lot of blue-green deployments, but you probably don't need to do that most of the time. If you don't know Elixir and the BEAM well, of course you're going to have a bad time. That's true of any language.

benmmurphy 1y ago
phoenix live view is effectively built around the assumption that the server process never dies and never restarts. its a very dubious model for a production deployment. > what happens when the server restarts / connection is lost / server dies? > you lose all of the current client state but you can work around this by persisting all the client state somewhere. > oh, so why am i using live view again?
- ch4s3 1y ago
  > phoenix live view is effectively built around the assumption that the server process never dies and never restarts. Not exactly, it's built to hold state in memory by default but doesn't assume how you want to handle deploys or server restarts. There's a built in restore mechanism for forms and it's trivial to shuffle state off to either the client/redis/your db[1]. You'd have the same problem if you were storing all your state in memory for any web application regardless of your library choice. Or you conversely have the problem that refreshing the page trashes client state. So there are two thinks here, you don't have to use live_view to use elixir or phoenix, and if you do you just need to actually think about how you're solving problems. The state can get trashed anywhere for any number of reasons. Tossing on the client and forgetting about it just moves the problem. [1] https://hexdocs.pm/phoenix_live_view/deployments.html https://hexdocs.pm/phoenix_live_view/deployments.html
  - benmmurphy 1y ago
    the way live-view is sold is some kind of alternative to writing javascript. if you have a very rich client side application then you can easily end up with a bunch of state which would be in the clients memory but now is in the servers memory. but if its in the servers memory the data ends up being much more fragile because any failure of the client or the server means the live view state is lost. whereas if the data was just in client memory then it would only be lost if there is a problem in the browser. ideally people would write applications that are tolerant to both faults. but i think in practice live-view practitioners just ignore the problem and then you are left in a worse situation. i realize there is still a dataloss problem when there is state on the client but there is a lot of simple stuff that causes problems if you are effectively reloading the page if the server disappears due to a redeploy or a crash. for example i'm reading an email in my message client. i've scrolled half-way down the email. but now the server crashes i reconnect to live view and my scroll position when reading the email is reset. when i look at live view i feel like its written by people that have never deployed something in production. of course this is not really true but i feel like it would be better if live-view people were more honest about the tradeoffs. its a very complicated situation and having some bad outcomes might be worth the increase in developer productivity but i feel like live-view people just ignore the bad outcomes. also, take a cloud deployment. websockets seem to be an inherent problem in cloud deployments especially AWS. as far as i know AWS does not expose some event to a instance that is part of a load balancer that it is about to die. ideally if you have a websocket instance with a client and you realize you are scheduled to be reaped you would message the client that it needs to reconnect. then the client would reconnect to a server that would not be reaped and everything would be dandy. but AWS doesn't seem to have this functionality (or its not easy to implement!) but more importantly live view does not expose any kind of hooks so you can have 'safe' server redeployment out of the box.

jon-wood 1y ago

Sure, if your a company which is fully bought into ephemeral containers running on Kubernetes then Elixir is probably not going to be a great fit for you. I have once introduced it into a company like that and eventually the same thing happened, the application got rewritten in a language that fits the paradigm better. If I were starting a new company today though I'd probably go with Elixir, and then I simply wouldn't bother with containers, Kubernetes, and schedulers. Just run some servers and run the application on them, let them cluster, and generally lean into the advantages.

em-bee 1y ago
most people/companies who think they need kubernetes don't actually need it. you are not google or amazon. and with erlang/elixir that's likely even more true.
asa400 1y ago
> if your a company which is fully bought into ephemeral containers running on Kubernetes then Elixir is probably not going to be a great fit for you As a community, we have got to stop saying this stuff. It's false. Nothing about Elixir or k8s precludes using the other. Elixir applications can and do run just fine in containers and k8s deployments. In fact, they're complementary: https://dashbit.co/blog/kubernetes-and-the-erlang-vm-orchestration-on-the-large-and-the-small https://dashbit.co/blog/kubernetes-and-the-erlang-vm-orchest...

Towaway69 1y ago

Elixir has a Ruby on Rails approach which is kind of all in one. Not everyone’s cup of hot chocolate. Erlang is low level, lightweight processes and message passing - perfect for micro-services and containerisation. What Erlang lacks are high level web-oriented packages, i.e. markdown conversion, CSS and JavaScript packaging, REST (not quite true: cowboy is fantastic) - for which though Erlang was never intended. However the cool thing is that you can combine both in the same project, allowing you to have high level Elixir and low-level process management in one project. This is possible because both use the same virtual machine - BEAM.

davidw 1y ago
Erlang isn't really that much lower level than Elixir. The Elixir syntax is just a bit different and they've improved a few things like string handling. Processes are still processes.

lknuth 1y ago

We look at K8s more like "the Cloud Operating System". Many of its capabilities are more valuable for other runtimes, but that doesn't mean that Elixir is a bad fit with it. For example, the Erlang VM clustering can make use of K8s for Service Discovery. You can do ephemeral containers and use readiness probes to create a " hand over" period where new instances can sync their data from old, about-to-be-replaced instances.

sisve 1y ago

Did you do hot updates? I ser that is mention in the post, but I thought the community has walked away from it? Or at least that its mixed feelings about it?