4 ms·

Elixir was a joy to write applications in. OTP provides the most seamless graduation from single-threaded to concurrent to distributed application that I've see

by jb3689 5y ago

Elixir was a joy to write applications in. OTP provides the most seamless graduation from single-threaded to concurrent to distributed application that I've seen in any language. The abstractions are built the way they are because they facilitate this process. Additionally using apps as building blocks matches exactly how I think about systems. The only things I didn't like: * Message queues are fundamental to the abstractions. If you need to avoid queuing for whatever reason then you need to think harder * Leaving the Erlang ecosystem (e.g. shelling out) always felt painful. Integrating with Kubernetes was painful. OTP has its own ways of doing everything and they are often counter to general best practices (e.g. doing hot releases instead of rolling new containers) * I never figured out how to do multi-node systems correctly. One of the neat things about OTP is that you can migrate processes between nodes that are connected in a mesh network. The documentation is really light on how to do this. Along those lines, more advanced multi-node setups exist but feel like they are at the fringes of what has been done with OTP so you need to invest a lot of time if your application can't handle a mesh setup The only language that comes close to Elixir for me is Rust. I haven't done much with Rust however the out-of-the-box tooling is really great for it. I'm doubtful that distributed applications are as easy to write in Rust as they are in Elixir though I tried to sell a company I was working at (they were doing real-time bidding) on Elixir. It's a shame they didn't go with it (they went with Java instead). It's really easy to build those types of apps in Elixir. Likewise I'm somewhat surprised Elixir hasn't taken off with teams who want microservices.

linkdd 5y ago
> Leaving the Erlang ecosystem (e.g. shelling out) always felt painful - https://hexdocs.pm/rambo/Rambo.html - https://hexdocs.pm/elixir/1.12/Port.html - https://github.com/Pyrlang/Pyrlang - https://github.com/goerlang/node - https://erlang.org/doc/apps/erl_interface/ei_users_guide.html - https://erlang.org/doc/tutorial/nif.html > Integrating with Kubernetes was painful - https://hexdocs.pm/libcluster/readme.html - https://hexdocs.pm/k8s/usage.html > OTP has its own ways of doing everything and they are often counter to general best practices (e.g. doing hot releases instead of rolling new containers) Now this is opinionated. Hot releases are used mostly if you want to upgrade your drone's software while it's flying. Surely you don't want it to crash? Or if you're a telecom company (like the creator of Erlang), you don't want an upgrade to kill the on-going communications. Same for a MMO, you don't want an upgrade to disconnect your players. Docker/Kubernetes is not "general best practices". It's only one way out of many. And if you don't need the use cases above, you can put your application in a Docker container and restart it for upgrades, this is how 90% of Elixir/Phoenix webapps are deployed. > One of the neat things about OTP is that you can migrate processes between nodes that are connected in a mesh network. The documentation is really light on how to do this. - https://hexdocs.pm/horde/ - https://hexdocs.pm/highlander/Highlander.html#content - https://github.com/ringling/distro > The only language that comes close to Elixir for me is Rust How? They solve completely different problems. Could you explain?
- jb3689 5y ago
  My time with Elixir is pretty stale at this point (5-6 years ago; haven't touched it much in the past 4) so I'm glad to see there are better solutions today > How? They solve completely different problems. Could you explain? I don't disagree. The main crossover for me has been in productivity/expressiveness/safety. Can I easily write the programs I want to write with it or am I fighting the language and tooling constantly? Do I have high confidence in the correctness of my solution? Does the solution feel easy to maintain and extend? I haven't done enough with Rust to comment on how it fairs for larger projects, but my experiences with it for smaller problems has been very positive

by jb3689 5y ago

linkdd 5y ago

> Leaving the Erlang ecosystem (e.g. shelling out) always felt painful - https://hexdocs.pm/rambo/Rambo.html - https://hexdocs.pm/elixir/1.12/Port.html - https://github.com/Pyrlang/Pyrlang - https://github.com/goerlang/node - https://erlang.org/doc/apps/erl_interface/ei_users_guide.html - https://erlang.org/doc/tutorial/nif.html > Integrating with Kubernetes was painful - https://hexdocs.pm/libcluster/readme.html - https://hexdocs.pm/k8s/usage.html > OTP has its own ways of doing everything and they are often counter to general best practices (e.g. doing hot releases instead of rolling new containers) Now this is opinionated. Hot releases are used mostly if you want to upgrade your drone's software while it's flying. Surely you don't want it to crash? Or if you're a telecom company (like the creator of Erlang), you don't want an upgrade to kill the on-going communications. Same for a MMO, you don't want an upgrade to disconnect your players. Docker/Kubernetes is not "general best practices". It's only one way out of many. And if you don't need the use cases above, you can put your application in a Docker container and restart it for upgrades, this is how 90% of Elixir/Phoenix webapps are deployed. > One of the neat things about OTP is that you can migrate processes between nodes that are connected in a mesh network. The documentation is really light on how to do this. - https://hexdocs.pm/horde/ - https://hexdocs.pm/highlander/Highlander.html#content - https://github.com/ringling/distro > The only language that comes close to Elixir for me is Rust How? They solve completely different problems. Could you explain?

jb3689 5y ago
My time with Elixir is pretty stale at this point (5-6 years ago; haven't touched it much in the past 4) so I'm glad to see there are better solutions today > How? They solve completely different problems. Could you explain? I don't disagree. The main crossover for me has been in productivity/expressiveness/safety. Can I easily write the programs I want to write with it or am I fighting the language and tooling constantly? Do I have high confidence in the correctness of my solution? Does the solution feel easy to maintain and extend? I haven't done enough with Rust to comment on how it fairs for larger projects, but my experiences with it for smaller problems has been very positive