I'm still not a fan of tail regression, er, recursion.
Why not? The recursive call gets optimized away, so it's just as fast as a loop.
Elixir 1.9
51–60 of 174 posts
Re: Elixir 1.9
#52Fantastic. Congratulations to the Elixir team! Something striking from the release announcement: > As mentioned earlier, releases was the last planned feature for Elixir. We don’t have any major user-facing feature in the works nor planned. Part of me is a little alarmed—no one wants a language to stagnate. José makes it clear that this doesn't mean it's the last version: > Of course, it does not mean that v1.9 is th…
I guess Elixir is "done" then? What could be the downsides to this?
Lack of language improvement. Sure, you can do anything with macros, but then when you open some random open source library it may be using different macros (or macros that are named the same way but act differently) than those that you use. Putting something in the language forces everybody to use the same standard. It can be good and it can be bad.
Re: Elixir 1.9
#53Earlier quoted context omitted.
Wait, what? I wrote an Elixir/Phoenix webapp around 2015 and one of the major selling points was the ability to hot-upgrade code that was inherited from Erlang. What changed?
The problem with hot code updates is they can break your app if your structs change shape and are extremely hard to get right over a period of time. Best to do rolling deployments with Kubenetes or something...
Hot code updates can be challenging at times, but the decrease in deployment time and hassle for changes where it makes sense is definitely worth it, and using hot code loading for most updates doesn't prevent you from using a rolling restart for the updates where it's more appropriate.
If you're using distribution, there's a good chance you need to deal with messages from both updated and not updated nodes anyway, so handling different shapes from different versions is a skill you already need to have; it's just hot load exposes it at more layers than previously.
Since working in Erlang for several years, when I have to work in languages where hot loading is not easy or common, it's always frustrating. Throwing away connection attached state to update code is a hard choice that doesn't need to be.
Re: Elixir 1.9
#54This is great news! The deployment story has progressively improved since I started using Elixir in 2016, but the best way is to just have _one_ community blessed system. Distillery has helped a lot for sure, so it's nice that it's basically been rolled into the base elixir distro.
There are some comments below about Distillery vs Elixir releases, so I will hijack the root comment to add some clarifications. It was clear to both Paul (Distillery author) and the Elixir team that Elixir releases were going to be a subset of what Distillery provides. There is a good chunk of what Distillery does that is well established and that's what we streamlined and brought into Elixir. Some other areas were…
We've never actually done hot code upgrades yet before, although, like many Elixir/Erlang/OTP things, I feel confident that if I was required to do so, it would be easier than in most other ecosystems.
Similarly I suspect many users of elixir are doing the "boring" thing that we're doing – load balancer -> stateless web server(s) running phx -> DB server. And they'd probably be more than happy with this.
Re: Elixir 1.9
#55This is great news! The deployment story has progressively improved since I started using Elixir in 2016, but the best way is to just have _one_ community blessed system. Distillery has helped a lot for sure, so it's nice that it's basically been rolled into the base elixir distro.
> Distillery has helped a lot for sure, so it's nice that it's basically been rolled into the base elixir distro. That would be nice if it were true. However, for better or worse, Distillery was Not Invented Here, so what Elixir shipped with today is a reimplementation of the simple half of Distillery.
Which is fine for probably most of us using Elixir who do blue-green deployments behind a load balancer.
Although we should probably embrace this aspect of the ecosystem, (like with clustering of servers) I bet it's even easier than I can imagine.
Re: Elixir 1.9
#56This is great news! The deployment story has progressively improved since I started using Elixir in 2016, but the best way is to just have _one_ community blessed system. Distillery has helped a lot for sure, so it's nice that it's basically been rolled into the base elixir distro.
There are some comments below about Distillery vs Elixir releases, so I will hijack the root comment to add some clarifications. It was clear to both Paul (Distillery author) and the Elixir team that Elixir releases were going to be a subset of what Distillery provides. There is a good chunk of what Distillery does that is well established and that's what we streamlined and brought into Elixir. Some other areas were…
It seems like a pure win as long as there's still a zero downtime solution that doesn't rely on containers. I'm definitely looking forward to what gets built on top of 1.9 releases!
Re: Elixir 1.9
#57Earlier quoted context omitted.
Based on what I've learned from the Elixir forum, these new releases have "no support for hot code updates / appups / relups". This means that Distillery will remain the best choice for many of us, including myself. I have a very simple deploy process with Edeliver and Gitlab CI/CD that basically just consists of pushing or merging a commit to master that passes the tests. There's zero down-time and it doesn't requir…
Wait, what? I wrote an Elixir/Phoenix webapp around 2015 and one of the major selling points was the ability to hot-upgrade code that was inherited from Erlang. What changed?
I compare it to unwrapping a handfull of utility razors chucking them up in the air and saying "free razors!".
You CAN do hot upgrades, but many times the complexity of doing so far outweighs the benefits. For any non trivial app it makes updates/deploys to the app non trivial as well.
Re: Elixir 1.9
#58Earlier quoted context omitted.
I would be curious to know what makes this feature a major selling point. Aren't rolling deploys easier to handle? I'm not saying it's not a great feature, but honestly, it probably stopped being useful since Erlang/OTP was originally designed.
Hot code upgrades are one of the Erlang features that helps me keep headcount down on our operations team. Appcues is three years into running Elixir in prod, and we still have not had to set up blue/green deploys because the built-in upgrade and rollback feature is so robust. For the first year and a half of that, we had a single platform developer (hi!) supporting dozens of servers and hundreds of customers. Hot up…
yes, but they do come with a lot of cognitive load and sharp edges. For many apps they are simply not worth it.
Re: Elixir 1.9
#59Sorry if this is a dumb question, but how do releases fit into the deployment story with containers so prevalent these days? (As in why is this a benefit when you can just package code into a single container to ship it?) Is it that it works with hot code updates? Or it’s a more Erlang-sanctioned way of deploying code?
Fred Hebert was on the ElixirTalk podcast and mentioned speed of deploys as one advantage - no need to rebuild a bunch of VMs.
> From experience, we could deploy to a 70-node cluster in something like under 5 seconds by doing it in parallel. If you want to rotate your infrastructure... your deploy could be taking from 5 minutes to an hour depending on how fast the connection draining can be done.
https://soundcloud.com/elixirtalk/episode-145-feat-fred-hebe...
Re: Elixir 1.9
#60Earlier quoted context omitted.
Hot code upgrades are one of the Erlang features that helps me keep headcount down on our operations team. Appcues is three years into running Elixir in prod, and we still have not had to set up blue/green deploys because the built-in upgrade and rollback feature is so robust. For the first year and a half of that, we had a single platform developer (hi!) supporting dozens of servers and hundreds of customers. Hot up…
yes, but they do come with a lot of cognitive load and sharp edges. For many apps they are simply not worth it.
The cognitive load is quite low when deploying changes which only involve your app code (i.e., no dependency upgrades). My app has a few tens of millions of open websockets at a time, and it's worth it to me to avoid mass reconnects. I'm not everyone, but my use case isn't totally unique either.