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.

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

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

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.

Distillery is pretty much “the way” right now and the core team hired the guy that built it to flesh out the long term built in solution. He’s explained the various moving parts but the short version is that he’s aiming for portable binary style deployment.

Except, it's really not. Boring "MIX_ENV=production mix phx.server" works just as well, and you can trivially add the stuff to make logging into a node easier.

Everybody wants this tooling for deploying appliances when frankly we are almost all just doing boring webshit.

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/phoenixframework/phoenix/issues

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.

Oh I ran into some of those issues too. Getting runtime configuration variables can be a bit of a pain. But on the plus side, I added a tuple (MFA) option in a PR for a lib and Jose Valim merged it a few days later. Really helpful core team!

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.

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.

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.

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.

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

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.

Time and timezones are basic functionality used in almost any app of substance.

A modern language should have first-class support for these things. :|