
Elixir 1.9 - mischov
https://elixir-lang.org/blog/2019/06/24/elixir-v1-9-0-released/
======
nickjj
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).

~~~
sansnomme
The Authn/Authz story of Phoenix is a joke though compared to Rails/Devise or
Django. The framework authors refuse to ship a first party implementation and
instead leave it to the community. Problem is, the ones available are mostly
extremely low level (ueberauth, guardian etc.) and you have to spend ages
customizing it. On Rails it's literally two commands to set up user
registration, email confirmation, password reset. Despite its supposed Rails
roots, Phoenix has a long way to go (the greater irony is that the company
behind Devise, Platformatec, is also the company behind Elixir).

If you only need basic functionality and absolutely have to use Phoenix, Pow
is a good choice:

[https://github.com/danschultzer/pow](https://github.com/danschultzer/pow)

~~~
pbowyer
> The Authn/Authz story of Phoenix is a joke though compared to Rails/Devise
> or Django. The framework authors refuse to ship a first party implementation
> and instead leave it to the community.

I agree, but it's not unique to Phoenix. In the PHP world the otherwise
excellent Symfony framework is only starting to add generation of
authentication/authorization, and email confirmation and password reset
remains the developer's responsibility.

I see two reasons for this.

1\. Frameworks see themselves as building blocks, not RAD systems. When the
core framework developers are (mostly) working on APIs they don't see the need
for approval/password reset. After all "you'll issue the user with a JWT so
who cares about the rest (shrug)"

2\. Flexibility to auth with anything. Apparently not bundling a system makes
it more "flexible".

I believe (1) to (a) be shortsighted and (b) we need RAD frameworks, of
higher-level flexible components that can be bolted together.

I believe (2) is wrong, and bundling standard auth flows does not reduce
flexibility: you implement your own if you need something else.

~~~
conradfr
That's partially true because you have FosUserBundle as kind of defacto
standard for user facing auth (but yes it's a community package) and many
built-in things for APi auth.

~~~
pbowyer
FosUserBundle is no longer recommended, and is superseded by Guard. Guard is
considerably nicer to work with, and doesn't take long to build the extra bits
(password reset etc) but (a) it's not built-in, and (b) if done as a bundle,
it doesn't get the same level of support.

------
ashton314
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!

~~~
jerf
"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.

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

~~~
derefr
A difference with Java is that new Java releases tend to come with changes to
the JVM. The language's semantics and the abstract machine are intertwined in
a way where the JVM might be changed to enable a new language feature, or
vice-versa. And the JVM itself improving is pretty much always an unalloyed
good, so people tend to look forward to releases of Java to see what JVM
improvements it has in store.

Elixir doesn't hold the same position for its abstract machine. BEAM, the
abstract machine, has its development intertwined with that of _Erlang 's_
language development, but not-so-much with Elixir's. Elixir can stabilize
while BEAM+Erlang continue to evolve "underneath" it. Given that Erlang syntax
is pretty much† always valid Elixir syntax, Elixir doesn't even need to change
to expose new Erlang stuff!

† There were big changes when maps were introduced, but another change of that
scale seems unlikely at this point. (Unless Erlang gets a mutable byte-array
type or something.)

~~~
pjmlp
Unless you are using Android J++, then you get some Java features at the
expense of de-sugaring.

------
atonse
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.

~~~
josevalim
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...](https://hexdocs.pm/mix/Mix.Tasks.Release.html#module-hot-code-
upgrades) \- 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.

~~~
atonse
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.

------
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.

~~~
josevalim
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
How does `mix release` handle NIFs currently? Same architecture is assumed?

~~~
di4na
Yes, basically it does not. It is up to the NIF packager to package a working
way to handle that.

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

------
KingFelix
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
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
This is awesome, Cross-section is what I am also looking for.

Appreciate the input, thank you!

~~~
PopeDotNinja
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/3dec7028b05bd10f6ff3180d199...](https://gist.github.com/amorphid/3dec7028b05bd10f6ff3180d1992b7f8)

^^^ 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
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!

~~~
PopeDotNinja
My pleasure, I'd you want another Elixir reference examples, feel free to
email me. Email in profile.

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

~~~
josevalim
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...](https://github.com/hexpm/hexpm/blob/d015973e472af59644ee537f809cb004f284139b/Dockerfile#L62:L73)

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

~~~
josevalim
Not much of a guide but at least an example:
[http://blog.plataformatec.com.br/2019/05/updating-hex-pm-
to-...](http://blog.plataformatec.com.br/2019/05/updating-hex-pm-to-use-
elixir-releases/)

------
sergiotapia
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.

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

~~~
gamache
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
What's the benefit of a hot code upgrade vs a blue/green deploy?

~~~
di4na
speed. A hot code upgrade can deploy a whole cluster in a few seconds. Plus it
can keep states safe without rebalancing.

------
alskdj21
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
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.

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

~~~
AlchemistCamp
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)

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

~~~
di4na
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.

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

~~~
ashton314
Why not? The recursive call gets optimized away, so it's just as fast as a
loop.

