I'm still not a fan of tail regression, er, recursion.
Elixir 1.9
21–30 of 174 posts
Re: Elixir 1.9
#22Fantastic. 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…
Honestly I'm happy to see that they're gonna slow down a little bit. You need a certain stability for the language to become more attractive. Think that the book "Elixir 1.6" was only released a few months ago, and today we're already getting Elixir 1.9.
Yes, of course 99% of the book is probably still relevant and all, but I believe it is important to brand a language as having reached maturity and stability.
Re: Elixir 1.9
#23I'm still not a fan of tail regression, er, recursion.
good news: For 99.9% of use cases, you can use the Enum module.
Re: Elixir 1.9
#24Earlier 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...
You make it sound like setting up k8s is a walk in the park! I've used hot code upgrades in production for 3+ years, and we've had it blow up in our face perhaps twice. If you do canary deploys, it's not hard to control the blast radius.
Re: Elixir 1.9
#25Fantastic. 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…
"no one wants a language to stagnate"
In the sense of the language itself, I do. The language community should keep growing, libraries, frameworks, etc., but I'd like to see more languages qua languages declare themselves "done" sooner and more often, or failing a sudden cutoff, start seriously raising the bar on the next "new feature". There's a lot of good languages out there that were great in years 5-15 and then choked on all the features they kept adding to the core language.
Re: Elixir 1.9
#26Earlier 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?
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 upgrades are very, very useful.
Re: Elixir 1.9
#27Earlier 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?
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.
It's a difference in run time purpose.
With a single code base capable of having millions of processes running as the norm, some handling direct client requests and others handling in-progress work, data storage, holding open connections for transfers, etc...you get the capability to deploy without disrupting ANY of that.
Most run times can't do anything close to that. Think about all of those X million websocket benchmarks...now think about being able to deploy without forcing all X million to try to reconnect at the same time.
And it can do this while all of the nodes are connected and communicating with each other as well as the outside world.
For standard issue client server, it's not that big of a deal. You just separate the web parts behind a load balancer.
For background workers, long lived connections, web sockets, video/audio streams, file transfers (CDN)...it's huge.
Re: Elixir 1.9
#28Fantastic. 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…
"no one wants a language to stagnate" In the sense of the language itself, I do. The language community should keep growing, libraries, frameworks, etc., but I'd like to see more languages qua languages declare themselves "done" sooner and more often, or failing a sudden cutoff, start seriously raising the bar on the next "new feature". There's a lot of good languages out there that were great in years 5-15 and then…
"no one wants a language ecosystem to stagnate"
I used to be so happy when there was a new Java version every year, something new is good, something better is good, some hype is good. Now I am getting old I just want to use the same tools for the next 15 years. I mean it is not like most of the problem we are trying to solves were limited by the languages itself. ( Mostly the ecosystem around it )
Re: Elixir 1.9
#29Fantastic. 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…
Honestly I'm happy to see that they're gonna slow down a little bit. You need a certain stability for the language to become more attractive. Think that the book "Elixir 1.6" was only released a few months ago, and today we're already getting Elixir 1.9. Yes, of course 99% of the book is probably still relevant and all, but I believe it is important to brand a language as having reached maturity and stability.
FWIW, the new books they are releasing for Elixir and Phoenix are both titled "Programming Phoenix >= 1.4" and "Programming Elixir >= 1.6"
That they are willing to put that in a primary book title is pretty bold.
Re: Elixir 1.9
#30Earlier 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?
It was talked about a lot by people who were fans of elixir/erlang but hadn't really done much work with it (these folks are increasingly common in tech, confusingly so sometimes but good).
Digging deeper the line from folks using erlang/elixir "in anger" was always that it was a supported feature but the reality is that most people shouldn't do it and wouldn't need to for the hassle it has.