Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elixir 1.9

elixir-lang.org

Post reply on HN
Print view View original

41–50 of 174 posts

Re: Elixir 1.9

#41

Post by KingFelix »

giaour wrote: post #38
KingFelix wrote: post #35

I know nothing about Elixir/erlang besides following installs for apps. I have used it, installed via ASDF on my Raspberry pi since dependencies weren't up to date. Can anyone provide a good place to start on where to get started with Elixir? I tend to learn by working on stuff and not just reading etc, maybe a step by step in elixir? I am going into the literature now as well Thanks in advance for any help!

Programming Elixir[1] has hands-on exercises throughout. The author also published a video course[2] with exercises. [1]: https://pragprog.com/book/elixir16/programming-elixir-1-6 [2]: https://codestool.coding-gnome.com/courses/elixir-for-progra...

Excellent! This is great thank you!

Re: Elixir 1.9

#42

Post by KingFelix »

foggyboi wrote: post #36
KingFelix wrote: post #35

I know nothing about Elixir/erlang besides following installs for apps. I have used it, installed via ASDF on my Raspberry pi since dependencies weren't up to date. Can anyone provide a good place to start on where to get started with Elixir? I tend to learn by working on stuff and not just reading etc, maybe a step by step in elixir? I am going into the literature now as well Thanks in advance for any help!

I learned by converting a simple Rails API that I had running to do one or two things into a Phoenix API. In my case, it was very eye opening both because it was basic ETL and because it was something that benefited from high concurrency. I especially recommend this approach because it gives you more or less the most complete cross-section of some basic data structures, some web stuff, and some database stuff via the…

This is awesome, Cross-section is what I am also looking for.

Appreciate the input, thank you!

Re: Elixir 1.9

#43

Post by losvedir »

As someone using Elixir full time for a couple years now, I'm very happy to see releases become first class parts of the language. Is there a migration guide for those of us using distillery currently? And if we're happy with our distillery setup, what are the advantages of moving to native 1.9 releases?

Re: Elixir 1.9

#44

Post by brightball »

gamache wrote: post #37
brightball wrote: post #31

Earlier quoted context omitted.

The maintainer of Distillery joined the Elixir team to develop releases IIRC.

This is incorrect. I'd feel a lot better if it were true!

Paul went to work for Dockyard with Chris McCord when they started working on this feature for Elixir (and still is).

If he isn't the one writing it, he's certainly been highly involved with the conversation.

Re: Elixir 1.9

#45

Post by josevalim »

losvedir wrote: post #43

As someone using Elixir full time for a couple years now, I'm very happy to see releases become first class parts of the language. Is there a migration guide for those of us using distillery currently? And if we're happy with our distillery setup, what are the advantages of moving to native 1.9 releases?

Not much of a guide but at least an example: http://blog.plataformatec.com.br/2019/05/updating-hex-pm-to-...

Re: Elixir 1.9

#46

Post by PopeDotNinja »

ha470 wrote: post #6

Sorry 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?

Building a container and building a release are quite similar in many respects, so if all you want to do to compile your Elixir app during a container build, a release might not give you very much. An Erlang/Elixir release has some goodies that you might be interested in, so I'd read up on those goodies to see if they are attractive to you.

Re: Elixir 1.9

#47

Post by fabian2k »

One part of releasing Elixir applications I never found a definite answer was how closely the build environment has to match the final environment where the release is deployed. The Erlang runtime is bundled with a release, and this part is platform-dependent as far as I understand.

If I'm writing an application that I'll only deploy myself I can of course match the environments exactly. But what about if I wanted to distribute an Elixir application to end users that might install it on all kinds of different operating systems and distributions? Do I have to build a release for OS/architecture combinations like Linux/64bit, Windows/32bit and similar? Or do I have to match each Linux distribution and windows version exactly? That would make it rather impractical to use Elixir to write software you give to other people, and don't deploy yourself.

Of course when I looked at this Distillery was the standard way to deploy, but it doesn't look like this part is any different with Elixir Releases.

Re: Elixir 1.9

#48

Post by josevalim »

atonse wrote: post #4

This 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 left out, such as a complete structure for setting up CLI hooks, and most notably, hot code upgrades.

The documentation explains some of the complexities behind hot code upgrades: https://hexdocs.pm/mix/Mix.Tasks.Release.html#module-hot-cod... - so I won't go over those. More importantly, during discussions with different teams and library authors, it was clear there is not a golden path for hot code upgrades. There are different approaches, with different gains and pitfalls, and it would be too premature to choose one as blessed.

So what is the path forward?

While Elixir releases don't do hot code upgrades by default, its whole structure supports it. We use the proper names and structure everywhere. But the front-end to start the upgrade is not there.

I have discussed with Paul the possibility of Distillery building on top of what Elixir releases provide with a more complete feature set. It doesn't have to be done by Distillery either. Maybe someone (or multiple people) will provide a smaller package that focuses on hot code upgrades. Then once we gather enough collective knowledge, we can choose if and how to proceed.

Still, I believe Elixir releases cover the majority of use cases out there. But we will know for sure over the next months. At least, by making releases part of core, we hope we are easing the learning curve for releases altogether, which we will naturally lead more people to explore hot code upgrades.

Re: Elixir 1.9

#49

Post by ashton314 »

ksec wrote: post #28
jerf wrote: post #25

Earlier quoted context omitted.

"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 )

Thank you. That's what I should have said. :)

Re: Elixir 1.9

#50

Post by josevalim »

timwis wrote: post #13
rkangel wrote: post #12

Earlier quoted context omitted.

There's a good 'why releases' section of the article. Even without the compilation and configuration stuff, it's easier to put the release bundle in something basic like an alpine image, rather than keep docker image versions and app in sync.

But the article says you have to run the release on the same OS/version that you built it on. So if you're running it on alpine, won't you need to build it on alpine, which suggests you'll need to configure your Dockerfile to compile it anyway?

You would have two images, one with all compile time dependencies, sources, etc, which you use to assemble the release, and another image with only the artifact (the release) and none of the rest. Hex (Elixir's package manager) is open source and uses this approach, which you can see here: https://github.com/hexpm/hexpm/blob/d015973e472af59644ee537f...
Post reply on HN