4 ms·

I cut my teeth on Ruby and Rails, I've screwed around with Phoenix, and I'm currently infatuated with Rust. Earlier on I thought that, yeah, Rust is a great re

I cut my teeth on Ruby and Rails, I've screwed around with Phoenix, and I'm currently infatuated with Rust. Earlier on I thought that, yeah, Rust is a great replacement for C and not something want to write a web app in. So, sure, I've got a bunch of little doodads written in Rust (mostly CLI tools). Now? The fluff I've written in Elixir is getting ported to Rust. The Rust tooling and community are just that good. I'd rather have to work on some extra verbosity and maybe even maintain my own helper library in Rust than deal with with Elixir/Phoenix at this point. The number one reason is that Elixir deployments are nothing short of a nightmare. I've found the community not particularly helpful or knowledgeable about how things work (and given how many moving pieces are in an Elixir deployment, and how brittle Elixir deployments are, this is a terrible thing). And you're definitely not going to write CLI tools in Elixir (it straight doesn't work with escript in the first place). Compiling down into a single "static" binary like Rust (and Go) do by default is a huge win for things like this. The quick startup time of a Rust or Go app compared to Ruby or anything JVM based is great for rapid iteration and testing. The tooling around Rust is, in general, fantastic. Being that much of a pleasure to use really makes up for how inappropriate it is to use Rust for most high level web app things. Phoenix had a lot of promise, but these days I'd much rather go back to Rails or Django (with an eye towards how to migrate to a compiled language) if I needed to churn something out quickly.

uxcolumbo 8y ago
I'm currently looking into learning Elixir, but your comment sprinkled some doubts on that. If deployment was easier in the Elixir world, would you have stuck with it?
- inferiorhuman 8y ago
  If deployment was easier in the Elixir world, would you have stuck with it? Perhaps, but Elixir was a very niche product for me. I'd use it for web apps and that's about it. Even then the ecosystem was fairly immature, and I'd only really want to use it in a setting that played to the strengths of Erlang. One of the big problems with the deployments being a gigantic beast is that there are maybe one or two people who understand the tooling around it. Great when it works, really lousy when it doesn't. With the other languages being discussed (e.g. Rust, Go, Python, Ruby, Clojure, Kotlin) I've found far broader uses. I'm not going to write TUI/GUI apps nor would I write shared libraries with Elixir. Unless escript support was implemented you simply can't write things that depend on a shebang. There's no harm in learning it, but the key is in being able to go beyond the hype and evaluate when it's worth using the knowledge you've just acquired.
- robotmay 8y ago
  Honestly Elixir has been one of the most enjoyable learning experiences I've had in years. Deployment is fine, but there are a few different things to consider (because you can do some really cool stuff using BEAM). But you can just chuck it on Heroku if you want something easy. I also like Rust a lot, but I find Elixir pretty much frictionless to work in. Rust is basically you vs the compiler for quite a while. I've been using Rust for IoT work but I vastly prefer Elixir for web. And since I've been enjoying it so much I'm gonna start looking at Nerves (https://github.com/nerves-project/nerves https://github.com/nerves-project/nerves) for IoT work as well.
Gazler 8y ago
Not sure when you were using Elixir, but releases are a good option for deployment now. This is supported with the distillery library (https://hexdocs.pm/distillery/home.html https://hexdocs.pm/distillery/home.html). The master version of Elixir also has support for releases https://hexdocs.pm/mix/master/Mix.Tasks.Release.html https://hexdocs.pm/mix/master/Mix.Tasks.Release.html
- inferiorhuman 8y ago
  Last I checked distillery was Linux only (e.g. does not work on BSD), which is a deal breaker for me. But I wouldn't consider using distillery (and thus Elixir/Phoenix) on any platform given the haphazard nature of the support for distillery. There's exactly one person who knows anything about it and he supports it when he doesn't have anything better to do. Sure, in a smaller shop you could dig into distillery and try to fix things up. But when shit hits the fan, do you want to discover the hidden dependencies (e.g. bash vs POSIX sh)? I wouldn't want to bet on a single point of failure like that. And the big problem for Elixir is that you don't see that level of mess or siloed knowledge with other languages. Say what you will about something like Capistrano, but it's an order of magnitude easier to dig into and support because it's not mashing together a variety of languages (erlang, bash, elixir). Some languages like anything JVM based (that compile down to JARs), Rust, and Go compile down into single artifacts quite easily. Others like Ruby and Python can be moved around with standard system tools easily enough.
  - josevalim 8y ago
    If those are your concerns, then the fact we are adding releases to Elixir core in the upcoming version should solve most of them. The single point of failure is gone. The code is now maintained by the Elixir Core Team and it should garner more general attention from the community. The amount and complexity of scripts have been reduced drastically and they are statically verified to run on `sh` (no bash). As with everything else in Elixir, we do our best to keep the Erlang <-> Elixir interface pretty clean. You should expect the same level of quality and polish as the remaining of the Elixir tooling. I am not sure about this point though: > Others like Ruby and Python can be moved around with standard system tools easily enough. If you are not using releases, and simply Mix, is Elixir any harder to move around then Ruby and Python? From my understanding, using Mix to run Elixir in prod is a similar experience that both Ruby and Python would provide.
josevalim 8y ago
I am sorry to hear that you had bad experiences while deploying Elixir. To avoid having others running into the same bad experiences, I would like to point out to some resources and recent improvements in the area for those interested in deploying Elixir. There are mostly two ways to deploy Elixir. One is the provisioned approach: you install Erlang/Elixir (or you assume it is installed in the machine), then you fetch your project source code, fetch deps, compile them and run your project (in the same way you would run it locally). The other approach is via releases. A release is a way to package the Erlang VM, Elixir and all of your application code into something you can dropped into production. The downside is that you need to match the target OS and architecture but there are many documented approaches to do so. Today the main tool for performing releases is Distillery and it has great documentation covering AWS, Docker, etc: https://hexdocs.pm/distillery/home.html https://hexdocs.pm/distillery/home.html In Elixir v1.9, coming out this July, we are incorporating releases as part of the language. You can read more about it in our documentation for master: https://hexdocs.pm/mix/master/Mix.Tasks.Release.html https://hexdocs.pm/mix/master/Mix.Tasks.Release.html If you are using a PaaS such as Heroku, it is likely there is already tooling that will take care of it for you, such as the Heroku Elixir buildpack: https://github.com/HashNuke/heroku-buildpack-elixir https://github.com/HashNuke/heroku-buildpack-elixir. There is also Gigalixir, a PaaS specific to Erlang/Elixir: https://gigalixir.com/ https://gigalixir.com/ Finally, if you want a more structured resource, there is also the Adopting Elixir book (disclaimer! I am one of the authors): https://pragprog.com/book/tvmelixir/adopting-elixir https://pragprog.com/book/tvmelixir/adopting-elixir - One third of the book is about production concerns, covering deployment, performance, metrics, monitoring, etc. If none of this works, you can always reach out to the community in elixirforum.com. I assure you there are more than 2 developers that know about deployment :) and if you still feel like none of the replies about deployment there have been satisfactory, feel free to add me to the conversation there. > And you're definitely not going to write CLI tools in Elixir (it straight doesn't work with escript in the first place). I do not understand this comment as Elixir works with escripts just fine. You can build an escript for your project by simply calling `mix escript.build`. This has been available since v1.0 (https://github.com/elixir-lang/elixir/blob/v1.0.0/lib/mix/lib/mix/tasks/escript.build.ex https://github.com/elixir-lang/elixir/blob/v1.0.0/lib/mix/li...). You can even install escripts directly from Hex (our package manager) since Elixir v1.4 (2.5 years old).
AlchemistCamp 8y ago
This is quite a coincidence as deployment was exactly what I covered in my last YT video. I hear the complaint about deployment a lot, but it really doesn't make sense to me. If you run mix in production, then it's just like running Rails or Node. You don't get certain features like hot upgrades in production while keeping what's in memory on the server, but you don't get that from Rails/Node/PHP/Python either. If you want those BEAM releases, then you have to use the Elixir (or Erlang) tools for them. I also encountered a great deal of frustration when working from a different OS, but no more than I did when building Rails apps several years ago. Now I generally, build with Gitlab CI/CD and deploy from that Gitlab container to my server with Distillery and Edeliver. It lets me use the standard CI/CD tools and have stateful upgrades. I am running Ubuntu on the server, though: https://www.youtube.com/watch?v=-mm44ADU3kc https://www.youtube.com/watch?v=-mm44ADU3kc
Fire-Dragon-DoL 8y ago
Sorry, I don't get your point for deployment. There are complaints you can make fot everything, but deploying an elixir application boils down to compile, upload, start. Sure, 2 days of work the first time, which is a negligible amount of time for any real world project (otherwise you are on the wrong language). This if you want a good pipeline. Otherwise it's a couple of hours, but even with rails i always invested a couple of days to have a good pipeline. Doesn't mean rust does not do it better, but it's really not the point for choosing a language over another. In a big project you have a dedicated person. In a medium project, the investment is very small. In a small project, you are better served by prototyping tools (rails)

uxcolumbo 8y ago

I'm currently looking into learning Elixir, but your comment sprinkled some doubts on that. If deployment was easier in the Elixir world, would you have stuck with it?

inferiorhuman 8y ago
If deployment was easier in the Elixir world, would you have stuck with it? Perhaps, but Elixir was a very niche product for me. I'd use it for web apps and that's about it. Even then the ecosystem was fairly immature, and I'd only really want to use it in a setting that played to the strengths of Erlang. One of the big problems with the deployments being a gigantic beast is that there are maybe one or two people who understand the tooling around it. Great when it works, really lousy when it doesn't. With the other languages being discussed (e.g. Rust, Go, Python, Ruby, Clojure, Kotlin) I've found far broader uses. I'm not going to write TUI/GUI apps nor would I write shared libraries with Elixir. Unless escript support was implemented you simply can't write things that depend on a shebang. There's no harm in learning it, but the key is in being able to go beyond the hype and evaluate when it's worth using the knowledge you've just acquired.
robotmay 8y ago
Honestly Elixir has been one of the most enjoyable learning experiences I've had in years. Deployment is fine, but there are a few different things to consider (because you can do some really cool stuff using BEAM). But you can just chuck it on Heroku if you want something easy. I also like Rust a lot, but I find Elixir pretty much frictionless to work in. Rust is basically you vs the compiler for quite a while. I've been using Rust for IoT work but I vastly prefer Elixir for web. And since I've been enjoying it so much I'm gonna start looking at Nerves (https://github.com/nerves-project/nerves https://github.com/nerves-project/nerves) for IoT work as well.

Gazler 8y ago

Not sure when you were using Elixir, but releases are a good option for deployment now. This is supported with the distillery library (https://hexdocs.pm/distillery/home.html https://hexdocs.pm/distillery/home.html). The master version of Elixir also has support for releases https://hexdocs.pm/mix/master/Mix.Tasks.Release.html https://hexdocs.pm/mix/master/Mix.Tasks.Release.html

inferiorhuman 8y ago
Last I checked distillery was Linux only (e.g. does not work on BSD), which is a deal breaker for me. But I wouldn't consider using distillery (and thus Elixir/Phoenix) on any platform given the haphazard nature of the support for distillery. There's exactly one person who knows anything about it and he supports it when he doesn't have anything better to do. Sure, in a smaller shop you could dig into distillery and try to fix things up. But when shit hits the fan, do you want to discover the hidden dependencies (e.g. bash vs POSIX sh)? I wouldn't want to bet on a single point of failure like that. And the big problem for Elixir is that you don't see that level of mess or siloed knowledge with other languages. Say what you will about something like Capistrano, but it's an order of magnitude easier to dig into and support because it's not mashing together a variety of languages (erlang, bash, elixir). Some languages like anything JVM based (that compile down to JARs), Rust, and Go compile down into single artifacts quite easily. Others like Ruby and Python can be moved around with standard system tools easily enough.
- josevalim 8y ago
  If those are your concerns, then the fact we are adding releases to Elixir core in the upcoming version should solve most of them. The single point of failure is gone. The code is now maintained by the Elixir Core Team and it should garner more general attention from the community. The amount and complexity of scripts have been reduced drastically and they are statically verified to run on `sh` (no bash). As with everything else in Elixir, we do our best to keep the Erlang <-> Elixir interface pretty clean. You should expect the same level of quality and polish as the remaining of the Elixir tooling. I am not sure about this point though: > Others like Ruby and Python can be moved around with standard system tools easily enough. If you are not using releases, and simply Mix, is Elixir any harder to move around then Ruby and Python? From my understanding, using Mix to run Elixir in prod is a similar experience that both Ruby and Python would provide.

josevalim 8y ago

I am sorry to hear that you had bad experiences while deploying Elixir. To avoid having others running into the same bad experiences, I would like to point out to some resources and recent improvements in the area for those interested in deploying Elixir. There are mostly two ways to deploy Elixir. One is the provisioned approach: you install Erlang/Elixir (or you assume it is installed in the machine), then you fetch your project source code, fetch deps, compile them and run your project (in the same way you would run it locally). The other approach is via releases. A release is a way to package the Erlang VM, Elixir and all of your application code into something you can dropped into production. The downside is that you need to match the target OS and architecture but there are many documented approaches to do so. Today the main tool for performing releases is Distillery and it has great documentation covering AWS, Docker, etc: https://hexdocs.pm/distillery/home.html https://hexdocs.pm/distillery/home.html In Elixir v1.9, coming out this July, we are incorporating releases as part of the language. You can read more about it in our documentation for master: https://hexdocs.pm/mix/master/Mix.Tasks.Release.html https://hexdocs.pm/mix/master/Mix.Tasks.Release.html If you are using a PaaS such as Heroku, it is likely there is already tooling that will take care of it for you, such as the Heroku Elixir buildpack: https://github.com/HashNuke/heroku-buildpack-elixir https://github.com/HashNuke/heroku-buildpack-elixir. There is also Gigalixir, a PaaS specific to Erlang/Elixir: https://gigalixir.com/ https://gigalixir.com/ Finally, if you want a more structured resource, there is also the Adopting Elixir book (disclaimer! I am one of the authors): https://pragprog.com/book/tvmelixir/adopting-elixir https://pragprog.com/book/tvmelixir/adopting-elixir - One third of the book is about production concerns, covering deployment, performance, metrics, monitoring, etc. If none of this works, you can always reach out to the community in elixirforum.com. I assure you there are more than 2 developers that know about deployment :) and if you still feel like none of the replies about deployment there have been satisfactory, feel free to add me to the conversation there. > And you're definitely not going to write CLI tools in Elixir (it straight doesn't work with escript in the first place). I do not understand this comment as Elixir works with escripts just fine. You can build an escript for your project by simply calling `mix escript.build`. This has been available since v1.0 (https://github.com/elixir-lang/elixir/blob/v1.0.0/lib/mix/lib/mix/tasks/escript.build.ex https://github.com/elixir-lang/elixir/blob/v1.0.0/lib/mix/li...). You can even install escripts directly from Hex (our package manager) since Elixir v1.4 (2.5 years old).

AlchemistCamp 8y ago

This is quite a coincidence as deployment was exactly what I covered in my last YT video. I hear the complaint about deployment a lot, but it really doesn't make sense to me. If you run mix in production, then it's just like running Rails or Node. You don't get certain features like hot upgrades in production while keeping what's in memory on the server, but you don't get that from Rails/Node/PHP/Python either. If you want those BEAM releases, then you have to use the Elixir (or Erlang) tools for them. I also encountered a great deal of frustration when working from a different OS, but no more than I did when building Rails apps several years ago. Now I generally, build with Gitlab CI/CD and deploy from that Gitlab container to my server with Distillery and Edeliver. It lets me use the standard CI/CD tools and have stateful upgrades. I am running Ubuntu on the server, though: https://www.youtube.com/watch?v=-mm44ADU3kc https://www.youtube.com/watch?v=-mm44ADU3kc

Fire-Dragon-DoL 8y ago

Sorry, I don't get your point for deployment. There are complaints you can make fot everything, but deploying an elixir application boils down to compile, upload, start. Sure, 2 days of work the first time, which is a negligible amount of time for any real world project (otherwise you are on the wrong language). This if you want a good pipeline. Otherwise it's a couple of hours, but even with rails i always invested a couple of days to have a good pipeline. Doesn't mean rust does not do it better, but it's really not the point for choosing a language over another. In a big project you have a dedicated person. In a medium project, the investment is very small. In a small project, you are better served by prototyping tools (rails)