https://twitter.com/josevalim/status/666390233609576448
Due out December 20th according to github. Appears the biggest part of the release is support for Erlang 18 features while dropping support for Erlang 17.
http://www.erlang.org/download/otp_src_18.0.readme
I wonder what this means for Phoenix itself and the library ecosystem. Hopefully nothing drastic.
In Meteor half of must-have stuff is done by community (router, schema, validation, etc), while the core dev team adds new things (can’t actually remember any new at least half a year, babel…?) very slowly and almost does not communicate with community.
As you have used Phoenix, how are this things there?
If you scroll up a bit, @SkinnyGeek1010 discusses how approachable the Elixir and Phoenix core are. They evidently hang out in irc with the peons, answering questions.
Gauging from the commits, they certainly aren’t sleeping on the job either.
Any comparisons on deployment with Phoenix vs Meteor?
Any comparisons on deployment with Phoenix vs Meteor?
Deploying to Heroku is easy with a build pack. They have a redis adapter to allow horizontal scaling (connects the pubs).
http://www.phoenixframework.org/docs/heroku
Deploying to your own infrastructure requires you to use Exrm which is harder than deploying with mup no matter how you slice it. This gives you the ability to do hot code patching (per module) while running for 0 downtime but for my use cases is way more work than just having a second or less of downtime.
http://www.phoenixframework.org/docs/advanced-deployment
The core is quite solid. The router is really nice too.
It uses Ecto for the model and changesets which give you a schema and a way to cast data and validate. If you opt into all of Ecto you can get an ‘orm’ like thing for queries. I prefer the raw driver for Rethink as you can use pipelines to transform the data and i’m just using a thin adapter for model/changesets
I’m getting close to releasing a REST library for Meteor that adds these features to Meteor actually… a very similar server side router, concept of transforming the connection from entry to exit (with controllers), and a separate package to provide the changeset/model in a functional paradigm (not objects or classes).
I think learning about Phoenix is a net positive for Meteor in my opinion. Using just Phoenix strictly will work for some but borrowing ideas can help strengthen the Meteor community 
@SkinnyGeek1010 Is it the same principle as the socket.io redis adapter ? used to sync the pub/sub between multiple servers ?
If this is the case, then redis should be faster than Phoenix right ?
And in the other discussion, we just said that the redis solution is not efficient at all (this message and the next one)
Thank you guys for the answers, I think the right thing to do is to spend some time trying to do a setup + example app and see, what does it look and feel like.
With the latests events, considering leaving Meteor and investing time into smth else today sounds not so crazy.
Other books :
The Little Elixir & OTP Guidebook (MEAP v5 in november not finished) Benjamin Tan Wei Hao at www.manning.com
Metaprogramming Elixir by Chrus McCord (author of Phoenix) Feb 2015 at Pragmatic Programmers https://pragprog.com.
In that video It was socket.io acting as an event bus, not Redis, that was the point of failure. Redis itself and Phoenix both use an observer pattern which will scale considerable higher. Only pertinent information is transferred to a particular channel, not all information.
That being said, you have to consider that Phoenix is highly concurrent while Redis just bypasses concurrency issues by being single threaded. Redis is hand tuned c code and is hella fast. Still, Phoenix is likely to outpace Redis.
As far as I understand it, Redis is only used to keep multiple servers in sync. It’s also only used if you’re running on Heroku because of some kind of restriction on the Erlang VM cluster support.
However, from what I understand you don’t need it if you just have 1 node and scale vertically (since you can use all cores this works out nicely).
Here’s the chart they show redis bing used and other things like RabitMQ or XMPP. I think Redis is just the most user friendly. On Heroku you just click to add and add in the adapter as a package dep. (again from what I understand 
)
I’ve only deployed to a DO server with a single instance so I haven’t dove into that yet.
Puh, from your lips to God’s ears. Of course realtime is an illusion; even from the light of this screen to your eyes. Call it soft-realtime if you want, but meteor is an application development framework targeted at maintaining endstate, not caring much about timelynes, receival order and drop outs. Anyone who wants to build whatsapp or a monetary stock transaction application with meteor would be just as crazy as building a content management system on top of erlang. Therewith, this comparison is limping - and I find phoenix quite interesting.
yeah 
proves my point I guess
True enough. Though perhaps you missed the Whatsapp clone tutorial on the meteor blog.
Haha, that’s a pretty bad UI 
Back end designers.
I don’t want to beat a dead horse but the main point of Erlang/Phoenix is that backend. I’m sure someone will come out with a CMS with a nice front-end. Meteor is a very nice full stack solution.
Speaking of bad production value this is a great video:
https://www.youtube.com/watch?v=xrIjfIjssLE
Haha, yes, as Erlang unleashes all its concurrency power to the content management world.
However, with no means to kill the discussion, but let’s get back to topic. I don’t try to play the blind meteor advocate here; only to point out that Meteor - of course - does not make sense for many of the applications at scale for which Erlang, and there with Phoenix, was designed for. Meteor as a phoenix alternative? Come on
Looking at business cases for both frameworks, the title “Phönix as a Meteor alternative” becomes narrow, since - there should be - very little overlap. One really must have a personal relationship to the DevOps Gods if they plan to build highly concurrent systems with Meteor or way too much budget if they instrument Erlang to power their steady state website content.
Meteor is the microwave of kitchen equipment here.
I agree to some extent most people will never need to support millions of users but we could all use a more efficient tool. Also important, it may be better to pay more for hosting to get easier realtime (meteor).
However, i’m afraid that there is a lot of overlap as far as scale. You don’t have to have 50k concurrent users to need Phoenix… a lot of Meteor apps i’ve heard of can only have less than 50 concurrent users before needing additional boxes.
The best i’ve done was a little over a 150 concurrent users per modulus servo (512mb) for a particular app (tuned publications and limited reactivity). For the day a peak was 400 so not massive scale but I needed 4 servers to stay afloat. At $60 a month this isn’t a big deal but scaling larger would be costly.
I mean really they are apples and oranges and hard to compare side by side but if you would have the same app on both systems you can use less resources. I guess that’s the point i’m trying to make is that Phoesnix isn’t just for mega scale, it’s aimed at normal apps but it happens to do it fairly efficiently.
Benchmarking a REST Phoenix API on a 2GB 2-core digital ocean yielded around 58k hits in 1 min or roughly 1000 hits per second before getting errors (23). Max latency was 16ms and best was 14ms. using Blitz.io.
That’s plenty for me needs and offers lots of headroom without needing 4-6 node boxes running in a cluster.
I’m most interested in bringing in some things that could help Meteor, whether its the language or framework(s) (though they’re different beasts of course). I’m still developing on Meteor for most projects but high traffic sites may get Phoenix until MDG provides a more efficient solution (which sounds like its in the works).
@SkinnyGeek1010 When do you think you will release your Rest API package for Meteor ? And is it solid, production ready? Could I compare it to an Express Rest API ? Does it scale the same way if I only use the Rest API without any DDP ?
Within this week. working on the Meteor-Elixir repo above took more time than I estimated.
The basic router/controller/connection-functions will be released first and is 90% of it, then the model/changesets will come next (models are done).
Does it scale the same way if I only use the Rest API without any DDP ?
Yep! It scales the same as an express app so you can just horizontally scale without any issues.
Could I compare it to an Express Rest API ?
Very much so. It’s running the connect-router under the hood (which could be swapped easily). It’s basically like an express with ES6 and a functional mindset. There’s a conn data structure that gets passes around and transformed but under the hood you can just modify conn.req and conn.res directly if there isn’t a function that’s included. The conn eventually gets returned in the controller and rendered into JSON/XML/etc…
Can’t wait to start back up on it I’ll have some basic benchmarks on DO, Heroku and Modulus to see what the differences are in hosting (and perhaps Galaxy 
) .
Wow ! Honestly, after this, there will be no reason to use another node framework. This is awesome !!!
So it will support any Connect/Express middleware ? What about auth ?
Thanks a lot for your work, this will make Meteor way more useful for a lot of people.