
Phoenix 1.0 - arthurcolle
http://www.phoenixframework.org/blog
======
lpsz
If you were choosing today, would you recommend choosing Elixir over Go for
web/back-end development? Would you say Go is more suited for high-performance
command-line tools, and Elixir for long-term running stuff?

I'm an indie developer building such a back-end (social networking/chat
space), have full choice of language. Started using Go earlier this year and
mostly happy with it.

Should I switch to Elixir in my next iteration? Would it make me more
productive, or save me from various deployment hurdles in long-term?

(Please don't take this as one of those mostly aimless "Hey, is Ruby or Python
better?" type of questions. I hate those myself. I'm going to be investing
thousands of hours into Go at this point. Hoping for some serious pro-vs-con
discussion, hoping people who have architected something big in either
language could chime in -- such is the major plus of asking on HN.)

I tried Googling, and the best/most recent I found was this thread. [1]

[1]
[https://www.reddit.com/r/elixir/comments/3c8yfz/how_does_go_...](https://www.reddit.com/r/elixir/comments/3c8yfz/how_does_go_compare_to_elixir/)

~~~
namelezz
You are probably more productive in Elixir at the early stage of development.
However, I personally think Go would be better for long-term development
because it is statically typed.

You can read more about pros and cons of statically and dynamically type
languages [1]

[1]
[http://programmers.stackexchange.com/questions/122205/what-i...](http://programmers.stackexchange.com/questions/122205/what-
is-the-supposed-productivity-gain-of-dynamic-typing)

~~~
davelnewton
I've heard this argument before. For a long time, actually. But the kinds of
errors I have are only rarely related to type issues, and those are almost
always caught very early. YMMV, that's just been my experience.

~~~
niklasni1
Having worked with Scala a lot recently, I've found that the ability to turn
logic issues into type issues is an incredible gain for my productivity. OCaml
programmer Yaron Minsky summed it up nicely with the advice that you should
"make illegal states unrepresentable". He gives a good example of modelling a
network connection in [0].

Another example is instead of shuffling a bunch of bare UUID objects around
(or strings, for that matter) in a system where lots of different things have
a UUID, I can make a simple reference type for the IDs of different entities.
This way, calling a function that takes the UUID of one type of entity with
that of another can be a type error that's caught by the compiler instead of a
logic error that's caught by a unit test. This is cumbersome at best to do in
Java or C, and obviously impossible in Python or Ruby, but in ML-inspired
languages it's simply the most natural way to work.

[0] [https://vimeo.com/14313378](https://vimeo.com/14313378)

~~~
davelnewton
I wouldn't classify those as "type problems" but rather "using types to solve
problems". I have no issue with the claim that great type systems make some...
ahem... types of problems go away, although it's often trading one type of
complexity for another. My issue is with the claim that "long term development
is intrinsically better with static typing".

~~~
fghfghgfhfg
The type system, at least more powerful ones, encode a lot of intention and
more importantly, enforce it.

It might add some additional complexity in the first writing of the code, but
in return you eliminate whole classes of problems forever. It's not just the
initial writing that benefits (at some cost, admittedly), but all future
changes won't have those problems either. In the case the types themselves
need to change to account for expanded functionality or whatever, you again
pay some cost in complexity, but in return every place the new type would
cause problems you get a nice error.

The other thing to keep in mind is that whether or not these type are codified
in the language they're there conceptually. Just because you have to write
them down doesn't necessarily add complexity but is more like forced
documentation that can be used to eliminate who classes of problems. It's
difficult to see how this wouldn't intrinsically be better than so-called
dynamic typing.

~~~
Havvy
If you're talking about a good type system, sure. The type system in Go is
frankly terrible at describing the kinds of invariants and reuse we care
about.

I'd dare say that diaylizer (Elixir's optional but easy to use type system)
would lead to more maintainable code than Go's forced type system in the long
run.

~~~
davelnewton
That more or less sums up my view on Go in a nutshell.

------
oomkiller
After spending nearly 7 years in the Ruby and Rails ecosystem, I changed jobs
and have been working in with Elixir and Phoenix for nearly 3 months. I have
been very satisfied with the process. The community is amazing, the tooling is
unbeatable, and the quality and availability of open source libraries is
great, especially for such a young project. The future looks very bright for
Elixir and Phoenix!

~~~
ffn
Agreed. One of the many things that makes Phoenix/Elixir great for us
rails/ruby refugees is that it's built by other rails/ruby refugees. In many
ways, we have all the good things that our old masters DHH trailblazed with
rails, but at the same time, very little of the mess that also came with the
trail-blazing.

That being said, I do miss active_support though; Elixir's utility libraries
(fox, pipe, croma, etc.) doesn't yet have all the easy automagic that made
rails so simple to develop on.

~~~
aaron-lebo
I downvoted you and I wanted to say why:

1) Referring to DHH and others as a "our old masters" instinctively bothered
me.

2) While I appreciate that Elixir and Phoenix have Rails connections and can
learn from it, I'd prefer it not become just a place for Rails refugees where
it turns into a huge circle jerk about how Rails is terrible and Phoenix is
great (which happens all too often in communities).

Other than that, I agree. But we should start something new.

~~~
fredoliveira
I appreciate the honesty here, but don't see how this is a reason to downvote
his comment. His comment contributes meaningfully to the discussion.

------
houshuang
Phoenix and Elixir are really great tools. I spent the summer building a bunch
of interactive components for an EdX MOOC
([https://imgur.com/a/rAXVz](https://imgur.com/a/rAXVz)), and got to try out a
lot of Phoenix capabilities (channels/websocket support is great!), but also
using underlying Elixir/Erlang libraries for task-queues, email sending and
receiving, etc. Super stable, never able to get our server above a few percent
of CPU :)

~~~
tbrooks
Do you have any blog posts on task-queues and email sending/receiving? I'm
trying to learn Phoenix and Elixir by rewriting an app I have that does just
this.

Sidekiq has been great as a background worker, but I'd like to try concurrency
elsewhere.

~~~
houshuang
Just wrote something on [sending errors by
emails]([http://reganmian.net/](http://reganmian.net/)). The full code is
here:
[https://github.com/houshuang/survey](https://github.com/houshuang/survey),
including my job module
[https://github.com/houshuang/survey/blob/master/lib/job_work...](https://github.com/houshuang/survey/blob/master/lib/job_worker.ex).
The code worked well for me, mostly because it registers errors and retries (I
had problems with rate-limiting of Amazon SES), however it's not parallel
right now. I will probably rewrite it to have a single module that gets tasks
from the DB, and then dispatches it to workers, and I want to split it out
into a separate library.

Note that this was my first Elixir library and I was very much learning as I
went along. Lot's of code that I want to refactor and extract.

~~~
tbrooks
Wow, this is awesome. Thanks for sharing!

------
djm_
Congrats to the whole team!

It's also worth noting that Ecto [1], the core-maintained Elixir ORM-like
package, also hit v1 earlier this week and has backends for dealing with:
PostgreSQL, MySQL, MSSQL, SQLite3 & MongoDB.

[1] [https://github.com/elixir-lang/ecto](https://github.com/elixir-lang/ecto)

~~~
rattray
Can you talk about your experiences with Ecto? How does it compare to ORM's in
other langs, like Python's SQLAlchemy or Node's Sequelize?

~~~
rubiquity
Ecto isn't an ORM since Elixir isn't OO. Terminology aside, Ecto identifies
more as an Integrated Query Language in a similar vein as LINQ does in the
.NET ecosystem.

As someone who has used lots of ORMs I find the switch to a libary like Ecto
very refreshing. It has an intuitive and very composable querying API and
friendly DSLs for defining schemas and validations. These are the baseline
features of any database/modeling library and Ecto satisfies them nicely.

But by far my favorite feature that has come in handy is that Ecto's concept
of Repos does not couple you to a specific database. Unlike traditional ORMs
that couple your objects to a specific database (read: the my_cool_app
database in MySQL or Postgres) it's easy to support different databases within
the same type of RDBMS or different RDBMS entirely. Since all querying in Ecto
goes through Repo modules all you need to do is just create more Repo modules
and configure them accordingly.

For some people this feature might not sound useful but if you've ever worked
on an Enterprise or older app with multiple data sources or want to switch
from MySQL to Postgres, this is a killer feature. Doing this with Rails'
ActiveRecord is ugly, buggy, a pain and will bring you to your knees during
Rails upgrades any time there are major changes in ActiveRecord.

~~~
rufugee
I've worked with multiple ORMs (Hibernate, Rails ActiveRecord, and Grails
GORM), and I've always been able to easily switch betweens RDBMS's unless I
specifically decided to step out of the ORM and use a DB-specific feature or
query. I'm not sure what you mean here?

~~~
rubiquity
By switching I mean I want one query to go to this database and another query
to go to a completely different database at the same time. Can you do this in
other ORMs? Yes. Does it almost always involve a third party library that
monkey patches your ORM's connection pool? Yes.

~~~
rufugee
Ok, that's more clear. I've only had to do this once, and I did indeed use a
third-party plugin that monkeyed all over.

------
ffn
This is awesome! I've been working with Phoenix for a bit now, and aside from
the fact hex/phoenix doesn't yet have all the libraries that rubygems/rails
have, Phoenix has blown my expectations out of the water. For such a big and
complex framework, the entire functional plug system (functional is love,
functional is life) makes the whole thing easy to grok in a way utterly
unimaginable in a traditional rails framework.

By the way, in case core team is reading, what's the motivation behind
removing infer_model_view from the render functions?

~~~
rdtsc
I haven't done much either with Elixir or Ruby (I do more Python and Erlang).
But one thing I noticed is Valim (and others on the team) created a really
approachable langauge and framework. Their emphasis on new comers,
documentation, friendliness of community is outstanding.

Also Elixir will bring more people to the BEAM VM and take advantage of it, as
I think it is a gem of engineering.

~~~
angersock
It's great having new people, but hopefully we'll avoid the clusterfuck of
gems and node modules that are the hallmark of the perpetually-immature web
development community.

~~~
rubiquity
I know you're being downvoted but I 100% agree with you. I don't want 100,000
Hex packages. I want a few thousand packages that solve problems really well
and people rally around and collaborate on them. NPM and RubyGems are
casualties of people seeking open source fame and I hope we can avoid that in
Elixir.

~~~
MrBra
This is totally nonsense. Any among those 100000 could become the most used
library in their specific field at some point in time, and the fact that you
can choose to contribute to whichever you like more, or create your own is the
beauty of OSS. If you fear this will weaken devs ability to focus their
strength on just one common solution, and be inefficient, then you really
don't know how OSS works. What you want to impose, is something that already
happens spontaneously in OSS (one gem taking over the other, unless they
provide very different features or to do things in a drastically different
manner).

~~~
angersock
Counter-argument: the entire Javascript ecosystem.

------
pbreit
When people choose to build on a more esoteric language such as Elixir (and to
lesser extent Erlang) is it because what they want to do simply is not
possible in Ruby/Python/Go/JavaScript/etc or just less efficient, elegant,
productive, etc?

~~~
erokar
The latter. The virtues of Elixir is that it is a functional language with
immutable data structures, and that it does not support object oriented
programming (which I consider a feature).

~~~
sjtgraham
Erlang processes have state and you interact with them by sending them
messages. You can do OO if you want :P

~~~
dpeck
Oddly enough you can do OO with Erlang/Elixir in a more pure/better (to me)
way than you can with more traditional OO languages.

~~~
Havvy
That's because the core of OO (message passing to opaque things) is really all
you can do if you have a PID. In other more-traditional object-oriented
languages, they usually have defaults that let you do more than just send
messages - such as mutate the internal state directly in ways that the object
cannot detect.

------
wiremine
If you're new to Elixir, I highly recommend Dave Thomas' book "Programming
Elixir"

[https://pragprog.com/book/elixir/programming-
elixir](https://pragprog.com/book/elixir/programming-elixir)

From the website:

"You want to explore functional programming, but are put off by the academic
feel (tell me about monads just one more time). You know you need concurrent
applications, but also know these are almost impossible to get right. Meet
Elixir, a functional, concurrent language built on the rock-solid Erlang VM.
Elixir’s pragmatic syntax and built-in support for metaprogramming will make
you productive and keep you interested for the long haul. This book is the
introduction to Elixir for experienced programmers."

~~~
rodgerd
At an introductory level, Katie Miller's "Programming in Elixir" from LCA 2014
is a good talk:
[https://www.youtube.com/watch?v=uWSGBpW3xEQ](https://www.youtube.com/watch?v=uWSGBpW3xEQ)

------
jonathonf
Ah, this is great. Hopefully now there won't be updates that alter syntax and
functionality with quite the same frequency! (check the 'Upgrading from...'
posts)

I'm pretty excited about Elixir and Phoenix. Building on Erlang's OTP should
mean scaling can be fairly transparent.

~~~
chrismccord
Rest assured that's the point of the 1.0 release. Those upgrading guides are
what it took to get here, but our APIs are all now stable. Enjoy!

~~~
angersock
Just in time for your workshop. :)

------
chrismccord
My NDC Oslo talk gives a nice overview of the framework, Elixir, and its
Erlang roots for those that want to evaluate the stack before jumping in
[https://vimeo.com/131633172](https://vimeo.com/131633172)

------
aren55555
FWIW the URL should probably be updated to
[http://www.phoenixframework.org/blog/phoenix-10-the-
framewor...](http://www.phoenixframework.org/blog/phoenix-10-the-framework-
for-the-modern-web-just-landed)

[http://www.phoenixframework.org/blog](http://www.phoenixframework.org/blog)
seems to point to the most recent post.

------
shaunxcode
What is the "tooling"
([https://www.filepicker.io/api/file/exQlE8JZQ2O2DaLm6cEA](https://www.filepicker.io/api/file/exQlE8JZQ2O2DaLm6cEA))
specifically called?

(edit: it is ":observer.start()" from inside iex (elixir repl)
[http://blog.plataformatec.com.br/2015/06/elixir-in-times-
of-...](http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-
microservices/))

~~~
tednaleid
That's the Erlang "observer". You can launch it from an iex (elixir) console
as simply as: `:observer.start` and see your currently running process. It's
super powerful for seeing the state and organization of your current
application (though a little ugly). It can also be used to monitor remote
nodes easily, kill processes, view state, see application load, etc.

------
elevenfist
Can anyone break down how phoenix compares to meteor?
Advantages/Disadvantages? Let's say I'm a CS grad, not a layman.

------
jerelunruh
I primarily use Django REST Framework for APIs... has anyone moved from Django
to Phoenix and can give a report on how the developer productivity compares
currently? If it's not there yet I'm sure it will get there as the community
grows but how is it now?

~~~
djm_
Phoenix is more like Flask in that regard and definitely doesn't come
batteries included like Django (no auth, no admin, no cache backends etc) so
it would be more work to build something as full-featured as DRF on top of it.

Having said that, I've found it easy to get along with retuning JSON and the
actual speed of responses is incredible. Completely anecdotal and unscientific
but one service I recently converted from DRF to Phoenix saw drops in avg
response time of 350ms to about 15ms.

------
tortilla
Awesome! Great work Chris and Jose and everyone else.

Getting my feet wet with a few side projects and am really loving Elixir and
Phoenix. Performance is great and I don't miss too much compared to Rails. I
still love Ruby and Rails, but will most likely default to Phoenix/Elixir for
most future projects.

------
rdtsc
Great work Chris, Valim and everyone else involved.

I like the screenshot of htop on the front page with all CPUs working along.
And a shoutout to the Erlang's Observer tool as well, to inspect the running
system and show process dependencies.

------
mands
Slightly off-topic, but can someone familiar with both Elixir and Erlang
explain what Elixir provides in comparison to Erlang.

I'm looking into using Erlang for a new project that requires extensive
scaling and concurrency and am coming from a functional background so may be
more comfortable with the traditional Erlang syntax. However it seems that
perhaps more development and activity is happening on the Elixir side of
things and it may be more productive in terms of tooling, libraries (such as
Phoenix and Ecto), and support.

Thanks!

~~~
unoti
> can someone familiar with both Elixir and Erlang explain what Elixir
> provides in comparison to Erlang.

The syntax is nicer, but that's just a bonus. The real game-changer to me
about Elixir vs Erlang is its macro system. This gives you runtime code
execution and runtime code generation, similar to what makes LISP to powerful.

There's a large amount of boilerplate involved in creating an OTP server, as
you know if you've done any Erlang. Elixir's macro capabilities completely
eliminate all the boilerplate.

The source to both Elixir and Phoenix are quite elegant and educational to
browse, and demonstrate this runtime code generation aspect very well. It's
straightforward in Elixir to introspect code, represent that code as data
structures, manipulate those data structures, then generate or execute that
code, as you can in LISP.

Elixir also gives a number of excellent tools that streamline the support
process over vanilla Erlang. For example, Elixir's runtime tooling
automatically manages dependencies for you (similar to node's npm), and
automatically maintains the application string that you need to provide for
all OTP applications. It also has improved capabilities for testing, which are
also made possible by the amazing macro generation capabilities.

> I'm looking into using Erlang for a new project that requires extensive
> scaling and concurrency and am coming from a functional background so may be
> more comfortable with the traditional Erlang syntax

Elixir's syntax is still just as functional. They support a regular if
statement, unlike Erlang, but generally it's just as functional as Erlang.
Elixir eliminates a number of needless chores from Erlang, such as having to
end some lines of code with a comma, and others with a period, and then
shuffling punctuation around whenever you add or remove lines of code. That's
a task I used to do literally a hundred times a day in Erlang that I don't
have to do at all any more.

~~~
vezzy-fnord
You can do reasonable metaprogramming in Erlang with the syntax_tools and
stdlib interfaces. Most famously was bringing back parameterized modules via a
parser transformation for tools like BossDB to support ActiveRecord-like ORM
patterns.

I've looked at OTP the Elixir way and I do not see any real boilerplate
reduction. The application-project dichotomy and the opinionated integration
with a tool like Mix is also policy over mechanism.

rebar3 does fine dependency management given its constraints of having to
unify packages coming from disparate sources.

The syntax is not nicer. It is a jarring conceptual mismatch to put Smalltalk-
ish Ruby syntax over a language that eschews excessive monkey patching and
dynamism like Erlang.

~~~
haddadell
> You can do reasonable metaprogramming in Erlang with the syntax_tools and
> stdlib interfaces.

You can also do concurrency in Ruby. It is not the same as doing concurrency
in Erlang though. The same way doing metaprogramming with syntax tools, parse
transforms and what not is nowhere close to a macro system.

> I've looked at OTP the Elixir way and I do not see any real boilerplate
> reduction.

So please look again? Take a look at Elixir's agents or tasks and explain how
it doesn't lead to more readable and cleaner code than the GenServer
equivalent in Erlang for the cases they fit. You could maybe point other
criticism but saying "no real boilerplate reduction" just shows you didn't
really try or care to give it a try.

> It is a jarring conceptual mismatch to put Smalltalk-ish Ruby syntax over a
> language that eschews excessive monkey patching and dynamism like Erlang.

This sentence is specially ironic given that Erlang inherits from Prolog,
which is quite different semantically from Erlang, instead of using the more
tradicional ML families. Also Erlang is pretty much a very dynamic language.

I am a Haskell developer, I hate Ruby syntax and I programmed Erlang for a
year. I would still choose Elixir over Erlang any day mostly because of the
tooling, typeclass like polymorphism and the new abstractions (Task and
Agent).

~~~
vezzy-fnord
_The same way doing metaprogramming with syntax tools, parse transforms and
what not is nowhere close to a macro system._

I'd wager that's because no one has written tooling to make it compelling to
the common programmer. Same with release management for a long time, and hot
code reloading. I'd understand if you said that basic substitution macros are
nowhere close to actual AST macros, but Erlang has far more than that.

 _Take a look at Elixir 's agents or tasks and explain how it doesn't lead to
more readable and cleaner code than the GenServer equivalent in Erlang for the
cases they fit._

Those are sugar. It's not like you can't define your own behaviors in Erlang.
People do it all the time, there's so many good libraries that go beyond stock
OTP. I should really switch an entire language because of default libraries?

 _This sentence is specially ironic given that Erlang inherits from Prolog,
which is quite different semantically from Erlang_

Only traces. The Prolog influence of Erlang is severely overrated by a lot of
people these days.

 _Also Erlang is pretty much a very dynamic language._

It ain't no Smalltalk. The runtime is very dynamic, and the typing is loose,
but the Erlang language itself not so much, which I think is a strength.

 _I am a Haskell developer, I hate Ruby syntax and I programmed Erlang for a
year._

Good for you, chap.

~~~
haddadell
> I'd understand if you said that basic substitution macros are nowhere close
> to actual AST macros, but Erlang has far more than that.

Fair point.

> Those are sugar. It's not like you can't define your own behaviors in
> Erlang. People do it all the time, there's so many good libraries that go
> beyond stock OTP.

There is a very strong point in providing those as default. If Erlang didn't
ship with a gen_server, we would see hundreds of different gen_server
implementations and no real consensus. By providing one, all Elixir developers
are familiar with it.

In a way, you could define everything Elixir provides as a sugar, after all,
it runs in the same VM. Sure, an Erlang library could provide all unicode
manipulation functions... but having it all sorted out for me is a great deal.
The same way Erlang solves many other things which makes it attractive to
many.

That leads me to...

> I should really switch an entire language because of default libraries?

No. But if it provides a really good standard library altogether (unicode,
structs, enumerable, etc) with an excellent tooling and powerful abstractions
(like protocols), then surely yes.

~~~
vezzy-fnord
_But if it provides a really good standard library altogether (unicode,
structs, enumerable, etc) with an excellent tooling and powerful abstractions
(like protocols), then surely yes._

I can't comment on excellent tooling. Language-specific package managers never
tend to be excellent, which is why I appreciate the limited scope of a tool
like rebar.

Again, you are overvaluing a language based on the libraries it exports,
rather than on its true _a priori_ merits. Some languages are designed for
intense extensibility and expressiveness, like Forth. An argument based on
laundry listing abstractions to dissuade someone from using it would be
rightfully dismissed as nonsense, since it is their prerogative to define the
threshold of abstraction they need.

Furthermore, I've noticed that people who tend to promote languages based on
the mere reductionist listing of abstractions tend to not understand those
abstractions well themselves, treating it as dark wizardry.

Erlang is definitely malleable to reasonable extensibility. See Erlando which
adds Miranda/Haskell-like monadic patterns to Erlang.

~~~
haddadell
Except I am not. What would be Erlang really without OTP? Would you really
want to implement all the building blocks in every new project? You are
dismissing the importance behind stdlib while defending a language that is
known specially because of its standard library (Erlang/OTP).

Also rebar3 is pretty much the same in scope as Mix (elixir tool). Which
proves the point you are criticizing Elixir while using the same criteria to
praise Erlang.

I am not saying Elixir is better or worse, just pointing you are extremely
biased in your comments.

------
happyfriend
Does phoenix require javascript, or just this announcement page? I see a big
block of text mixed with json... Not so good for noscript users and search
engines that don't load JS.

~~~
chrismccord
We use readme.io to host our guides and blog. They use angular I believe, so
maybe a hiccup on their end? Phoenix itself targets html/form, spa's, and
api's alike.

~~~
ryanSrich
Interesting. Any reason why it's not built with Phoenix? It seems like docs
would be a perfect use case for such a framework.

~~~
oomkiller
Building a custom docs app falls somewhere below "Getting 1.0 released" on the
kanban board, if I had to guess.

------
skrause
If this framework gets too popular they'll probably rename it to Firebird.
Let's just hope there isn't already another open source software called
Firebird.

~~~
k3d3
And then after that they'll rename it to Firefox

~~~
acheron
[http://tvtropes.org/pmwiki/pmwiki.php/Main/DontExplainTheJok...](http://tvtropes.org/pmwiki/pmwiki.php/Main/DontExplainTheJoke)

------
mccada
This is fantastic. I'm hoping for some book releases in the near future now
that the framework has reached version 1.

~~~
chrismccord
There are at least a few in the works that I'm aware of

~~~
gt565k
Could you provide some links / info on where we can find them?

Personally I've got a few books on elixir (one written by you), but I'd like
to get as many resources as possible for Phoenix.

~~~
chrismccord
Awesome. None have been publicly announced yet, but stayed tuned now that 1.0
is out

------
digitalzombie
Man I went to an Erlang meeting a year ago and all the people there were
talking about how to get Erlang to be popular.

I basically said look at Ruby, it shot up because of RoR. All erlang needs is
a good hype web framework.

Everybody in that room was like nope, the people can't see the power of Erlang
and Erlang only solve a niche problem or that web framework isn't the answer.

Uh huh. Phoenix is evidence that programming language needs a good framework
and a big user base that are hype about it. Sadly I don't see Erlang going to
get momentum as Elixir and I think it's a good thing. Erlang can do it thing
and Elixir can bring in more people on to the Erlang VM (BEAM).

------
cpjk
Congratulations to the whole team! Thank you for all your hard work! Phoenix
has so far been a joy to work with.

------
msandford
Does Elixir have any kind of signal processing capabilities ala numpy/scipy
for the Python ecosystem? I'm doing some stuff right now using a django/nodejs
hybrid system (glued together manually) and I'd love to be able to do
everything in one language. But the DSP support (seemingly) isn't there in the
javascript ecosystem yet.

I'd really love something built on erlang because of all the theoretical
problems that just don't happen because of the way it's built.

~~~
houshuang
There's very little in terms of analytics, statistics, machine learning
libraries etc. There also isn't a common dataframe like structure.

~~~
msandford
Not what I wanted to hear, but thanks for the reply.

------
ChuckMcM
Getting to 1.0 is really awesome. Although I have a lot of 'framework fatigue'
at this point, what would be really helpful for me would be why this framework
is better than the dozen other frameworks along any number of axes, say "time
to develop", "spinning up new developers", "obsolecence protection", anything
which would provide a compelling story why this instead of Angular or React or
Bootstrap or Eve or anything else for that matter.

~~~
chrismccord
I don't have time for a longer response at the moment, but Angular/React are
front-end frameworks, and Bootstrap is a css framework. In case you missed the
2nd sentence:

> Phoenix is set to take on the world whether you're building APIs, HTML5
> applications, or network services for native devices.

My NDC Oslo talk (linked in this thread) would answer your questions if you
have the time to watch it. I give a high-level overview of Phoenix, Elixir,
and the Erlang virtual machine and the virtues of how it all fits together.
I'll try to get back later with a broader overview.

~~~
ChuckMcM
Thanks Chris, my suggestion is that you link that talk on the announcement
page too, my guess is that other people who are looking at Phoenix for the
very first time since its now 1.0 will benefit from that information.

------
agend
reading the comments it's pretty clear that phoenix + elixir - it the best
thing since sliced bread. Usually it takes years and couple of versions - to
make it tick. But here - boom - 1.0 - everything works great - pretty
impresive

------
techpeace
Congrats on hitting 1.0.0! Thanks for all the hard work. The Elixir community
is producing some really exciting stuff.

------
akoder
Wow,excited to see this. I'm following phoenix since its 0.10 days and i'm
proud to say it has come a long way. Using phoenix source for tips and
guidance while im developing a web framework for Erlang (Entirely for learning
purposes). Amazing work team Phoenix. Hats off to you!

------
krashidov
Are there any libraries to help with authentication in Phoenix?

I couldn't find anything in the docs.

~~~
rickr
I haven't done much with Phoenix but I think there are a few libraries out
there. I think addict is the front runner:

[https://github.com/trenpixster/addict](https://github.com/trenpixster/addict)

[https://github.com/opendrops/passport](https://github.com/opendrops/passport)

Also here's a nice blog post that was in the elixir newsletter that may help!

[http://nithinbekal.com/posts/phoenix-
authentication/](http://nithinbekal.com/posts/phoenix-authentication/)

------
anderspitman
Man, we really are spoiled with some great languages and frameworks these
days.

------
bra-ket
not to be confused with
[https://phoenix.apache.org/](https://phoenix.apache.org/) (distributed
database)

~~~
staticint
Or to be confused with [http://website-
archive.mozilla.org/www.mozilla.org/firefox_r...](http://website-
archive.mozilla.org/www.mozilla.org/firefox_releasenotes/en-
US/firefox/releases/0.1.html) (web browser)

An interesting choice for a name of a software project, given its history.

------
thunderbong
Without javascript enabled this site is totally garbled. Since rendering is so
dependent on javascript maybe a noscript will help

------
thirdsun
I've been getting into serious production-ready web development for some time
now and Rails has been the tool that kicked things off for me. However Phoenix
and Volt are alternatives that have been on my radar recently and really
caught my interest. Glad to see it reaching this milestone. Congratulations!

------
tiffanyh
Should there be concern using Phoenix given the low performance rank of it on
the Web Framework benchmark? [1]

[1]
[https://www.techempower.com/benchmarks/previews/round11/](https://www.techempower.com/benchmarks/previews/round11/)

~~~
chrismccord
As noted on that page:

> WARNING: Preliminary data! Errors, anomalies, and other peculiarities should
> be expected.

We sent them a PR as their example app was doing things like html form CSRF
token generation, session fetching, and heavy logging, - all for JSON apis.
Phoenix has pipelines to explicitly segregate these kinds of request overhead
when they aren't needed. They also used a very low database connection pool
size. Hopefully they merge the PR shortly, and re-run the tests to properly
represent us. See own series of benchmarks here:
[https://gist.github.com/omnibs/e5e72b31e6bd25caf39a#results](https://gist.github.com/omnibs/e5e72b31e6bd25caf39a#results)

------
yellowapple
The screenshot there seems to imply that Phoenix uses 6GB of RAM and pegs two
CPU cores for one controller action and the rendering thereof ;)

Congrats to the Phoenix folks; I'm pretty sure it's the first Elixir framework
to hit that 1.0 milestone, and that's a pretty big deal.

------
arca_vorago
Has anyone gotten Elixir and Phoenix talking with VoltDB via JSON/BSON or
anything else? That's something I've been working on but got distracted with
other projects.

Loving Erlang/Elixir/Phoenix, I really feel it is going to scale very well.

------
andersonmvd
As Jose was one of who contributed the most of RoR code and now is focusing on
Elixir/Phoenix, will the RoR community move to Elixir/Phoenix? I think so, as
Rails 5 doesn't seems to be that promising as one discussion here took place

------
gjaldon
In case anyone's interested, there's some screencast tutorials on Phoenix
[http://phoenixscreencasts.com/](http://phoenixscreencasts.com/) \- Not much
episodes yet though :)

------
dodyg
This is fantastic. It is now on my list to learn.

------
jdoconnor
This is great news. Side note: with a name like Phoenix, would it make sense
to start at 2.0? :)

------
vippy
Then you have to learn Elixir though.

Disclaimer: My needs are currently best served by isomorphic React.

~~~
haddadell
Oh, the horrors in having to learn a new programming language!

------
devty
very excited to see the development. hope to see many apps built using
phoenix.

------
beginrescueend
Way to go! Great work, team.

------
amelius
How would this compare to the NodeJS ecosystem?

~~~
davelnewton
Newer and smaller.

------
toephu2
...another new web framework?

------
RGamma
Way to go to ignore most basic web standards, too (JS disabled):
[http://i.imgur.com/HE3uH4Y.png](http://i.imgur.com/HE3uH4Y.png)

Please don't participate in the "modern web", thanks.

~~~
djm_
To be clear to anyone reading this who didn't read the rest of the thread: the
docs are hosted on readme.io (YC) and not with a Phoenix build. Readme.io have
stated they are working on a better nojs solution.

