5 ms·

I used to be really bullish on Elixir, but having used it in production for over a year (and having worked on libraries since '13), I think people are overselli

I used to be really bullish on Elixir, but having used it in production for over a year (and having worked on libraries since '13), I think people are overselling the daily experience. The language itself is good, the tooling is pretty excellent, but there are issues for things like deployment, ops, and frankly a general excitement about neat things instead of focusing on bread-and-butter stuff like, say, timezones and timestamp formatting (something coming in a couple of releases, allegedly, but which was always an obvious absence).

qaq 8y ago
I would agree that deployment story could be better, thing is you have to allocate time to setup CI/CD and all the relevant integrations regardless of what language you are using so the extra one time effort to get things working smoothly for Elixir is not that bad. This is also an area of strong focus of efforts to improve the tooling so I think it will get better in a reasonable amount of time.
whalesalad 8y ago
Why does everyone seem to be so upset about deployment? I can't comprehend the issue.
- sb8244 8y ago
  My experience has been painful at first (~1 week time to get setup), now takes 15 minutes to get a service deployed. Using Heroku (not good practice and I wouldn't use in prod), it would be really quick.
  - bostonvaulter2 8y ago
    Heroku works fine in prod up to the scale of most pre-series A startups. There are a few limitations you have to accept but for us the easy deployment strategy (and existing suite of addons) makes it very easy.
    - sb8244 8y ago
      This is true, probably fine for smaller use cases. I cannot imagine doing a production Elixir app without node networking (I do quite a few things with it), and that is a deal-breaker for me on Heroku. That's really the only deal-breaker though. Docker for Heroku makes it really easy to ship artifacts rather than source which I think is important as well.
- dudul 8y ago
  Because there is no agreed upon way to properly do it yet. I tried using Elixir 2 years ago in production, and while the language is great, deploying (and runtime configuration) was a nightmare. It was 2 years ago, I know the community tried to improve things, but it's still not there. I read some excerpt of the upcoming book "Phoenix in Action", and in chapter 1, the author himself mentions "deployment" as a drawback of using Phoenix since it's still painful.
  - burky 8y ago
    I'm curious as to what was a nightmare about the deployment and runtime configuration. Would you mind sharing your experience? Even better, post your concerns on one of the following sites and link back here. Sounds like it could be an interesting issue and I might be able to contribute. https://github.com/elixir-lang/elixir/issues https://github.com/elixir-lang/elixir/issues https://github.com/phoenixframework/phoenix/issues https://github.com/phoenixframework/phoenix/issues
    - _asummers 8y ago
      The general issues people have are around Application env, compiled System variables from build box in their configs, people forgetting that module attributes are compiled, and those sorts of issues. Libraries have begun moving away from Application env per library guidelines, and have begin moving to init/2 callbacks instead, which alleviates a lot of those issues, but there are a lot of straggler libraries that will not change for a while. So you have to do funky things like play with your Application env in your application.ex file. You had that weird system tuple thing that some libraries supported, and some that didn't, and then things like Confex coming up to meet in the middle. There isn't a nice story for getting secrets from something like Vault, for example. Releases are not mainline yet (soon!) and are kind of off to the side in a semi-officially supported way (bitwalker is amazing!). There are guides for this, but not the same type of guides as would exist if it were in the core repos. Then you have hot code reloading, which exists, but is usually said to be shied away from generally, so there's even fewer guides about all the gotchas that come with those sorts of systems. Some people even run mix phx.server on their prod boxes! I LOVE this language, and all these problems have solutions and workarounds, but one can't tell the story without being honest about the current release/deployment quirks. Things are definitely better than they were a few months ago, and much better than a few months before that. But they're not quite at the level they need to be for something that's supposed to be so fundamental to your application as its configuration and release. They'll get there.
Exuma 8y ago
What is elixir lacking in terms of timezones and timestamp formatting? Examples?
nickjj 8y ago
Why not just use the Timex library for now? Then timestamps and timezones are in good shape. Even as a newbie to the ecosystem it didn't take long to discover that time functionality was lacking in Elixir but the Timex library makes that a solved problem with little effort. Looking forward to seeing what comes up in the standard library for that in the future.
- freedomben 8y ago
  I've had a great time with Timex (pun not intended). I hope it gets merged into the language as is its goal.
passer-by-123 8y ago
While I agree deployment is probably the major pain point, I don’t see a reason to add time zones or time formatting to Elixir, given those problems are well solved in the community with the Timex and Calendar packages. I prefer the Elixir standard library to continue small and focused.
- angersock 8y ago
  Time and timezones are basic functionality used in almost any app of substance. A modern language should have first-class support for these things. :|

qaq 8y ago

I would agree that deployment story could be better, thing is you have to allocate time to setup CI/CD and all the relevant integrations regardless of what language you are using so the extra one time effort to get things working smoothly for Elixir is not that bad. This is also an area of strong focus of efforts to improve the tooling so I think it will get better in a reasonable amount of time.

whalesalad 8y ago

Why does everyone seem to be so upset about deployment? I can't comprehend the issue.

sb8244 8y ago
My experience has been painful at first (~1 week time to get setup), now takes 15 minutes to get a service deployed. Using Heroku (not good practice and I wouldn't use in prod), it would be really quick.
- bostonvaulter2 8y ago
  Heroku works fine in prod up to the scale of most pre-series A startups. There are a few limitations you have to accept but for us the easy deployment strategy (and existing suite of addons) makes it very easy.
  - sb8244 8y ago
    This is true, probably fine for smaller use cases. I cannot imagine doing a production Elixir app without node networking (I do quite a few things with it), and that is a deal-breaker for me on Heroku. That's really the only deal-breaker though. Docker for Heroku makes it really easy to ship artifacts rather than source which I think is important as well.
dudul 8y ago
Because there is no agreed upon way to properly do it yet. I tried using Elixir 2 years ago in production, and while the language is great, deploying (and runtime configuration) was a nightmare. It was 2 years ago, I know the community tried to improve things, but it's still not there. I read some excerpt of the upcoming book "Phoenix in Action", and in chapter 1, the author himself mentions "deployment" as a drawback of using Phoenix since it's still painful.
- burky 8y ago
  I'm curious as to what was a nightmare about the deployment and runtime configuration. Would you mind sharing your experience? Even better, post your concerns on one of the following sites and link back here. Sounds like it could be an interesting issue and I might be able to contribute. https://github.com/elixir-lang/elixir/issues https://github.com/elixir-lang/elixir/issues https://github.com/phoenixframework/phoenix/issues https://github.com/phoenixframework/phoenix/issues
  - _asummers 8y ago
    The general issues people have are around Application env, compiled System variables from build box in their configs, people forgetting that module attributes are compiled, and those sorts of issues. Libraries have begun moving away from Application env per library guidelines, and have begin moving to init/2 callbacks instead, which alleviates a lot of those issues, but there are a lot of straggler libraries that will not change for a while. So you have to do funky things like play with your Application env in your application.ex file. You had that weird system tuple thing that some libraries supported, and some that didn't, and then things like Confex coming up to meet in the middle. There isn't a nice story for getting secrets from something like Vault, for example. Releases are not mainline yet (soon!) and are kind of off to the side in a semi-officially supported way (bitwalker is amazing!). There are guides for this, but not the same type of guides as would exist if it were in the core repos. Then you have hot code reloading, which exists, but is usually said to be shied away from generally, so there's even fewer guides about all the gotchas that come with those sorts of systems. Some people even run mix phx.server on their prod boxes! I LOVE this language, and all these problems have solutions and workarounds, but one can't tell the story without being honest about the current release/deployment quirks. Things are definitely better than they were a few months ago, and much better than a few months before that. But they're not quite at the level they need to be for something that's supposed to be so fundamental to your application as its configuration and release. They'll get there.

Exuma 8y ago

What is elixir lacking in terms of timezones and timestamp formatting? Examples?

nickjj 8y ago

Why not just use the Timex library for now? Then timestamps and timezones are in good shape. Even as a newbie to the ecosystem it didn't take long to discover that time functionality was lacking in Elixir but the Timex library makes that a solved problem with little effort. Looking forward to seeing what comes up in the standard library for that in the future.

freedomben 8y ago
I've had a great time with Timex (pun not intended). I hope it gets merged into the language as is its goal.

passer-by-123 8y ago

While I agree deployment is probably the major pain point, I don’t see a reason to add time zones or time formatting to Elixir, given those problems are well solved in the community with the Timex and Calendar packages. I prefer the Elixir standard library to continue small and focused.

angersock 8y ago
Time and timezones are basic functionality used in almost any app of substance. A modern language should have first-class support for these things. :|