First of all, I am in no way criticizing Phoenix, Rails, etc. Love them all, glad they exist. I’m just a bit curious about what the community thinks. Happy to be proven wrong so I can calm down.
Even though Ruby is a general purpose language, it’s no exaggeration that for all practical purposes, in the job market, it’s synonymous with Rails. Even though many different kinds of projects use Ruby (like Homebrew), if you find a Ruby job, there’s a 99% chance you’ll be doing Rails. Contrast with Python where you might go from Django apps to machine learning or data science (I’m sure there’s way more of the first one, but the last two are valid and realistic options).
I’m sort of afraid the same with happen with Elixir. While I like web development and understand it’s a large part of the job market in general, I don’t want all Elixir jobs in the future to become Phoenix jobs. I really like the language, the concurrency, and functional programming but I’d hate to be limited to making web apps (which can get boring after the tenth one) or just not working with Elixir. Erlang was made for telephone networks, but it found its way to chats, messaging protocols, game supporting software, and financial systems. I hope Elixir sees the same variety of jobs and opportunities in the future.
Also I’d really hate for there to be people that know Phoenix and not Elixir (ever heard of people complaining that their devs know Rails and not Ruby?) though Chris has done a good job making sure you know Elixir to get the most out of Phoenix so not too worried about that.
I think the future is distributed programming: IoT, gaming, and combinations thereof with cute animations and avatars with identity shared among your fridge, phone, and toaster. This means concurrency, which means youngins are going to be learning the heart of Elixir with the actor model, nodes, FP, immutability etc, and not necessarily just Phoenix. As long as they’re pushing towards client-side BEAM, then there should be absolutely no problems. From what I’ve seen with Nerves, embedded Linux distros look covered. Would be awesome to see a BEAM on Android/iOS (if it doesn’t already exist).
I don’t see why it wouldn’t be a valid question and it’s always good to be a little paranoid in this business.
It seems to me that as Phoenix matures it actually is moving away from what limited Rails - it seems to be embracing the lessons that Erlang (and by extension Elixir) has already learned and the philosophy that emerged from it. Rails (as far as I can tell) kind of did it’s own thing and happened to use Ruby (which I could personally never warm up to). Phoenix on the other hand seems to build on and extend on Erlang’s (OTP’s, Elixir’s) foundation. So in a way I don’t think anybody can really be effective in Phoenix without also drinking the Erlang/Elixir/OTP Kool-Aid.
Frankly here you kind of identify an escape hatch - Erlang is the fallback position from Elixir - while it isn’t exactly mainstream right now it is at least “less academic” and “more commercial” than something like Haskell (or even Lisp). And really Erlang needs Elixir to get rid of the required boilerplate that seems to have put off some people from Erlang (though the level of meta-programming going on in Elixir may prove to be a challenge for some people).
At some point in time the DevOps/microservices architecture/IoT adoption crowd will have to notice the Erlang/OTP/Elixir solution to the ongoing “the free lunch is over” dilemma - they just need some time to realize that their legacy .NET/Java EE infrastructures and solutions “just can’t get there from here” (with any reasonable amount of effort) and that there is no point in pursuing some mythical isomorphic/universal technology stack.
I think this is a legitimate question, but I am hopeful.
I think the difference is best summed up in the title of a talk last elixirconf “Phoenix is not your application”. Whereas rails provides a project structure completely unique to itself, an application that uses phoenix is just a regular mix application.
It’s true that lots of us are building stuff for the web, and we’re almost universally using phoenix for that purpose. However phoenix’s very structure makes it more like a component than a “Phoenix application”. This becomes ever more evident as you start doing in your application above and beyond serving web requests. Umbrella applications can further delineate this distinction.
It’s true that one of Elixir’s primary use cases is stuff on the web, but the BEAM was built for networks; it’s a natural fit. The Elixir platform gives us tools to build modular programs that Ruby simply doesn’t ship with, and I think it’s those tools that ultimately prevent the issue you’re concerned with.
Elixir can be used to great extent for building web-apps, but unlike Rails which is sort of a ‘bionic arm’ around Ruby that adds a whole new layer of features, limitations and complexity, Phoenix is ‘just’ a web framework. The meat of your application is not (should not) be shaped by Phoenix. Because of Elixir’s concurrent nature, many systems that you’d need to use external dependencies for can be built inside Elixir directly.
Another important thing to note: Elixir is also used with great success in the embedded software realm with the Nerves project. This is something we definitely should not overlook. My prediction for the future is that when the ‘internet of things’ becomes more important, that it is really nice to be able to manipulate your client-side microprocessors, your back-end data processing server and your web-based control panel all in the same language.
It’s a legit question, but I think that the way Elixir is built as a language prevents this from happening. Phoenix provides some constructs within Elixir to provide a familiar and robust development experience.
Rails changed Ruby to make it a web language. This is what made it possible to know Rails and not Ruby. I don’t think that’s possible with Elixir and functional programming. If anything, I view Phoenix as a gateway to make the transition easier for common and needed tasks.