28 ms·

Elixir 1.9

458 points by mischov 7y ago

ing33k 7y ago
quite new to elixir ( still haven't deployed anything to prod ). interested to know, how the releases feture going to affect the way we deploy elixir/phonenix apps in production ?
- lawik 7y ago
  Previously most people used distillery. Now they'll use Elixir releases. Because it is pretty much the same solution but now moved into the language tooling itself.
- AlchemistCamp 7y ago
  You can simply "mix release" to build a release without using the Distillery library. There are some limitations, though, mentioned on the forums: https://elixirforum.com/t/elixir-v1-9-0-released/23366/4 https://elixirforum.com/t/elixir-v1-9-0-released/23366/4
bdibs 7y ago
Are releases supposed to replace Distillery? If so, are there any particular reasons to switch?
- lawik 7y ago
  I guess so, I imagine that's up to the maintainer.
  - brightball 7y ago
    The maintainer of Distillery joined the Elixir team to develop releases IIRC.
    - gamache 7y ago
      This is incorrect. I'd feel a lot better if it were true!
      - brightball 7y ago
        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.
        bitwalker 7y ago
        I was initially hired at DockYard to work specifically on releases and their eventual integration into core, but I am not a member of the Elixir core team itself :). In any case, that in itself is not really a relevant detail, since José and I talked frequently about the core implementation, so being on the core team wouldn't have changed much there.
- gamache 7y ago
  Elixir's `mix release` is intended to replace (or remove the need for) third-party packages like Distillery. However, it's not there yet, and Distillery is strictly more powerful at the moment. Notably, Elixir's release implementation does not support hot code upgrades. I use upgrades all the time, and won't be trying out Elixir's releases until this shortcoming is addressed.
  - KZeillmann 7y ago
    What's the benefit of a hot code upgrade vs a blue/green deploy?
    - di4na 7y ago
      speed. A hot code upgrade can deploy a whole cluster in a few seconds. Plus it can keep states safe without rebalancing.
atonse 7y ago
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.
- AlchemistCamp 7y ago
  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 require containers on the server. I'd also say that the "deployment story" wasn't any worse than Rails or other stacks in the past except in that people have a choice of having a stateful server. This is how I'm doing it now: https://youtu.be/-mm44ADU3kc?t=172 https://youtu.be/-mm44ADU3kc?t=172
  - superdisk 7y ago
    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?
    - dmix 7y ago
      OP mentions it's still entirely possible with other deployment libraries (Distillery). Just the one being newly packaged into Elixir 1.9+ by default does not yet support hot-loading...
    - andy_ppp 7y ago
      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...
ashton314 7y ago
Fantastic. 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 the last Elixir version. We will continue releasing shipping new releases every 6 months with enhancements, bug fixes and improvements. Elixir is remarkably extensible. When I was first getting acquainted with the language finding macros with all the expressive ability of a LISP blew my mind. Making powerful macros a core part of the language meant that the language could grow. That in my mind is the most important part of any language's long-term viability. Fantastic work all who contributed. Thank you for making a fast, functional, and fun language to work with!
- faitswulff 7y ago
  I guess Elixir is "done" then? What could be the downsides to this?
  - comboy 7y ago
    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.
    - deleted 7y ago
      [deleted]
    - derefr 7y ago
      There's a middle-ground stance that's pretty common in the Elixir ecosystem: five or six libraries get written to solve a problem over the course of a year or two, people play around with them, and then a common set of primitives gets factored out of those libraries and made into an interchange library that all those libs support. That interchange library can then be integrated into the Elixir stdlib—that's what happened with DateTimes in Elixir—but there's no reason it needs to be. It works just as well to just keep the interchange-type library as its own tiny little dependency that all these libraries pull in.
ha470 7y ago
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?
- rkangel 7y ago
  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.
  - timwis 7y ago
    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?
    - jschniper 7y ago
      With Distillery you can specify a directory for the ERTS so the release can be built on one OS and run on another. You just have to make sure ERTS was built on the OS that it will eventually run on.
    - arvidkahl 7y ago
      That is correct. But that can be multiple stages, and therefore separated concerns. Also, releases can be very small, after all the superfluous parts/symbols are stripped. Combine that with a fresh alpine image and you have quick-to-deploy containers.
    - josevalim 7y ago
      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/d015973e472af59644ee537f809cb004f284139b/Dockerfile#L62:L73 https://github.com/hexpm/hexpm/blob/d015973e472af59644ee537f...
sergiotapia 7y ago
They're moving config from each individual umbrella application to the root of the umbrella. Gotta love how the team keeps things simple and opinionated. These little choices add up to quite the developer experience.
xvilka 7y ago
Congratulations! Notably, they mention switch to Cirrus CI, because it supports FreeBSD also. I wish Travis[1], Appveyor[2], and Azure Pipelines supported it too. [1] https://travis-ci.community/t/freebsd-vms-support/2125 https://travis-ci.community/t/freebsd-vms-support/2125 [2] https://github.com/appveyor/ci/issues/2844 https://github.com/appveyor/ci/issues/2844
hackbinary 7y ago
I'm still not a fan of tail regression, er, recursion.
- dnautics 7y ago
  good news: For 99.9% of use cases, you can use the Enum module.
- ashton314 7y ago
  Why not? The recursive call gets optimized away, so it's just as fast as a loop.
- aeorgnoieang 7y ago
  Why not? I've always enjoyed it in languages that support it.
- pmarreck 7y ago
  I would perhaps agree that having to structure the code in such a way that TCO is "triggered" can be a hassle, but once you realize the pattern and learn it, it's not hard at all to refactor your code to trigger TCO. And it allows you to enjoy the semantics of an infinitely-deep stack without actually needing an infinitely-deep stack :)
KingFelix 7y ago
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!
- foggyboi 7y ago
  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 their db adapter of choice, Ecto, which is excellent. Each part can be a pretty steep (but fairly quick) adjustment depending on your background.
  - KingFelix 7y ago
    This is awesome, Cross-section is what I am also looking for. Appreciate the input, thank you!
    - PopeDotNinja 7y ago
      Don't forget to learn how to write a GenServer from scratch. I lot of people I've met who hop straight into Phoenix forget to learn the basics of GenServers (and processes in general). Here's a stupid example I whipped up: https://gist.github.com/amorphid/3dec7028b05bd10f6ff3180d1992b7f8 https://gist.github.com/amorphid/3dec7028b05bd10f6ff3180d199... ^^^ you wouldn't ever code it that way, but you should (in my opinion) know what each line of code is trying to do.
      - KingFelix 7y ago
        This is great, I have been teaching myself everything and there are a lot of day 1 things I learned way too late, this is extremely valuable, thank you!
nickjj 7y ago
If anyone is on the fence on learning Elixir / Phoenix (Elixir's most popular web framework library) please do yourself a favor and give it a shot. If you're on a time crunch and want the best bang for your buck on "why bother learning yet another language to write web apps in?" then watch this talk called "The Soul of Erlang and Elixir": https://www.youtube.com/watch?v=JvBT4XBdoUE https://www.youtube.com/watch?v=JvBT4XBdoUE I'm not affiliated with the language but I just want to throw out that I've been around since the Geocities era as a web developer and I haven't seen a tech stack or platform this well thought out and so in tune with what makes developing (and testing!) modern web applications an absolute joy. There's really something special here. I see myself sticking with it for 10+ years with 0 regrets. The best part about it is everything is ready today (and was before 1.9 too btw).
- neduma 7y ago
  That was exactly my thought when I went thru release notes.
- freehunter 7y ago
  My preferred way of learning a new language/framework is watching someone walk through creating a real app in that language/framework so I can see all the folders/files I need to touch and the thought process moving step-by-step. Unfortunately I haven't found much in the way of that for Phoenix, the stuff on Udemy is pretty outdated last time I checked. Any recommendations?
  - AlchemistCamp 7y ago
    That's exactly what I do at https://alchemist.camp https://alchemist.camp. Most the videos and all the intro-level ones are free. I've also put up about a hundred screencasts at http://youtube.com/alchemistcamp http://youtube.com/alchemistcamp.
    - PopeDotNinja 7y ago
      Looks like a cool site. I'll check it out. My Elixir is Good. My Phoenix is not.
losvedir 7y ago
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?
- josevalim 7y ago
  Not much of a guide but at least an example: http://blog.plataformatec.com.br/2019/05/updating-hex-pm-to-use-elixir-releases/ http://blog.plataformatec.com.br/2019/05/updating-hex-pm-to-...
fabian2k 7y ago
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.
- josevalim 7y ago
  Currently releases require the OS and architecture to match. However, Erlang/OTP does support cross compilation, so at least a possibility is there, it needs to be further explored: http://erlang.org/doc/installation_guide/INSTALL-CROSS.html http://erlang.org/doc/installation_guide/INSTALL-CROSS.html The other concern is packages with NIFs (native code) and they would need to be changed if they don't support cross-compilation yet. I believe Nerves, which is an Elixir framework for embedded, does a good amount of cross compilation too but they have a more controlled environment.
  - pmarreck 7y ago
    How does `mix release` handle NIFs currently? Same architecture is assumed?
    - di4na 7y ago
      Yes, basically it does not. It is up to the NIF packager to package a working way to handle that.
- SeanAppleby 7y ago
alskdj21 7y ago
As someone who's new to web dev, is there any incentives in going for Elixir than using those established languages(i.e. Node, Ruby)? Any book/sources recommendations?
- pmarreck 7y ago
  This is anecdotal but I have inadvertently created FAR fewer bugs in Elixir/Phoenix than I ever did in Ruby/Rails. A lot of that has to do with the immutability guarantees and the pattern-matching and the fact that everything is explicit without being wordy... everything in this language seems designed to make it easy to grok what the code is doing, and that means fewer bugs produced.
- prodiguy89 7y ago
  I used to work with rails before. While it is fun to build stuff with it, it comes with a set of bothersome headaches: - too much magic - slow and painful to scale - too much metaprogramming - no compilation, makes it easy to hide syntax errors - concurrency is absent - frameworks like rails are too bloated All these are addressed on the elixir platform, and there are more pros: - immutability - mostly purely functional - well defined modules with good documentation
hphamq 7y ago
Besides speed, what are the advantages of Elixir/Phoenix that a lot of fintech startups use them instead of Ruby/Rails?
- di4na 7y ago
  Failure handling. Load profile is slower but far smoother, it degrades far more nicely. It can handle stateful things and distributed systems far nicer, with a programming model that is really adapted to it.

458 points by mischov 7y ago

quite new to elixir ( still haven't deployed anything to prod ). interested to know, how the releases feture going to affect the way we deploy elixir/phonenix apps in production ?

lawik 7y ago
Previously most people used distillery. Now they'll use Elixir releases. Because it is pretty much the same solution but now moved into the language tooling itself.
AlchemistCamp 7y ago
You can simply "mix release" to build a release without using the Distillery library. There are some limitations, though, mentioned on the forums: https://elixirforum.com/t/elixir-v1-9-0-released/23366/4 https://elixirforum.com/t/elixir-v1-9-0-released/23366/4

bdibs 7y ago

Are releases supposed to replace Distillery? If so, are there any particular reasons to switch?

lawik 7y ago
I guess so, I imagine that's up to the maintainer.
- brightball 7y ago
  The maintainer of Distillery joined the Elixir team to develop releases IIRC.
  - gamache 7y ago
    This is incorrect. I'd feel a lot better if it were true!
    - brightball 7y ago
      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.
      - bitwalker 7y ago
        I was initially hired at DockYard to work specifically on releases and their eventual integration into core, but I am not a member of the Elixir core team itself :). In any case, that in itself is not really a relevant detail, since José and I talked frequently about the core implementation, so being on the core team wouldn't have changed much there.
gamache 7y ago
Elixir's `mix release` is intended to replace (or remove the need for) third-party packages like Distillery. However, it's not there yet, and Distillery is strictly more powerful at the moment. Notably, Elixir's release implementation does not support hot code upgrades. I use upgrades all the time, and won't be trying out Elixir's releases until this shortcoming is addressed.
- KZeillmann 7y ago
  What's the benefit of a hot code upgrade vs a blue/green deploy?
  - di4na 7y ago
    speed. A hot code upgrade can deploy a whole cluster in a few seconds. Plus it can keep states safe without rebalancing.

atonse 7y ago

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.

AlchemistCamp 7y ago
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 require containers on the server. I'd also say that the "deployment story" wasn't any worse than Rails or other stacks in the past except in that people have a choice of having a stateful server. This is how I'm doing it now: https://youtu.be/-mm44ADU3kc?t=172 https://youtu.be/-mm44ADU3kc?t=172
- superdisk 7y ago
  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?
  - dmix 7y ago
    OP mentions it's still entirely possible with other deployment libraries (Distillery). Just the one being newly packaged into Elixir 1.9+ by default does not yet support hot-loading...
  - andy_ppp 7y ago
    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...

ashton314 7y ago

Fantastic. 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 the last Elixir version. We will continue releasing shipping new releases every 6 months with enhancements, bug fixes and improvements. Elixir is remarkably extensible. When I was first getting acquainted with the language finding macros with all the expressive ability of a LISP blew my mind. Making powerful macros a core part of the language meant that the language could grow. That in my mind is the most important part of any language's long-term viability. Fantastic work all who contributed. Thank you for making a fast, functional, and fun language to work with!

faitswulff 7y ago
I guess Elixir is "done" then? What could be the downsides to this?
- comboy 7y ago
  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.
  - deleted 7y ago
    [deleted]
  - derefr 7y ago
    There's a middle-ground stance that's pretty common in the Elixir ecosystem: five or six libraries get written to solve a problem over the course of a year or two, people play around with them, and then a common set of primitives gets factored out of those libraries and made into an interchange library that all those libs support. That interchange library can then be integrated into the Elixir stdlib—that's what happened with DateTimes in Elixir—but there's no reason it needs to be. It works just as well to just keep the interchange-type library as its own tiny little dependency that all these libraries pull in.

ha470 7y ago

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?

rkangel 7y ago
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.
- timwis 7y ago
  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?
  - jschniper 7y ago
    With Distillery you can specify a directory for the ERTS so the release can be built on one OS and run on another. You just have to make sure ERTS was built on the OS that it will eventually run on.
  - arvidkahl 7y ago
    That is correct. But that can be multiple stages, and therefore separated concerns. Also, releases can be very small, after all the superfluous parts/symbols are stripped. Combine that with a fresh alpine image and you have quick-to-deploy containers.
  - josevalim 7y ago
    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/d015973e472af59644ee537f809cb004f284139b/Dockerfile#L62:L73 https://github.com/hexpm/hexpm/blob/d015973e472af59644ee537f...

sergiotapia 7y ago

They're moving config from each individual umbrella application to the root of the umbrella. Gotta love how the team keeps things simple and opinionated. These little choices add up to quite the developer experience.

xvilka 7y ago

Congratulations! Notably, they mention switch to Cirrus CI, because it supports FreeBSD also. I wish Travis[1], Appveyor[2], and Azure Pipelines supported it too. [1] https://travis-ci.community/t/freebsd-vms-support/2125 https://travis-ci.community/t/freebsd-vms-support/2125 [2] https://github.com/appveyor/ci/issues/2844 https://github.com/appveyor/ci/issues/2844

hackbinary 7y ago

I'm still not a fan of tail regression, er, recursion.

dnautics 7y ago
good news: For 99.9% of use cases, you can use the Enum module.
ashton314 7y ago
Why not? The recursive call gets optimized away, so it's just as fast as a loop.
aeorgnoieang 7y ago
Why not? I've always enjoyed it in languages that support it.
pmarreck 7y ago
I would perhaps agree that having to structure the code in such a way that TCO is "triggered" can be a hassle, but once you realize the pattern and learn it, it's not hard at all to refactor your code to trigger TCO. And it allows you to enjoy the semantics of an infinitely-deep stack without actually needing an infinitely-deep stack :)

KingFelix 7y ago

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!

foggyboi 7y ago
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 their db adapter of choice, Ecto, which is excellent. Each part can be a pretty steep (but fairly quick) adjustment depending on your background.
- KingFelix 7y ago
  This is awesome, Cross-section is what I am also looking for. Appreciate the input, thank you!
  - PopeDotNinja 7y ago
    Don't forget to learn how to write a GenServer from scratch. I lot of people I've met who hop straight into Phoenix forget to learn the basics of GenServers (and processes in general). Here's a stupid example I whipped up: https://gist.github.com/amorphid/3dec7028b05bd10f6ff3180d1992b7f8 https://gist.github.com/amorphid/3dec7028b05bd10f6ff3180d199... ^^^ you wouldn't ever code it that way, but you should (in my opinion) know what each line of code is trying to do.
    - KingFelix 7y ago
      This is great, I have been teaching myself everything and there are a lot of day 1 things I learned way too late, this is extremely valuable, thank you!

nickjj 7y ago

If anyone is on the fence on learning Elixir / Phoenix (Elixir's most popular web framework library) please do yourself a favor and give it a shot. If you're on a time crunch and want the best bang for your buck on "why bother learning yet another language to write web apps in?" then watch this talk called "The Soul of Erlang and Elixir": https://www.youtube.com/watch?v=JvBT4XBdoUE https://www.youtube.com/watch?v=JvBT4XBdoUE I'm not affiliated with the language but I just want to throw out that I've been around since the Geocities era as a web developer and I haven't seen a tech stack or platform this well thought out and so in tune with what makes developing (and testing!) modern web applications an absolute joy. There's really something special here. I see myself sticking with it for 10+ years with 0 regrets. The best part about it is everything is ready today (and was before 1.9 too btw).

neduma 7y ago
That was exactly my thought when I went thru release notes.
freehunter 7y ago
My preferred way of learning a new language/framework is watching someone walk through creating a real app in that language/framework so I can see all the folders/files I need to touch and the thought process moving step-by-step. Unfortunately I haven't found much in the way of that for Phoenix, the stuff on Udemy is pretty outdated last time I checked. Any recommendations?
- AlchemistCamp 7y ago
  That's exactly what I do at https://alchemist.camp https://alchemist.camp. Most the videos and all the intro-level ones are free. I've also put up about a hundred screencasts at http://youtube.com/alchemistcamp http://youtube.com/alchemistcamp.
  - PopeDotNinja 7y ago
    Looks like a cool site. I'll check it out. My Elixir is Good. My Phoenix is not.

losvedir 7y ago

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?

josevalim 7y ago
Not much of a guide but at least an example: http://blog.plataformatec.com.br/2019/05/updating-hex-pm-to-use-elixir-releases/ http://blog.plataformatec.com.br/2019/05/updating-hex-pm-to-...

fabian2k 7y ago

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.

josevalim 7y ago
Currently releases require the OS and architecture to match. However, Erlang/OTP does support cross compilation, so at least a possibility is there, it needs to be further explored: http://erlang.org/doc/installation_guide/INSTALL-CROSS.html http://erlang.org/doc/installation_guide/INSTALL-CROSS.html The other concern is packages with NIFs (native code) and they would need to be changed if they don't support cross-compilation yet. I believe Nerves, which is an Elixir framework for embedded, does a good amount of cross compilation too but they have a more controlled environment.
- pmarreck 7y ago
  How does `mix release` handle NIFs currently? Same architecture is assumed?
  - di4na 7y ago
    Yes, basically it does not. It is up to the NIF packager to package a working way to handle that.
SeanAppleby 7y ago

alskdj21 7y ago

As someone who's new to web dev, is there any incentives in going for Elixir than using those established languages(i.e. Node, Ruby)? Any book/sources recommendations?

pmarreck 7y ago
This is anecdotal but I have inadvertently created FAR fewer bugs in Elixir/Phoenix than I ever did in Ruby/Rails. A lot of that has to do with the immutability guarantees and the pattern-matching and the fact that everything is explicit without being wordy... everything in this language seems designed to make it easy to grok what the code is doing, and that means fewer bugs produced.
prodiguy89 7y ago
I used to work with rails before. While it is fun to build stuff with it, it comes with a set of bothersome headaches: - too much magic - slow and painful to scale - too much metaprogramming - no compilation, makes it easy to hide syntax errors - concurrency is absent - frameworks like rails are too bloated All these are addressed on the elixir platform, and there are more pros: - immutability - mostly purely functional - well defined modules with good documentation

hphamq 7y ago

Besides speed, what are the advantages of Elixir/Phoenix that a lot of fintech startups use them instead of Ruby/Rails?

di4na 7y ago
Failure handling. Load profile is slower but far smoother, it degrades far more nicely. It can handle stateful things and distributed systems far nicer, with a programming model that is really adapted to it.