
Phoenix 1.2 - sotojuan
https://github.com/phoenixframework/phoenix/blob/v1.2.0/CHANGELOG.md
======
chrismccord
Wow this news front-paged fast! I just tagged the commit, grabbed a quick
lunch, and I haven't finished drafting the official release announcement yet
:)

If you want to know what Phoenix 1.2 is all about, check my ElixirConfEU
keynote which demos Phoenix Presence:
[https://www.youtube.com/watch?v=n338leKvqnA](https://www.youtube.com/watch?v=n338leKvqnA)

José Valim and I were also on the changelog podcast talking about what's new:
[https://changelog.com/208/](https://changelog.com/208/)

~~~
davidw
That talk was super interesting. Thanks!

[https://haslab.wordpress.com/2011/07/08/version-vectors-
are-...](https://haslab.wordpress.com/2011/07/08/version-vectors-are-not-
vector-clocks/) \- are you sure what you described is a version clock, and not
a version vector? I'll readily admit to not having a thorough enough grasp of
both to feel confident in making that call.

~~~
chrismccord
I believe they are technically version vectors, which I've mentioned in other
talks, but I haven't been sure if the distinction is helpful and I haven't
been confident enough yet to explain the nuances. Will check out the link

~~~
davidw
Ok - the reason I ask is because when I needed to figure some of that stuff
out, I had more or less the same reaction you did in your talk. I'm still not
100% of everything :-)

------
dustinfarris
I'm 10-years Python/Django and making the leap to Phoenix. I can't begin to
describe how thrilled I am with the intelligence and warmth of this
community—something I always treasured at Django and was afraid of losing.

Phoenix 1.2 looks ready for prime-time! I just finished setting up a
continuous integration/deployment pipeline with edeliver and CircleCI and
couldn't be happier with how everything is fitting together.

Very excited for the bright future of Phoenix!

~~~
rattray
Thanks for sharing!

What are the biggest pros/cons you've encountered so far? What do you miss
from Django? What do you wish Django could copy from Phoenix?

~~~
dustinfarris
I'm still learning, but I've already noticed some incredible response times.
Phoenix is very fast. I wish I had actual numbers to give you that compare to
Django but I'm just not that far along yet.

Elixir as a language is very nice. This is my first taste of "functional"
programming and I really like it. Shifting my mindset from object-oriented has
been difficult, but I find the code I write much more straight-forward so far
for the types of apps I will be building.

What do I miss? Maturity. Django dotted its Is and crossed its Ts a long time
ago. I wouldn't say Phoenix is buggy at all—I think it is production ready—but
the recent work Django has been doing with things like Postgres libraries are
several steps ahead of where Phoenix is at today. Also, Django documentation
is bar-none.

There is nothing about Phoenix that jumps out at me and says "Django would be
so much better if it had this!" Maybe Presence will be one of those things,
but I have not had a chance to play with it yet. I am excited about how Elixir
(on top of Erlang OTP) scales horizontally with virtually no effort, which is
something that Python cannot replicate as easily without a lot of thought and
some sort of bolted on message db—and in the end, slower. The robust
concurrency story (and what that could mean long-term) is exciting to me.

~~~
MartinMond
I found Ecto to be one of the best Postgres libraries out there.

What do you miss from Django's Postgres libraries in Phoenix/Ecto?

------
Eclyps
Long-time rails guy here, really looking forward to playing around with
Phoenix soon. I keep hearing really positive things, just haven't had the time
dive in. I tried diving into react for a bit, but I found that it was really
hard to retain unless I was working with it every day. Lots of people are
telling me that the switch from Rails to Phoenix will be a lot easier though
(I hope so!)

~~~
anonyfox
You'll feel instantly at home in phoenix, since you know more or less what
MVC, migrations, ... are about.

Then you'll dig deeper into und the actual syntax (a week for rubyists before
it clicks?). Dont give up, its awesome.

Then you'll be productive right away. And then you'll discover what OTP
actually means in practice and be blown away. (Point of no Return)

And then you fully "get" what channels, distributed systems, umbrella-
refactorings and all the latest talks are about.

Phoenix as a whole is so advanced compared with everything else we have
currently its not even funny. I highly recommend the official book, it itself
is one of the best books in web dev i've ever read.

~~~
davidw
> And then you fully "get" what channels, distributed systems, umbrella-
> refactorings and all the latest talks are about.

I used Erlang on my last project, and it was an awesome fit for what we were
doing. It's a really great system.

That said... "don't drink too much kool-aid" \- Rails is fine for lots of
things, and continues to be fine. Not everyone needs a fault-tolerant,
distributed system, or web sockets or some of the other stuff where Erlang is
a win.

~~~
jasonpass
I agree with the "don't drink too much kool-aid" but you can also completely
develop and deploy Phoenix without worrying about distributed systems,
umbrella-refactorings, and so on. At least, I have. :)

This has been the whole appeal behind Phoenix: it truly is as productive as
Rails/Django but much more performant. Better throughput, faster boot times,
faster tests, etc. Fault-tolerance, channels and presence are the cherry on
top.

I have seen Chris keynote about the presence implementation and they seem to
have used really advanced techniques that I cannot not quite follow. Still,
this week we are going to deploy presence into production and all we really
care is that it just works (and without Redis or any other dependency).

~~~
davidw
> it truly is as productive as Rails/Django but much more performant

I'd be a little bit skeptical of both things: Rails has a huge, mature
ecosystem, and Erlang is often faster than Ruby, but is not a "fast" language.

[http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...](http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=yarv&lang2=hipe)

Where Erlang really shines is that it's running in a single Unix process, yet
can handle multiple things going on at once thanks to its scheduler (and not
have ugly code, because it's the scheduler doing the work, not the programmer
writing spaghetti). This means that generally, it's going to handle more
connections better and degrade more gracefully. This is a huge win for web
sockets where you have a connection sitting open and _not_ tying up a huge
Rails process. Although even there, I guess the Rails guys are working on some
new stuff that should help alleviate that problem.

Erlang is cool stuff, and well worth a look. I certainly enjoy working with
it. But be wary of throwing out Rails because "new! shiny!"

~~~
edpass
Jason's coworker here.

The Erlang benefits you have mentioned above also fully apply to regular web
requests and applications. One of Ruby biggest flaws (and consequently Rails')
is poor support for concurrency. And Phoenix performs well on all aspects
Jason mentioned because running tests, serving data, etc is all done
concurrently.

I was also skeptical at first. I've heard talks and benchmarks reporting
Phoenix is from 10x to 20x faster than Rails (like this one:
[https://gist.github.com/omnibs/e5e72b31e6bd25caf39a](https://gist.github.com/omnibs/e5e72b31e6bd25caf39a)).
After porting our authentication service to Phoenix (our first), we saw
similar gains with less CPU and memory usage (as well as better response time
averages and 99 percentiles). Our deployment infrastructure for this service
is now one fourth of what it was originally.

Other than that, Rails definitely has a huge ecosystem and that should be
taken into account by those planning to move to Phoenix. Honestly, it has not
impacted us in any significant way but YMMV.

------
lucidstack
Fantastic week for the Erlang/Elixir ecosystem!

Another thanks to the teams behind all these amazing releases, and
particularly (for this news) Phoenix.Presence and Phoenix.PubSub, for the wide
range of new exciting applications they'll have.

~~~
ghayes
Just bumped my servers to erlang 19, Elixir 1.3 and Phoenix 1.2. The erlang
and Elixir communities have done a great job shipping.

At my organization, I created our first internal service which uses Elixir and
Phoenix. I've had a number of both junior and senior devs come up to me really
excited about building on Phoenix and Elixir. It's rock-solid stable, fast and
fun to use. Props to José, Chris and the rest of the team for their continued
hard work.

------
vvanders
> [CodeReloader] The lib/ directory is now code reloaded by default along with
> web/ in development

Nice! I found the way Phoenix deals with iteration to be quite refreshing,
glad to see lib is now a part of this too.

------
bcardarella
I posted this in the Elixir 1.3 thread but also relevant here. If you're
looking to understand why you/your company may want to consider migrating from
Rails to Phoenix you can check out my RailsConf talk on the subject
[https://www.youtube.com/watch?v=OxhTQdcieQE](https://www.youtube.com/watch?v=OxhTQdcieQE)

------
rlbaker
Does anyone know if Programming Phoenix will be receiving an update for 1.2?
Are there any backwards incompatible changes in 1.2 or Ecto 2.0?

------
lsh
Phoenix is "A productive web framework that does not compromise speed and
maintainability."

~~~
mkesper
The readme doesn't even feature Elixir.

------
anonyfox
are the new calendar-types from elixir 1.3 already rolled into phoenix/ecto?

~~~
chrismccord
They are supported if you are on Elixir 1.3 since we ship with Ecto 2.0 out of
the box, but we are waiting to make them the default with the Phoenix
generators until we make Elixir 1.3 a hard dependency.

 _Edit_ : I was wrong! My comments will apply to Ecto 2.1. Life is confusing
living on the edge sometimes

~~~
quaunaut
Is there a good writeup on how to use them somewhere?

~~~
josevalim
Since that question is related to Ecto, I will take it. :) Right now it is not
possible to use the new Calendar types in Ecto. The plan is for Ecto v2.1 to
come in about a month, when v1.3 is a bit more stable, and it will introduce
the `:datetime`, `:time` and `:date` types that will map to Elixir's v1.3 new
Calendar types.

TL;DR - not yet, soon.

~~~
anonyfox
Sounds good! I am actually waiting for this exact feature before starting my
next project, since I have to deal with a lot of time range queries (all items
from the Last 48h, ...)

I really appreciate the work of you all!

------
wyldfire
What is Phoenix (in this context)? Since it took me a few clicks to figure
out, I'll share:

> A productive web framework [using node] that does not compromise speed and
> maintainability.

CORRECTION:

> A productive web framework [using elixir] that does not compromise speed and
> maintainability.

Apologies for incorrect info, I saw the "npm install" content in the
instructions and assumed it meant phoenix used node.

~~~
msie
Node? I thought Elixir was the underlying language/platform?

~~~
chrismccord
The tagline is definitely _not_ about using node :) We include brunch.io, a
nodejs asset builder, for our css/js building/bundling. Phoenix is first and
foremost and Elixir web and distributed systems framework, which is where we
get our productivity, speed, and maintainability.

------
findjashua
Phoenix looks great, but seems like it's focus is on serving html to websites
(like Rails). Is there something simpler for building REST apis for
mobile/single-page apps (like Sinatra)?

~~~
noam87
I have just started working on a serious Phoenix project after watching from
the sidelines for a while. It takes a completely different approach to Rails.
First of all there's no magic (everything is completely explicit). It's
extremely adaptable to different needs (JSON apis, real-time communication,
etc).

Also note: Phoenix is not so much a singular framework, it's more of a
collection of libraries (Plug, Ecto, etc.)... it's just that Elixir makes
cohesive communication between independent libraries so dead simple it "feels"
like a Rails-like monolith.

But once you actually look at the structure of the project, there's really not
a whole lot that's hidden "behind the scenes" like in Rails. You can just add
remove any of these components as you like.

Honestly give it a try. This is the first backend environment I've tried that
feels "right" (and man I've been searching); everyone else I know who's tried
it agrees. It's just a pleasure to work with.

So far every surprise has been pleasant!

