
Phoenix 1.4.0 released - rehemiau
https://phoenixframework.org/blog/phoenix-1-4-0-released
======
perishabledave
One thing worth highlighting in the post is that Phoenix now uses Ecto 3.0.
This latest version of Ecto separates Ecto's data mapping and validation from
Ecto's SQL adapters. Practically this means you can use Ecto's changesets when
you either don't need persistence or aren't using a SQL database.

Additionally there are a number of features that make Ecto 3.0 a great
release: [http://blog.plataformatec.com.br/2018/10/a-sneak-peek-at-
ect...](http://blog.plataformatec.com.br/2018/10/a-sneak-peek-at-
ecto-3-0-breaking-changes/)

~~~
_asummers
The best one is piping aggregate and other functions in queries!

Something like:

from foo in Foos, select: foo.id |> filter(foo.bar > 3) |> count()

------
ledgerdev
Been waiting for this release to start playing with Phoenix.

I'm super interested to see how liveview turns out. Can it be a game changer
and free us from JS framework morass? Anyone know if there's a public liveview
repo/work to look at somewhere?

~~~
chrismccord
There's no public repo yet, but I'd like to open it up soon. I've been ironing
out the details of the programming model before opening it up – namely nested
live views and how the remote client spawns and reconnects to the server
processes. I made solid progress last week, and posted a sneak peak of the
nested views and error recovery:
[https://twitter.com/chris_mccord/status/1059273315666350080](https://twitter.com/chris_mccord/status/1059273315666350080)

~~~
sergiotapia
absolute unit

This is terrific work!!!

------
sergiotapia
Thank you Phoenix team - changed my career for the better. My stress levels
dropped drastically since moving to Elixir and Phoenix.

Immutable language, blazing fast predictable performance, super quick test
suite, real-time capabilities that don't require gigabytes of RAM... the list
goes on.

~~~
wbeckler
There's not that many production elixir jobs out there. I'm hiring full time
remote or NYC elixir devs if anyone is looking to find this kind of
development experience. bill@stellaservice.com

~~~
Aduket
thanks for your effort, noted.

------
erik14th
Yay for webpack as default. My perception of phoenix is not only that it is
the best in class but that it also keeps getting better instead of bloated.

~~~
goliatone
Not to take away from your excitement or the validity of the change, but non
frontenders find webpack rather bloated. To be fair, I’ve met more than one
front-end developer with the same perception.

~~~
chrismccord
There's no panacea when it comes to front-end build tools, but the webpack 4
release vastly improved configuration and docs, which was a big reason for us
to make the jump. We've maintained the old brunch workflow for non-js pros,
where you place js in assets/js and css in assets/css and things Just Work™,
so folks fond of the old brunch way can continue to handle assets exactly as
before, but webpack will be used underneath. I also like to think we now
strike a nice balance between zero hassle asset bundling and professional
front-end engineers using phx.new and quickly getting to work.

~~~
rched
As a professional front-end engineer I thank you. The old system was a
constant pain point for me. Every time I started a new Phoenix project I
agonized over how to integrate the front-end workflow I liked with Phoenix.
This will be a big productivity win for me.

------
dudul
Kind of feel bad for this one: [https://www.manning.com/books/phoenix-in-
action](https://www.manning.com/books/phoenix-in-action)

Still a MEAP, and only covers up to 1.3

Elixir and Phoenix seem to have very fast release cycles. I don't know if it's
a good or a bad thing. It's great to add a lot of features, or remove the ones
that don't really work, but it also renders literature obsolete pretty
quickly.

~~~
chrismccord
This book actually should be in great shape since Phoenix 1.3 included the
larger re-org of project code. A book written for Phoenix 1.3 will be entirely
relevant for Phoenix 1.4. I think we had a total of two deprecations, with no
breaking changes. As another commenter said, our last major 1.3 release was
2017-07-28, so if anything, I would expect folks asking us to speed up the
release cycle a bit :)

~~~
dudul
Yes the book will probably be mostly relevant technically. But from a
marketing point of view, it's dead. If I know nothing about phoenix, I check
the website and see that the current version is 1.4, am I gonna buy the book
that covers up to 1.3?

Re: my comment about release cycle, you're right. It was probably more
applicable to elixir than phoenix.

------
jbhatab
I can't wait for telemetry. Better monitoring will be a huge addition to the
ecosystem!

~~~
ch4s3
Agreed, I'm pretty excited to wire up some prod apps.

------
sb8244
The Phoenix team has been very accessible for help and growth of the language.
Very happy to work with it every day and to be able to contribute back
occasionally!

------
samgranieri
And now I can't wait for Phoenix LiveView!

------
whitepoplar
Congrats and a big thank you to the Phoenix team! Any word on the previously
discussed metrics telemetry?

EDIT: Oops. Didn't read bottom of post.

~~~
lewapkon
It's mentioned in the article.

[https://github.com/beam-telemetry/telemetry](https://github.com/beam-
telemetry/telemetry)

------
rishav_sharan
Have a question for phoenix veterans. The server performance in benchmarks
like techempower have not been stellar, yet concurrency is one of its most
touted features. If i wanted to build an app like hackernews and host it on
digital ocean free drop, how many concurrent users can i hope to serve with
request latency less than 100ms. A rough ballpark figure here will help me
visualise phoenix's performance better.

~~~
conradfr
Sadly this thread didn't pick up much but I found this
[https://www.cogini.com/blog/benchmarking-phoenix-on-
digital-...](https://www.cogini.com/blog/benchmarking-phoenix-on-digital-
ocean/)

------
willyk
Big thanks and props to the team on this, very exciting! Looking forward to
pitching in on the guides or other areas where some contrib help may be
needed.

------
fastbmk
If BEAM/Erlang/Elixir is so great for web development, why the leading web
company Google would bother to develop Golang?

------
fastbmk
When you talk about BEAM supervision magic, you forget that in the end it's
just a regular process of the OS. If the BEAM's process is killed, supervision
magic won't work.

It's not any different from the Golang's process of the same nature.

------
fastbmk
LiveView technology won't work well with high latency internet connection. In
other words, on most mobile devices. Which is 50%+ part of the market.

Also there may be privacy concerns with sending every browser event to the
server.

------
bsaul
Is there any benchmark comparing two architectures , one using OTP, the other
using containers + kubernetes ( let’s say in go or java) ? In terms of
availability, performance, maintenance cost, etc.

~~~
pg_bot
You can use Docker + containers with OTP, they are not mutually exclusive.
Daniel Azuma gave a talk at the most recent Elixirconf about this subject.[0]

[0]:
[https://www.youtube.com/watch?v=nLApFANtkHs](https://www.youtube.com/watch?v=nLApFANtkHs)

~~~
ch4s3
I’ve been using ECS and it’s been a good way to write stateful apps that can
dump state on tear down ore crash and start back up and keep working.

------
jillesvangurp
Fun fact, Firefox used to be called phoenix. The rename happened over a
trademark for another product called phoenix (a database if I recall
correctly).

~~~
dagw
_The rename happened over a trademark for another product called phoenix (a
database if I recall correctly)._

They first renamed it from Phoenix to Firebird due to a trademark dispute with
Phoenix the BIOS company (which doesn't exist any more). They then promptly
got called out by Firebird the Open Source database project and eventually had
to change their name again to Firefox.

~~~
_asummers
That story is kind of funny.

"Let's call it Phoenix!" _gets sued_

"Uh okay, a Phoenix is like a fire bird right? That sounds pretty cool, let's
do that!" _gets called out_

"Okay well what's another animal we can use? How about fox?"

~~~
dagw
Yea, you'd think if you're forced to change the name of your product due to
the name clashing with and existing software project/company, you'd take some
time to make sure the new name you chose doesn't also clash with an existing
software project/company.

------
ilovecaching
I wonder what the biggest deployment of Phoenix is at this point.

I've written a few cowboy apps, but my professional Erlang experience has only
been with chat servers that do not use HTTP. I'm not sure if I'd choose Erlang
to build web services in. Cowboy is a single maintainer project, and Go has
had HTTP2 support for ages now.

~~~
enraged_camel
Please stop spreading FUD about Erlang/Elixir at every opportunity, thank you.

~~~
querulous
it's a legitimate concern. the only alternatives to cowboy for http2 are
chatterbox and ace which are both single maintainer and, as far as i know, not
in wide use (even by erlang standards). for http1 you have elli but it's also
never been widely deployed and it's unmaintained as of years ago

~~~
brightball
Not really. As mentioned elsewhere, there are many contributors to Cowboy and
major companies using it as well. Heroku, AWS uses it in Cloudfront last I
checked, Incapsula too.

~~~
querulous
heroku uses a fork of cowboy that diverged in 2013 and has less than 100
commits since then, including only 8 since 2014

cloudfront does not use cowboy

