I had no idea those book clubs were going on! haha. Michael Ries lives right by me and spoke at our local Elixir Meetup a couple months ago. He’s a nice guy. Thanks for sharing!
1 Like
Can we not start a @ryanswapp ‘blog post club’ or @SkinnyGeek1010 ‘blog post club’ and start a hangout thread to share ideas & what not ? It would be awesome.
I vehemently disagreed a month ago in the whats-wrong-with-blaze thread . But then @jacobin said something gold - Time is better spent learning React . I really liked that motto and abstained from further taking part in these arguments and learnt React 
instead. Although I miss the blazing fast mvp-making speed, I believe I will come up to speed with React soon as its more of a thinking pattern rather than syntax.
Finally, @SkinnyGeek1010 was talking about various programming languages in various threads and I really liked that. I liked how he advocated learning from other Languages and implanting it in javaScript. I always wanted to learn a side language for fun. Either Python, Clojure or Elm was on my list but then I learned about Elixir & Phoenix from you all. I have been hooked since to be honest. Its hard not to look at those youtube videos. I won’t use it in my main project, but the distributed data system has definitely made me interested.
8 Likes
Once you learn one c syntax derived language you really have learned them all. You know ansi-c you will be able to read java. You know java you know C#. Javascript, well by then you know it kind of sucks.
Elixir necessitates a different perspective and thinking pattern. I was resistant at first when @SkinnyGeek1010 was championing functional programming. However the change really is not as drastic as you might think.
Lambdas are just anonymous methods.
Chaining functions are just unix pipes.
Pattern matching is just akin to interface overrides.
Turned out I know how to do most all this FP stuff already. It looks strange but can do some really wild stuff. Sort of like the girlfriend of that guy in a Lumberjack costume over at the coffee house.
3 Likes
Haha! Got a good laugh out of that one.
Come on over to the Elixir slack channel! We’ve got a meteor-dev channel where we toss around ideas 
3 Likes
Were’s that slack channel? Any idea on how can I use Phoenix as a chat backend and connect it to meteor publications? That seems like a really good option for me. Meteor + Phoenix. And what’s the best db option with Phoenix for that? (Lots of small writes)
Here is the slack channel https://elixir-slackin.herokuapp.com/
I haven’t ever tried to hook Meteor into Phoenix, nor have I thought much about it, so anything I say is just an off-the-top-of-my-head comment. @SkinnyGeek1010 has done it though so he likely has a good idea of whether that’s possible.
There is no best DB option for anything really. It comes down to your project needs. Phoenix defaults to Postgres which is a really solid option. I also think RethinkDB is a stellar choice so you likely can’t go wrong with either of those.
2 Likes
This is super interesting… But I’m thinking of holding off building a phoenix/redux app at the moment because this issue https://github.com/facebook/relay/issues/114 is going to be resolved at some point.
I think relay will completely replace redux as soon as it can handle both client and server data.
And then there’s this issue: https://github.com/facebook/relay/issues/541 that is trying to cover real-time updates via subscriptions.
Once relay matures a bit more in company with Elixir’s graphql packages, that will an incredible way to build apps going forward.
I don’t know much about Relay, but from a quick glance it looks intriguing. When school calms down I’ll have to give it a closer look.
Ya I agree! Chris McCord has been saying that their goal is to move Phoenix over to a more GraphQL type system so that should definitely be interesting. He and Jose are super smart dudes. They seem to be pumping out good stuff at a break neck pace! Pretty impressive.
Chapter 9 on Phoenix Channels was uploaded tonight. Disappointed you were not there.
Do you have some thoughts about this other solution that tries to compensate Meteor limitations, mainly about scaling, but still using Node.js?
It seems well done.
1 Like
It’s a great proof of concept. I wouldn’t say scaling is the main issue he’s attempting to resolve. He’s put a lot of thought into many aspects.
The project looks interesting, but with only 34 commits from one guy it’s too early to tell what will become of it. I hope others start pushing code.
It’s certainly a direction MDG should be heading towards but will never be able to. The level of resistance to positive change in the meteor community dwarfs that of when Apple decided to ditch Motorola.
Myself though, Elixir has re-ignited my love for programming. Whenever I write code in Javascript I feel dirty. It is so bad on so many levels. That and the fact that Phoenix’s development activity level makes Meteor look like abandonware in comparison.
3 Likes
I’m confused as to why Phoenix is a suitable Meteor alternative tbh. I’m always interested in new technology and do have a habit of jumping from framework to framework - but Phoenix is a backend-only framework written in an obtuse (albeit seemingly enjoyable to use) language. It’s hardly like you could jump from one to the other.
I’m not sure what I’m getting at really, but I can see why @Babak is a bit fazed. There’s more activity in this thread than in Elixir’s SO tag.
2 Likes
I guess my tolerance for mucking around in javascript is a bit higher 
Honestly, with babel, there is rarely a pattern that makes me feel dirty. And the beauty of a language that updates annually is that it keeps getting more performant & it’ll probably absorb some good parts of Elixir, too.
I don’t think there’s an inherent performance gain to Elixir (the one benchmark is outdated, was performed on different machines, and didn’t really test much). We’ve all heard the success stories of node in Netflix & Walmart black fridays, but they don’t use sockets like we use them. About a year ago someone forked node to work concurrently, it never got popular because evented programming is just as fast & easier to reason about.
There’s always something to learn from a different language. Evented programming didn’t start with node, the libuv pattern was popular in C/C++ since the 80s. Chances are Flux/Redux wouldn’t exist without Elm & that’s a functional language. Who knows what nice treats the JS community can steal from Elixir
3 Likes
I know… I even talked to Michael about! Hopefully I’ll be on the next one. It’s been a little hard making the time with school 
Totes! I hope they do steal a few things… Elixir has some awesome features. Well, functional programming languages in general have awesome features (e.g. pattern-matching, pipes, etc…)
I love JavaScript, but man, I miss Elixir when I work with it haha. It’s kinda nice to switch back and forth when I build with React and Phoenix.
This is an interesting benchmark, have you seen this? Phoenix Showdown Comparative Benchmarks @ Rackspace · GitHub
I was pretty surprised by the performance of Elixir. Because you can spin up millions of processes to do work all at the same time you can get stuff done very quickly. It’s actually kinda shocking… Super fast.
But, this says it all:
Spot on.
2 Likes
It’s better than BASIC. At least we have classes now. Still no strong typing though.
I have to admit I find this new dynamic of transpilers quite fascinating. I thought .net was nifty when you could do something similar with outputting a C# app from a VB app or vice-versa, but this is another level altogether.
The Erlang VM uses a separate heap per process. A process in Erlang takes just 309 words to spin up, including 233 words for the stack which auto-grows and shrinks. That means you can spin up millions of them at will.
It a fully preemptive scheduler. No stop the world GC pauses and no synch process killing the rest of the system. It values low latency over throughput. @SkinnyGeek1010 posted about this earlier with his own benchmarks. 14ms response times, and only 16ms under heavy load.
If you have knowledge of how computers actually work there is no way you are not amazed at Erlang. Node, or even GO/Scala just cannot compete.
Get back to us when meteor’s (O)n^2 feature says hello. Meteor is the only framework where you hope and pray your application doesn’t become too popular. And by popular, we’re talking a few hundred users.
1 Like
btw dont trust any benchmarks you see, try them out for yourself and modify them to reflect what you are trying to build.
Just some useless info: I have performed the same with latest everything and you can see my results below. This doesnt say much, my env can be different or something else can be wrong. Point is try it out yourself
Note that the phoenix they used was very old so I created it from scratch, there might have been some performance tweaks I missed. Both ran in prod env.
[2015/12/02, 2:30:46 PM] Riaan Jacobs: phoenix:
[2015/12/02, 2:30:48 PM] Riaan Jacobs: riaans-MacBook-Pro-3:wrk riaan$ ./wrk -t4 -c100 -d30S --timeout 2000 "http://127.0.0.1:4000/showdown"
Running 30s test @ http://127.0.0.1:4000/showdown
4 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 9.09ms 0.91ms 18.38ms 73.06%
Req/Sec 2.76k 102.10 3.01k 76.25%
329775 requests in 30.01s, 729.06MB read
Requests/sec: 10988.04
Transfer/sec: 24.29MB
[2015/12/02, 2:30:54 PM] Riaan Jacobs: and express cluster:
[2015/12/02, 2:31:03 PM] Riaan Jacobs: iaans-MacBook-Pro-3:wrk riaan$ ./wrk -t4 -c100 -d30S --timeout 2000 "http://127.0.0.1:3000/showdown"
Running 30s test @ http://127.0.0.1:3000/showdown
4 threads and 100 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 4.72ms 3.60ms 167.29ms 95.64%
Req/Sec 5.57k 559.22 8.04k 86.20%
666977 requests in 30.10s, 1.36GB read
Requests/sec: 22156.41
Transfer/sec: 46.34MB
btw I really like phoenix and node/meteor. I look at my projects requirements and then pick the correct tool for the job.
Haha, same here. After writing Elixir, I’ve been using de-structuring heavily in my JS now, as well as making modules with just functions (no classes!). Using underscore’s chain method to pipe data through functions
var res = _.chain('555 121-7878')
.callFn(stripChars, '.')
.callFn(stripChars, ' ')
.callFn(stripChars, '-').value();
console.log(res);
// -> "5551217878"
Yea this is important. However, if you’re already using React/Redux in Meteor then the jump is not as far because you’re still using the same frontend. Instead of Meteor.call you use AJAX, and instead of subscribe you use the JS channels API.
The language can be learned in an intense weekend if you have Dave’s book and the learning elixir website. Phoenix is another day or two to make something to the point that it ‘clicks’.
That’s my experience and it was my first functional language (I find Elixir to pragmatic compared to Haskell/Listp/etc…)
It really depends on what you’re benchmarking… if it’s just a json api then you’re right, prob. not much of a difference comparing a node cluster to an Erlang machine. However… once you start benchmarking long lived stateful apps (websockets), Erlang/Elixir will rule the roost… mostly because the language itself was designed just to do this (telephone conversations are long lived connections).
2 Likes
@jacobin Perhaps I wasn’t clear. I wasn’t asking why it might be a better framework, but what makes it an ‘alternative’ in any real sense. I’d see something like sails.js as an alternative to meteor, for example. Phoenix is something different entirely.
i.e. If you had a trained team of javascript developers, you couldn’t easily migrate your meteor app to phoenix. It’s not something to consider unless you’re (likely) a sole developer and (likely) wanting to learn something new and quite different.
I guess this is pertinent. If ‘all’ your framework is doing is serving an API I guess the jump is a lot smaller.
Also if you’re the kind of developer that can pick up new languages easily it’s likely less of a big deal. I’m not a dedicated developer (although things seem to be shifting that way) and I still struggle with async coming from a PHP background, looking at Elixir code gives me the shivers!
Edit: tldr; Even if I went back to the day I discovered Meteor, I couldn’t imagine myself weighing up Phoenix vs Meteor - I think the target audiences are likely quite different.
(I’m sure it’s all awesome though, I really couldn’t say otherwise!)
1 Like