Phoenix 1.0 | Hacker News Reader

Phoenix 1.0

phoenixframework.org

792 pointsarthurcolle223 comments

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

I don't know enough about the internals of the languages to speak on that, but here's what has influenced my decision on choosing Elixir:

Community: smart people (who I respect) in the Ruby community are getting really excited about (and choosing) Elixir. People like José Valim, Dave Thomas, Bruce Tate, Chris McCord, etc.

BEAM and OTP: The Erlang VM and OTP have been battle-tested at Ericsson. It's known for having 9 9's of reliability and scaled WhatsApp to millions of simultaneous connections.

HEX: like Rubygems was for Ruby, Elixir/Erlang has a budding package management system via Hex. Hopefully this becomes the canonical source for libraries.

Phoenix: Rails popularized Ruby and became the framework of choice for quickly and pragmatically developing CRUD apps. Phoenix has Rails-like conventions in building an Elixir app and has built in support for websockets. This framework is built for today's technology.

Syntax: Coming from Ruby, the Elixir syntax is approachable and understandable. It's easy to jump into without having much prior knowledge.

Kinda subjective, but those are reasons why I'm excited and choosing Elixir to build future projects upon.

One thing that attracts me to Elixir is what it doesn't have to do. Go had to start from 0, Clojure had to build FP on top of Java. If they work at all, it's a success.

By contrast, if Elixir just works, it's useless. Its functionality comes almost entirely from Erlang. Therefore its whole reason to exist is to make using that power more pleasant.

That's why, for example, Jose Valim has said "if you see a bad error message in Elixir, which makes you confused and does not help you solve the problem, pls open a bug report." https://twitter.com/josevalim/status/621933537009246208

Clojure built FP on the JVM, not Java. Elixir introduces language features onto BEAM. I guess I don't see the comparison making sense here.

Elixir's functionality comes from BEAM and the language, not Erlang.

Elixir actually compiles to the Erlang AST and thus is leveraging Erlang much more than it might seem.

I see; I thought it compiled to BEAM code directly. I'd wonder then if there's anything representable in the Erlang AST that can't be represented by Erlang itself; it doesn't look like it so far.

There's not - see docs for parse transforms. Erlang is homoiconic in the sense that it's parse tree is its own valid data-structure literal. This is also true for Elixir. The difference is the `quote` and `unquote` macros and a simpler parse tree format in Elixir, which makes meta-programming much easier than in Erlang from what I understand.

I have rarely read things that were that much wrong. Just because the code can be represented as a data structure, or just because the compiler is written in its own language, that doesn't make a language homoiconic.

I concur -> In computer programming, homoiconicity (from the Greek words homo meaning the same and icon meaning representation) is a property of some programming languages in which the program structure is similar to its syntax, and therefore the program's internal representation can be inferred by reading the text's layout. Wiki

Every language's syntax internal representation can be inferred by reading it's text layout. It's what parsers do and people can, too.

How "similar" internal representation needs to be to its textual version to be homoiconic is subjective.

In Erlang an expression:

    2+3.

yields this AST:

    {op,1,'+',{integer,1,2},{integer,1,3}}

You can strip line and type annotations (you could also easily add them to the Prolog example below), which will get you:

    {'+', 2, 3}

If you scroll down the Wiki page you cite, you'll see an example in Prolog, where this:

    X is 2*5

yields AST of this shape:

    is(_, *(2, 5))

The important similarity here is that all elements of ASTs are still first class objects in the language. You can manipulate them in their raw form with the same functions you'd use for manipulating any other data. In other words, once you have an AST, you don't need to evaluate it, it's enough to just read it.

This is not true for Python. An expression:

2+3

yields:

    Expression(body=BinOp(left=Num(n=2), op=Add(), right=Num(n=3)))

An AST here cannot be manipulated in its raw form here. To manipulate it - the representation itself - you'd have to parse it again or evaluate it to use special methods on AST objects.

So this is the practical definition of homoiconicity I came up with. You are of course free to disagree. I'm stressing "practical" here, because what I'm interested in is how easy it is to manipulate the AST to write macros. Homoiconicity for the sake of homoiconicity is of no interest to me.

PS. BTW, maybe I should base my argument on Lisp instead of Prolog. If you read the Wikipedia page carefully you'll see the part on Lisp says the same thing I do above.

Homoiconicity specifically means that the primary representation of the language is a datatype in the language itself; Erlang isn't that.

I don't find it particularly subjective, it's just what it means. According to what you're saying any language that can be parsed and manipulated by the language is homoiconic, since the AST can be represented by types available in the language, no?

> Homoiconicity specifically means that the primary representation of the language is a datatype in the language itself; Erlang isn't that.

Literal datatype.

And please, prove it to me that "Erlang isn't that". My examples above indicate quite clearly that yes, it is.

> I don't find it particularly subjective,

I was referring to the word "similar" which appeared in the definition of homoiconicity given by flackjap.

> since the AST can be represented by types available in the language, no?

Yes, if the datatypes used in AST representation have literal forms in the language. No otherwise.

You claim any language that can represent its AST using that language's literal datatypes is homoiconic?! No. I can represent an AST in array literals in essentially any language, and quite a few using object/hash notation. That alone does not make a language homoiconic. See, for example, the lengthy thread here: http://c2.com/cgi/wiki?HomoiconicExampleInJava

There's another constraint, as seen in the definition of homoiconicity from Wikipedia. I'll paste it once again:

> In computer programming, homoiconicity [...] is a property of some programming languages in which the program structure is similar to its syntax, and therefore the program's internal representation can be inferred by reading the text's layout. If a language is homoiconic, it means that the language text has the same structure as its abstract syntax tree (i.e. the AST and the syntax are isomorphic). This allows all code in the language to be accessed and transformed as data, using the same representation.

As I noted, a similarity is subjective, but I never claimed that it's not needed as a criterion. So, what I claim is that homoiconicity happens when the AST representation consists of only literal datatypes of the language AND the AST structure is "similar" to the original code.

That's it. And also:

> I can represent an AST in array literals in essentially any language

I doubt it, but that's irrelevant. Had you done it you'd essentially reimplement the language of your choice and then we're not talking about that language in general anymore, but about your implementation. What you say here is that "every language can be made homoiconic given appropriate AST implementation". And that's probably true, although I suspect it gets too hard to do in practice for more complex syntaxes.

May I ask where are you getting your strong convictions about homoiconicity from? If you read the Wiki page you'll notice the use of less than precise words, like "similar" or "Languages which are considered homoiconic include" and so on. The concept itself is not as clear-cut as you seem to believe and it's mostly defined by examples.

Also, you still didn't provide a convincing argument that Erlang is not homoiconic; you only claimed that "it isn't" and moved on.

EDIT: as an example of how subjective homoiconicity is take a look at Julia. Listed on the wikipedia as homoiconic, here are the details: http://docs.julialang.org/en/latest/manual/metaprogramming/ - if Julia is homoiconic, then Erlang and Elixir are too. And Haxe, and Dylan. Are they? I don't know, I'm not going to argue about this. As I said, homoiconicity is only interesting as a way of simplifying macro creation; any more discussion is honestly useless to me.

Elixir, in my experience, is a much more productive and powerful language. If you are a one-man-show I'd pick Elixir any day.

Here I am pimping my own stuff but I wrote a related article on this:

http://lebo.io/2015/06/22/the-unix-philosophy-and-elixir-as-...

Thanks, I actually read!

"The Go devs have since stated that they were surprised to see that a lot of Go converts were from dynamic languages like Python and not C or C++. Go still makes sense for a lot of apps ... somewhere, however, that has been extrapolated to the idea that Go is a good language for writing web apps."

I think this is the crux of the question. And heck, it's very easy to spin up a web server in Go, and so many intro examples focus on that.

And elixir/erlang are great for writing custom servers handling custom protocols.... but you're better off just dropping in Cowboy and working at a higher level.

Go is really compelling in producing a single-binary application... but for web apps, I think Elixir wins because it's working at a much higher level, and thus you're more productive.

That was a great read, thanks for sharing!

One thing I really like about Go is that the output is a binary. This significantly reduces some types of infrastructure complexity (deploy, CI, etc).

After a long stint as a python dev, I find myself seemingly almost subconsciously avoiding languages that require a ceremonial dance and some type of sacrifice to get all the various bits (dependencies, etc) in just the right place before the app will start up properly.

Elixir is easier to deploy than Python/Ruby. Since Elixir compiles down to bytecode all you need installed on a server is the BEAM (the name of Erlang's virtual machine). It's not as simple as a binary but is still a significant improvement over git-based deployments.

Wouldn't you have to pull the elixir source and then compile the bytecode on the boxes you're deploying onto?

Forgive me if I've missed something. I'm just getting excited about elixir at this stage.

We deploy using Erlang "releases", which bundle the Erlang vm along with your application and it's dependencies into a tarball with a script to run the application. You don't need to install Erlang on the target system, just unpack and run.

We use "mix release" to build the tarball, scp to the server and unpack, then run using an upstart unit which runs "exec su -s /bin/sh -c 'exec "$0" "$@"' myuser -- /path/to/deploy/directory/bin/myapp foreground"

It's pretty painless. We are automating with Fabric now, but will likely be switching to Ansible soon.

There's releases where you can build a tarball[0] or RPM[1] that includes your application byte code plus the BEAM. Here's how you can go about building, testing and deploying a release in the context of Phoenix specifically: http://www.phoenixframework.org/v0.13.1/docs/advanced-deploy...

Optionally, you could cross compile locally or compile on a build server and have the other nodes pull from there, same as you would do in Go.

0 - https://github.com/bitwalker/exrm

1 - https://github.com/smpallen99/exrm-rpm

AFAIK, bytecode compiled on one Erlang system runs on any other. Bytecode is stored in .beam files, and -AIUI- .beam files are always forward compatible.

However, I'm not sure if bytecode compiled with an Erlang version >=17.0 will run on earlier versions of Erlang if it makes use of maps. (Maps are a new type that was introduced in Erlang 17.0.) I should really test this.

Yes, and the standard Go workspace layout (and therefore not even needing a makefile) is great.

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

The presence of a type system definitely improves maintainability, however it is only one of many factors. Being C and Haskell both statically typed, are they equally suitable for long term development?

For example, Elixir is a more "strict" dynamic language than your usual Python/Ruby/Javascript. Data is immutable. There is no monkey patching. Most state changes happen explicitly via process communication. The macro system is compile-time which means nothing will pull the carpet under your feet at runtime.

Also long-term productivity is about actually maintaining your system in production. And Elixir leverages 3 decades of experience on that, using a runtime designed to build systems that self-heal and are fault-tolerant (I slightly explore this here: http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-...).

I don't want to give a yes or a no answer, I would just like to point out the line is much blurrier than that. It doesn't matter which type system you use, your code is going to have bugs or unexpected situations will arise, specially when we are talking about network. So knowing that your system system can heal itself is quite comforting.

Those are two complementary aspects. It is one of the reasons I would love to see a statically typed language succeed in the Erlang VM.

> The presence of a type system definitely improves maintainability, however it is only one of many factors. Being C and Haskell both statically typed, are they equally suitable for long term development?

They're both statically typed, but the type systems obviously aren't equal. I would argue that stricter types are in fact one of the main things that helps me be more productive in languages with MLish type systems compared to C which lacks e.g. generics and proper sum types.

That said, I find Elixir very interesting for the exact reasons you said.

They're both statically typed, but the type systems obviously aren't equal.

That was his point.

I suppose the main difference is the presence of algebraic data types. But does that even make sense without static typing?

Thank you for sharing. Hopefully, learning Elixir will be a great experience for me.

I've used both Go and Elixir so here's my thoughts:

Elixir/Erlang aren't your typical dynamic language. Elixir is compiled and has pattern matching. I catch a ton of bugs at compile time in Elixir that I would never catch in Ruby/Python/JS until runtime. Examples of these are misspelled variables/bindings/function names and pattern match that will never actually match. Those are really, really common time wasters all taken care of at compile time.

Now what types of errors in Go really hurt you? Race conditions at runtime. I have to be way more careful about that to where it was costing me a lot of time in very concurrent programs. Eventually you develop a paranoia. Go has better tooling to help with this now, but concurrency and a language that prefers pointers just doesn't mix well. In Elixir I don't worry about this because everything is immutable. Now that GOMAXPROCS defaults to NumCPU I think a lot of programs that looked race condition-free probably aren't.

As far as runtime goes, Elixir and Go are at the same mercy but Elixir has much better debubbing capabilities than Go thanks to Erlang.

If you want something that gets you closer to static types and you have the discipline to keep up with running it and maintaining your type annotations, there's always dialyzer.[0].

You can handle misspelled variables/bindings/function names in Ruby/Python/JS by linting. That's a class of errors that's easy to avoid anywhere with a good text editor.

Due to the extremely dynamic nature of Ruby, I'm not aware of any linter that can catch misspellings when interacting with class or instance variables, dynamically-defined methods, etc.

It's an entirely different level of statically-verifiable correctness.

I know of class/instance variables working for py linters. Dynamically-defined methods, no, but those are hard to reason about even for humans so it's best to avoid them entirely.

Pattern matching will only get you so far without static analysis, though?

For example, if I have a function that returns {foo}, and I change it to return {foo, bar}, then a pattern match on its return value that does {Foo} -> ... will fail at runtime, and the compiler won't pick it up, right?

In a statically type language (such as Go), changing the number (or type) of return values will result in compilation errors until all callers have been updated.

Elixir can be optionally typed with the Dialyzer which will bring you to about the same level of static typing as go (if not more because the dialyzer allows for generics).

With compile time checking that is already there + Dialyzer, you basically have the whole 'code correctness' side of static typing? Right?

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.

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

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

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.

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.

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

A type problem is any problem that types can solve for you. People who are exposed to very limited type systems consider the range of type problems to be limited. Still it is true that most of these problems are solved quickly and caught with unit tests - no one thinks that simple type problems are the source of your production bugs. A good type system is mostly a productivity play for me; I develop a little faster and I refactor MUCH more quickly and with less effort.

I'm pretty familiar with actually-good type systems, and as I've attempted to say, they do eliminate certain classes of problems. They just don't happen to be the types of problems I struggle with or find major productivity-burners. YMMV.

Orthogonal to all this is that I'm underwhelmed by Go's type system :/ If I was going to shoot for a language whose type system really helped me (in the ways I need/want help) it wouldn't be Go. It's pretty slick for some things (aesthetics aside) though.

If you haven't used a good type system (which has at least algebraic data types and pattern matching), it's hard to realize how many of those bugs might actually be type issues.

I'm not claiming that good type systems aren't useful, I'm claiming that the statement "Go is better for long-term development because it's statically typed" is more like FUD than actionable information.

I also agree that good type systems can reduce some forms of complexity (while often introducing another, but that's a different discussion).

All of our servers and daemons at Cronitor have been built using Python. I know you're asking just about these two languages but i would consider a language with a bigger library and user base. It takes discipline with language features but we've had a lot of success writing stateless daemons that are under heavy load 24/7. It's been far easier to think from a fan-out pov vs worrying about every clock cycle wasted by, for example, the garbage collector.

My advice would be to find out for yourself and don't believe the hype:

> Would you say Go is more suited for high-performance command-line tools, and Elixir for long-term running stuff?

Like Go isn't very high performance. See for yourself: http://benchmarksgame.alioth.debian.org/ (I know, lies, damn lies and benchmarks, but it's the best we got!). Elixir is it good for marathons because it's based on Erlang and Ericsson claims six nines uptime? Just use the tech you find is most FUN to work with because it's better to have fun programming than being bored.

Also it depends on the system you are building. Elixir and Erlang scale great and send messages even between servers fast! So if you need to scale it is great. Go I am sure is faster performance wiz but Elixir/Erlang will stay running longer and be easier to reason about as the system gets bigger. Go will be easier to find devs then Elixir/Erlang will be harder. So there are trade offs.

In the end you could use both, use the right tool for the job.

No, I won't! I would advice you to learn them both instead, they are on such opposite sides, than knowing both will expand your knowledge in a very fulfilling way.

Nice insight. Learning more languages, especially those that seem to be different, could widen one's perspectives, and able to avoid the issue of learning only hammer and treat all problems as nails.

Out of curiosity, which libs/frameworks are you using in Go? (that are web related)

Hmm, still in the exploratory-hacking phase. Rewrote various parts of what Gorilla provides for learning purposes, plan to switch to Gorilla.

Using "lib/pq" (Postgres) for the db.

Also: need to cache some computed data in memory, and reload using a REPL or other means, haven't figured out the most "batteries included" way to do so yet.

Also: need to figure out the most production-friendly way to redeploy code (sounds like Erlang/Elixir can do really well in this regard.)

> Also: need to cache some computed data in memory, and reload using a REPL or other means, haven't figured out the most "batteries included" way to do so yet.

Elixir does nicely here, too. For caching, ets[0] tables are very easy to setup. For reload, you can use IEx to connect to a remote node and do whatever you need to do.

0 - http://www.erlang.org/doc/man/ets.html

> Hmm, still in the exploratory-hacking phase. Rewrote various parts of what Gorilla provides for learning purposes, plan to switch to Gorilla.

Good pick. The gorilla toolkit is definitely flexible. I typically use a mix of gorilla (context, csrf, schema) and Goji (routing, middleware chaining).

My 'hard and fast rule' is that everything needs to implement the http.Handler interface if I'm going to use it, so I don't get abandoned with a bunch of custom libraries that I need to refactor away from.

> Also: need to figure out the most production-friendly way to redeploy code (sounds like Erlang/Elixir can do really well in this regard.)

Most typically use the system's init daemon, and/or Supervisor/Circus/monit. I'm partial to Supervisor on that front for the cross-platform compat.

Relating to redeploying code, did you give https://github.com/codegangsta/gin a look?

Also, any particular reason to not use a web framework such as gin-gonic for routing and templating? It simplifies some things down for me.

Re: gin, thanks for the tip. I feel like this one makes more sense in development than in production, would like to avoid side effects (first HTTP request restarts the server), also an extra proxy layer.

Re: web framework. Absolutely, no intention to reinvent the wheel. Just informative to rewrite various pieces in the initial stages to get a better grasp on the language/patterns.

About gin, you're right, I think. But what else to use in case the app crashes? A simple shell script to restart the executable whenever it crashes (even though it shouldn't)? :) And what about hot code reloads? You'd have to stop the app for a second there, and replace the executable yourself. You'd also probably interrupt whatever the app was doing at the time, which could turn out pretty bad.

I use upstart to respawn if crashes, but there's definitely more than one way to solve this one :) Hot code reloads is the more interesting issue.

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!

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.

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.

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.

The flip side is that everyone is trying to write Ruby packages and projects in Elixir rather than thinking out of the box as to what is best for this new programming paradigm.

Hypothetically speaking, why would you choose Phoenix over Rails for a new app?

Phoenix shares many features with Ruby on Rails, e.g. a strong MVC model, an integrated ORM, a routing system, etc. What Phoenix on Elixir excels at is concurrency and distributed computing. For applications, this means you can have many active web sockets, for instance, where Rails applications tend to break down when you have too many active connections. Phoenix uses erlang processes for these tasks, which are lightweight and can number millions on a single machine.

As an example, Heroku uses cowboy (the erlang web server that Phoenix uses) for load-balancing incoming connections to all Heroku applications. The erlang VM (BEAM) is great for these types of highly concurrent, highly available, distributed tasks. The original use case for erlang was highly available phone switching for Ericsson.

This is very interesting as Phoenix could become the next Rails. I loved Rails and ruby, for the most part, but ruby MRI still lack 'Native Threading', and Jruby isn't viable if you are using external C extensions.

To overcome the lack, I've used Resque (or beanstalkd in PHP, which has the exact same problem) as a background job manager, but then I had to write my own layer and rely on the database to handle the 'job' result.

Which parts of the framework leverage the concurrency model, other than the routing/request handling part?

The best example is probably channels. The framework doesn't really have to provide you anything for you to be able to use concurrency. For a personal example, I was able to use RethinkDB changefeeds easily with channels: https://github.com/bbhoss/elixir_friends/blob/master/web/cha...

I just start another process when you join a channel, and that process sets up the changefeed and pushes changes to the client in the form of HTML, allowing messages to be received and processed by the channel. You can watch the full presentation here: https://www.youtube.com/watch?v=aWaleoYD1Ro Slides: http://www.slideshare.net/bbhoss/otp-phoenix-channels-rethin...

Another example is sending email. In Rails, you need to have something like Sidekiq (or now Activejob) to be able to background the job so it doesn't block the response to the client. In Phoenix, you can simply spawn a process to do the work and move on. Sure, you might want a system like exq to keep track of things a bit better, but ultimately the concurrency primitives provides by Erlang/Elixir allow you to do everything you need.

@oomkiller: again, so interesting, especially when used in combination with RethinkDB.

I'll have a look at the slides

Another example: I work on a Rails app where the user submits a request to us, and we have to talk to an API to respond. We can't afford to leave the connection open with the user, so we make them poll for results.

My understanding is that the cheap processes of Elixir would mean we could just keep a connection open to that user if we wanted to. Similarly, no need for a background processing framework like ActiveJob; just use processes.

That's right. Because Elixir is 10x faster than Rails, we don't need to worry about caching so much. And because it supports cheap concurrency, we don't need to offload long running tasks to a background task. So the overall structure is simpler.

And this works across the whole architecture. One of our projects right now is a mobile medical application for medical where caregivers communicate in real time with a number of patients. We have the mobile app talking to the server using a REST API and real time messaging for chat. The caregivers can communicate with the server using a web application with integrated web chat or via an XMPP client. And we have the normal public web and admin CRUD. All via a single server process in a single language. This is what Elixir/Phoenix was made for, it enables a new generation of modern apps.

What webserver are you using? Running puma in threaded mode, even on MRI, should allow your external API calls to run in parallel - this might simplify things a bit :)

Maybe so, but the fact that Rails includes Active Job shows that this is a common problem.

Better for building out services. Parallel processing. The supervised process abstractions are incredibly powerful.

If you're building another Twitter I would still use Rails. You'll be much more productive.

On the other hand, if you need to run parallel tasks or have mission-critical (aka can't go down for anything) work to be done I think you'll find Elixir the perfect combination of Ruby's syntax and Erlang's power.

Just my $.02 - I'm having a blast with Elixir at the moment.

Nah, if you really are trying to build the next Twitter Rails is a poor choice for architectural and scaling reasons. No need to repeat Twitter's own mistakes.

On the other hand, if you are just building another web app, Rails is the better choice...

I mean, if you're building an app for Twitter scale on day one you're already doing something wrong. But yeah.

Do you mind sharing what kind of project you develop? And even maybe what company you work for?

Can't say much about the details yet, but I work here: http://www.reactionhousing.com/ :)

Maybe a stupid question, but why would you need something like exilir?

I like Elixir because of its ability to do distributed computing, fault tolerance/HA, binary pattern matching, speed, and more. You don't need Elixir, but it makes a lot of stuff much easier to do.

That looks fun :)

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), 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 :)

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.

Just wrote something on [sending errors by emails](http://reganmian.net/). The full code is here: https://github.com/houshuang/survey, including my job module https://github.com/houshuang/survey/blob/master/lib/job_work.... 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.

Wow, this is awesome. Thanks for sharing!

If you're curious about the framework as well, here's the source for an app I made for peer-to-peer file sharing in Phoenix: https://github.com/hayesgm/fuego. You can try it out here: https://fuego.link

Phoenix has really been exciting to use. It's a great way to get introduced into the OTP system from Erlang (plus all of Erlang's modules), it's incredibly fast, and the immutable data structures make it easy to reason about your concurrent code. I would strongly suggest giving it a try.

Real realities. Can you believe it?!

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

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?

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.

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?

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.

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.

Personally, I have enjoyed using it. I prefer to stay closer to the SQL than perhaps most would and writing queries in Ecto felt a lot like SQL but with added composability.

Unfortunately, I don't have experience with using the ORMs you listed in anger so I can't make a direct comparison. Anecdotally, I have found it much nicer to use than Django's.

I've used Rails, but a long time ago. However, I really enjoyed Ecto; the migrations, the query interface etc. Still wrapping my head around changesets (I think it's quite simple, but when I began with Phoenix there were just so many new concepts).

Very exciting that they are branching out to support MongoDB as well. I'd love if they could support more untraditional Postgres operators for arrays and json (I guess there's always a tension between least common denominator and using the specialized features of each DB). You can get around it with partials, but it makes the code more messy.

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?

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.

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.

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.

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

Counter-argument: the entire Javascript ecosystem.

    > NPM and RubyGems are casualties of people seeking
    > open source fame and I hope we can avoid that in Elixir.

No, they're casualties of people actually using the platform, the platform's low publishing barrier, and the ecosystem's preference for focused libraries over monolithic bouncy castles.

Rallying around one library sounds cool until you see that the top three competing solutions in another ecosystem each have more contributors and activity. Then you realize you're not in the elite ecosystem, just the smaller one that has one library like my tiny Texas hometown.

Yeah because those 20+ half-baked MongoDB drivers on npm are totally better than emongo (Erlang) and mongo (Elixir).

I don't use Mongo, but I don't see any competitive alternatives to node-pg.

Eh, worst case, we can make another hex that enforces good test coverage and documentation. :)

Pretty much what rubiquity said. Inflection was causing confusion and explicit > implicit almost always, so we decided to drop it.

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

I'm not on the core team, but speaking as an Elixir user, explicitness trumps all virtues.

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?

> is it because what they want to do simply is not possible in Ruby/Python/Go/JavaScript/etc

There are several key distinctions about Elixir vs the other languages you mentioned. These are things that are basically not going to happen in Ruby, Python, Go, Javascript, or etc.:

1) You get the benefits of Erlang/OTP as others have mentioned in their replies.

2) You also get the amazing macro capabilities (runtime code execution and runtime code generation, a la LISP) that Elixir brings to the table. Many of the language features of Elixir are written in macros in Elixir. 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.

3) Immuatable data and functional style leads to better code in lots of ways. This is what really makes the benefits of OTP possible (updating the code without restarting the servers, easily migrating state between servers, and so on). But it also makes certain kinds of situations easier to understand and fix, since all state in the system can be expressed as parameters to functions.

Erlang/OTP is great fit for building applications that support a huge amount of concurrent users, but the problem is that IMO Erlang is nowhere near as pleasant to work with as Ruby, Python, etc. So if you're building something with zero users and choosing Erlang because of the ROFLscale potential it's premature optimisation. Elixir is the difference. I am just as productive in it as anything else and I enjoy it much more. So what we have is the massive power and potential of Erlang/OTP with a productive, pleasant API and great developer tools (Mix, Hex, etc).

Everything is possible in a Turing complete language (assuming enough of base utility functions are provided by stdlib), so the question is not possible vs impossible, but how much of a help the tool is.

Erlang provides great abstractions for building fault-tolerant, scalable, distributed, soft real-time systems. That's not to say you can't do it with Erlang, but Erlang does give some simple, yet very powerful tools for making developer's life easier.

Without Erlang you have to work harder to get similar effects. Again, it's not impossible but there's more burden on developers because the runtime provides less guarantees. I elaborated a bit on the topic in the promo interview for my book (http://www.infoq.com/articles/elixir-in-action-erlang-review).

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

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

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.

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.

I did. I love Rails. Love it. Love Ruby. I've been writing code for over 25 years this year, and I've been doing Ruby for 10. And I hit a big brick wall with a very websocket-heavy app I'm building.

I switched to Elixir and Phoenix last year and got the core of my app working.

It's funny though - the core is easier. But many freebies from Rails aren't there yet. So I still don't have password recovery emails or confirmation emails on signup done yet :)

But you woudn't need gems to for recovery emails right?

The Devise gem does that for free. I remember me coding it in my first Rails application so many years ago and I'm not keen to go back to it: it feels like wasted time. Phoenix didn't have it one year ago and it's sad to learn that it doesn't have it yet. Somebody will write it sooner or later because it's almost core functionality of a registration and authentication system.

Its actually pretty simple to implement on your own. I am not big of device. I feel it does too much magic. It should have been just a api layer and not touching views.

It's simple to write a password-based auth system. Then you must clear session appropriately.

Then you must create the login page.

Then the controller for authenticating. And then you need to ensure that the flow works with a test.

Then you need the email that actually activates the account, with the activation hash. So now you're setting up a mailer system, which Phoenix does not have by default.

Then people will want to recover passwords. So you need to write the logic for that. Oh, and the controllers and views. And routes.

And of course, you need to hash the password using some kind of encryption. Excrypt, comeonin, what have you. Choices choices choices.

You'll need a plug to act as the bouncer for your routes too, so nobody gets in where they shouldn't. So you'll have to write that.

You have to end-to-end test this, of course. And probably, if your business depends on it, get a couple other people to review the security of your system.

Simple. And takes a long time.

HTTP is pretty simple, but we use frameworks. SQL is pretty simple too, but we use Ecto now.

It's simple in its pieces, but I really don't wanna do all that work on every app. I'm lazy.

my employer uses erlang because it's a huge leap forward operationally over ruby/python/go/java. the erlang/otp concept of a release is extremely straightforward and reliable and the beam (erlang/elixir vm) run time introspection and debugging tools are second to none. it's trivial to attach to any running application and get a REPL with full access to the environment. you can even update running code in place

how do people typically put security (authentication and authorization) around this? You wouldn't want just anyone to be able to connect to your running apps, of course. From what I saw in Elixir, there's some kind of cookie/session key that you can specify, but is that it or is there more?

we're on aws, so we use vpc with security groups that limit connections to our vpn or a bastion server at our network edge

i'm not aware of anyone running an erlang or elixir repl over http but it would be an interesting project

VPC?

Virtual Private Cloud. Amazon's "branded" term for a private cloud with strict firewall inbound access protection.

I use Elixir/Phoenix on mobile multi-core arm devices because it uses memory efficiently and has off-the-shelf support for multi-core concurrency.

If you're new to Elixir, I highly recommend Dave Thomas' book "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."

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

Dave's book gives a great overview of Elixir.

If you want a deeper look at Elixir - I'd recommend Elixir in Action by Saša Jurić (Manning publications).

Ben Tan Wei Hao's book is also promising (still in early release) - The Little Elixir & OTP Guidebook also Manning.

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.

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!

Just in time for your workshop. :)

I have been working with Phoenix for about a year. Upgrading hasn't been bad. The most inconvenient thing was when Ecto changed some APIs to return tuples, and changing Ecto.Repo.update/2 to be a no-op with no changes. It really isn't that bad with a good test suite though. :)

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

FWIW the URL should probably be updated to http://www.phoenixframework.org/blog/phoenix-10-the-framewor...

http://www.phoenixframework.org/blog seems to point to the most recent post.

What is the "tooling" (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-...)

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.

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

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?

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.

I'm a Django developer working who works with Phoenix in my free time, and I can say I prefer it.

However "Developer productivity" seems like an excessively vague term, and would be hard to compare in any meaningful way.

If you are doing REST apis and are interested in Elixir I'd recommend checking out Trot (https://github.com/hexedpackets/trot). If is a lightweight wrapper around Plug (Exilir's middleware framework) and Cowboy (Elixir's native http server).

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.

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.

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!

A lot of Elixir folks try to claim that the syntax doesn't matter. They're lying to themselves: of course the syntax matters. Not only is it much easier and more consistent for the human brain to parse (even more so than Ruby, in my opinion; unlike Ruby, everything that should take a block - like 'def' and 'defmodule' - do (pun intended) take a block), but it also goes above and beyond what Erlang offers with things like its pipe operator ('|>'), macro support, defaulting to binary strings (if you use double-quotes; single quotes are Erlang-style lists of characters, which - while they have their uses (aside from the obvious interoperability with Erlang code) - aren't really as efficient), and (in my observation) greater consistentcy between what you can do in the REPL ('iex') and what you can do in actual source files.

They're both great languages, but I think Elixir is a bit more refined, learning from Erlang's advantages and disadvantages and improving on them. It's basically what you get if you watch "Erlang The Movie II: The Sequel" [0] and actually try to write a language for Ruby hipsters with excellent taste in noserings while humming along to Bananarama :)

[0]: https://www.youtube.com/watch?v=rRbY3TMUcgQ

I'm a long time Erlang programmer and still prefer Erlang. But anyone who asks about web programming I point to Phoenix. So if you are doing a web app, or have a web component, I'd suggest Elixir and Phoenix for that part :)

Erlang developer tooling does need work. But we are getting there, we have a new build tool http://www.rebar3.org/ that also combines forces with Elixir for the package management https://github.com/hexpm/rebar3_hex

Coming from an Erlang background, I found it very easy to get started with Elixir, it has the same underlying concepts and power as Erlang. Elixir takes it to the next level, though. The syntax eliminates annoyances in the Erlang system, e.g. having to fool around with punctuation and work with binary strings. The Elixir standard library gets rid of inconsistencies in the Erlang libraries and it is organized to allow easy chaining via the |> operator. Then it has features like protocols which give the encapsulation and polymorphism of OO without needing objects. And finally we have macros, which are the "right way" to do metaprogramming, allowing ease of use at a Rails level without the mess underneath.

Another big thing is that the Elixir community focuses on ease of use and out of box experience the way the Rails community did. So it's easy to get started and all the pieces generally fit together well, e.g. the mix build tool works great, as does the hex package manager, and relx release builder. With Erlang it's more DIY. We have recently converted a big Erlang project to use mix as the build tool, and it just eliminated a bunch of cruft. The interop between Elixir and Erlang is easy. So you get the best of both worlds, the ease of use of Elixir with the power of Erlang, with the highly mature runtime and libraries. And with Phoenix we get a web framework with world class ease of use.

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

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.

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

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.

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

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.

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.

I have worked a bit with elixir and erlang lately, but i'm not means an expert. I have to say, the biggest advantage elixir has against erlang for me is the macro system. It seems to manage to combine a ruby-like syntax with lisp-like macros, and it works incredibly well. Because of this it is very easy to create DSLs.

I've been doing full-time Erlang for five years, and I personally prefer Elixir.

Elixir is semantically close to Erlang the language, and allows you to take advantage of all the great benefits of Erlang/OTP.

It's benefit is dev's productivity. Creating OTP applications and releases is simpler, and there are tools in the language (e.g. macros, polymorphism via protocols, tidier stdlib), and around it (e.g. Hex package manager, mix tool, doc tests) that make developers' life simpler.

All of this is possible in plain Erlang, but it's more cumbersome, and sometimes requires home-brewed solutions.

Notice that I'm not discussing syntax at all, because it (mostly) doesn't matter. I actually like the Prologness of Erlang. What I dislike is that some chores require more of my time and yak shaving, compared to Elixir.

My impression is that Erlang/Elixir is excellent at the kind of decentralized networked services that people usually use it for, but less ideal for many other things. What's your experience with Erlang as a "day to day" language for more mundane stuff?

For example, a lot of my work tends to revolve around working with data. Processing large batches of data, parsing (often it comes in the shape of XML), transforming, filtering, ingesting it into databases, and so on. I can do this easily in Ruby, but performance issues has driven me to use Node.js or Go for new projects. With Go it's ridiculously easy to build efficient pipes that can parallelize each step to my liking, backpressure included. It's also trivial to build small command-line tools as well as specialized daemons. I have a world of libraries (and bindings to C libraries) at my disposal: AWS, image processing, transcoding, PostgreSQL, XML, JSON, it's all there. Go is also decent at Unicode and string manipulation.

I'm not wild about Go's performance, and everything I have seen of Erlang indicates that its performance is closer to that of Ruby or Node.js. Any comments here? Whenever I need to fire up anything related to batch processing in Ruby or Node.js, things take forever. Erlang's advantage here might be that it's easier to spawn remote processes to parallelize the workload.

Thanks all for your responses, really helpful!

Don't forget LFE (Lisp Flavored Erlang), if you prefer a Lisp syntax to a Ruby syntax that runs on the BEAM, as I do, although Elixir has great momentum right now.

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.

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.

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

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

Just the announcement page.

The Phoenix website is hosted on https://readme.io/, it seems that it uses client side rendering for posts.

Our (ReadMe.io) fault! We're releasing a JS-free version in the very near future :)

No, you can use phoenix without any javascript, it'll serve up regular html pages just fine. You only need the js if you plan on using sockets to connect to Phoenix's endpoints.

OP is asking about the phoenix web page, not phoenix itself.

Actually he was asking about both

Phoenix is built to power realtime web applications. Realtime web applications require javascript.

Edit: Not that you can't use Phoenix without realtime capabilities, but a lot of the good stuff in Phoenix is around Channels.

JavaScript may well be practically required, but there are people/agents that don't have it, and dumping piles of json data on them is a poor fallback.

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.

And then after that they'll rename it to Firefox

http://tvtropes.org/pmwiki/pmwiki.php/Main/DontExplainTheJok...

Yes, there is [1]. That's the reason Firefox is Firefox (Phoenix -> Firebird -> Firefox).

[1] http://www.firebirdsql.org/

I believe that's the joke! I usually never mind when projects have duplicate names, but c'mon, "Phoenix"?! Zero points for creativity there - I sure wish there were more things in history than rose from the ashes ;)

Oops... whoosh

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

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

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.

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

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

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

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.

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

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

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.

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.

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.

This doesn't compare to the frameworks you mentioned in that regard. It's a framework for the Elixir language, not another JS framework.

True, my thinking was one level up the stack, Phoenix is (according to Chris' talk) a framework for building applications. And it does this using Elixir running on Erlang. Is Elixir special?

Sure it is, but "framework for building apps using language X which is run by virtual machine Y" is the basic pattern for JavaScript, Clojure, Scala, Java, and others. There are a lot of them, they have varying levels of integration.

Can I build a discussion forum in Phoenix? Sure, it has all the tools. Can I build it using PHP or Ruby? Sure those have tools too. Can I create an integrated IDE with my langauge and my execution environment? Sure we can do that too like Light Table.

So is it just Visual Basic all over again? Thinking of it that way is probably not conducive to polite conversation :-) but in many ways it is. We have a scripted language (Elixir), a virtual machine (Erlang), a "window" system (HTML5), and a set of APIs we can call on.

That is great, doesn't solve a new problem but solves an existing problem in a new way. And I watched Chris' talk and read the documentation, and I still don't feel like I have a good feel for why its better than what came before.

Describe a "new problem". I only rarely encounter truly unique problems.

One thing it does do is allow scalability in a pretty straight-forward, integrated way.

I like the scaling aspect of it very much.

There are lots of "new" problems with respect to changing conditions in our day to day lives. Here are a few

- Identity management across Internet and non-Internet properties

- Configuration, control, auditing, and monitoring of billions of Beacon level devices

- Zero knowledge proofs as a technique for anonymous and no repudiated purchases online

- "home" level cloud services for local and on the road implementation of always available services (mail, journaling, calendaring, Etc.)

- Reliable third party payment systems (somewhat of an old system but one that benefits from revisiting with current technology from time to time)

- Navigation and cartography tools for people in disconnected regions of the planet.

- Civil process augmentation with automation and authentication.

- Connectivity as a tax payer civic utility, without an editorial bias.

-Dynamic skills assessment for students in the presence of confounding factors (mostly remote access)

- Low friction capital markets for charitable giving (think Watsi but for everything, and with better controls than 'GoFundMe')

- Providing civic services for indigenous homeless populations.

I could go on, there are lots and lots of problems. But to be clear it isn't a criticism of Phoenix that they are not solving a new problem, the feedback was that there are lots of solutions to the general form of problem they are solving and, as feedback on this announcement, I was trying to learn from their materials how they were different (and presumptively better) than those other solutions. I'm still looking for that summary somewhere.

These seems like architecture level problems rather then framework level.

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

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

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!

Are there any libraries to help with authentication in Phoenix?

I couldn't find anything in the docs.

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/opendrops/passport

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

http://nithinbekal.com/posts/phoenix-authentication/

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

not to be confused with https://phoenix.apache.org/ (distributed database)

Or to be confused with http://website-archive.mozilla.org/www.mozilla.org/firefox_r... (web browser)

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

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

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!

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/

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

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.

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.

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

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

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

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

Then you have to learn Elixir though.

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

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

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

Way to go! Great work, team.

How would this compare to the NodeJS ecosystem?

Newer and smaller.

...another new web framework?

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

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

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.

Reply on news.ycombinator.com