I use several frameworks/libs for different tasks: Webmachine, N2O, Cowboy
I don't believe in RoR type of frameworks. I believe in clear separation between server and client. We are steadily moving towards a web of websockets and "one page JS applications". Won't comment on whether that is nice thing or not. I am not sure for myself. For client we are stuck with JS. Sucks but it's a fact of life.
Erlang (or other things using this model, though, nothing as mature exists) is the only sane way of writing "multi-user" or "mega-user" servers. For me, server side is a solved problem (because of Erlang). And I'm talking about huge, clustered backends. Node.js feels like a child's toy compared to Erlang.
I would suggest that everyone who claims to be a web programmer should at least know how to use Erlang. Otherwise, you aren't really aware of how big the world really is. And what is possible actually. This may sound elitist, and it probably is, and I am probably not a good person for talking like that.
But you can't really argue with things like this: http://blog.whatsapp.com/196/1-million-is-so-2011
Once you have experienced things like this, and once you really understand why it works and how to steadily reproduce it on every project you work on... well, that's why I claim that server side is a solved problem.
As someone who knows their way around Erlang, it needs some work for more 'average joe' programmers to get much done with it. I'm not talking about the syntax, but some set of libraries or a framework or something that gets people up and running quickly. Chicago Boss is interesting, but it's not very Erlangy (it uses compiler magic).
Edit: that said, a big company would certainly have the resources to make Erlang work well for web development, and, yes, it's way more solid than Node.js from an architectural point of view.
So does this mean Erlang only makes sense if you work for a big company or have a large team to implement it properly? (I'm responding in light of davidw's edit which you may not have seen).
You can do web stuff in Erlang. It's just that it's not like Rails, where you start it up and it's easy to do so much with so little code. Since there's not as much infrastructure, you have to do more yourself.
That can still be worth it, given the advantages the run time gives you, but I think you'd really want to know exactly what you're doing.
Thanks for your suggestion, I will definitely look into erlang. I have tried to look into it but I have found it quite unapproachable. You have to be really motivated on your own to learn it.
Everytime someone points a erlang, they bring up whatsapp. And everytime they do that, I tell them facebook the company that owns it is a php shop (Atleast, that was the core driver. Things might be different today with hiphop).
Writing something in PHP made sense in 2004. Although Erlang was around at the time, it wasn't at all well known.
And no, you are not absolutely right, Facebook is not a PHP (only) shop. Their chat backend is in Erlang and that's a much bigger tell-tale than their legacy code.
Also, a lot of us Erlangers speculate that Facebook bought WhatsApp (not only but also) because of their huge infrastructure know-how and (Erlang) talent.
Not true anymore. They switched away from Erlang because of reliability and scaling problems. So saying that mega-user server side is a solved problem because of Erlang feels like a stretch.
Thanks. Sounds like they didn't really figure out what the problem was with the Erlang implementation but instead reimplemented with C++ systems that were existing, built in-house, and better understood. Makes total sense but shouldn't be taken as a point for or against Erlang as much as it's a point for using a stack your team is familiar with (or has a deep motivation to get familiar with).
> Isn't that argument bad for erlang? That you need to pay an atrocious price for erlang know how.
That erlang know-how commands a high price on the market is a good argument for developers to invest in developing that know how, and for organizations to work on fostering it in their staff.
Its only "bad for erlang" if you assume the only way to adopt erlang is for an organization to wake up out of the blue one day and decide "from this day forth, all our work will be in Erlang, and we're going to go out on the market today and hire up Erlang talent to enable that to occur."
Can you make some recommendations for Erlang IDEs?
What's your typical day-to-day setup, and what's your workflow look like?
I love Erlang and its concept, but the lack of friendly developer tools and easy testing put me off after the one successful (commercial) project I completed a couple of years ago.
I'm all geared up to become an Erlang evangelist (particularly for the reasons you give - Node.js really does feel like a toy in comparison), it's just the process of putting the code together feels painful compared to the tools I'm used to. (whether Visual Studio or PHPStorm or...)
If you can spend a few minutes discussing your setup, I would find it immensely useful.
Erlang is great and so is Elixir but node serves a different purpose which really amounts to many different purposes of which none include things like building massive real-time and fault-tolerant messaging services (you could still use node and make it work but it certainly would be a suboptimal choice for that).
Just to follow up on topic of WhatsApp and Erlang, here is a presentation given at Erlang Factory 2014 about their goals with scaling WhatsApp to billions of simultaneous users.
I would argue the discussion is less about which framework and more about the suitability of the language. It's a debate worth having but I struggle to think of good arguments to move infrastructure of this sort of scope to JavaScript over the more "typical" options (Java/Scala, .NET, Python, go, erlang, etc.). JavaScript obviously has a place in web application development, I'm just not convinced that place is on servers in the vast majority of cases.
