Since they prefer the language patterns of Ruby but want better performance for concurrent processes, it seems like this would be a perfect use case for Elixir with Phoenix. I wonder if they considered it.
The difference being that the Rails ecosystem is infinitely more mature than the Phoenix ecosystem (and community). Ecto is still going through some massive changes (ActiveRecord is comparatively stable). Personally I think that Elixr is an interesting language but it's not one I'd want to mess with in a production environment.
The big win for Go is that it compiles down to a single binary. Ruby you get a single point of entry (script with a shebang). But Elixr/Phoenix? You get a handful of bash (not even POSIX sh!) scripts and binaries and a whole VM to deploy. As a BSD user, I gave up on Elixr/Phoenix after trying to debug the nightmarish deployments that had been broken for months. I couldn't tell if it was an issue in the rat's nest of bash scripts or a VM bug. Sure, ruby-bcrypt is broken on FreeBSD too with a similar head-in-sand mentality from the bcrypt gem maintainer (which could make Rails deployments a non-starter) but that's easy to fix and has been fixed out-of-band. Elixr? Well there's one maintainer for the deployment tool and he's stopped responding to bug reports of any sort.
That said, I like Rails. A lot. But ruby is painfully slow and I've learned to push as much logic into the database as possible. So there's a compelling case to be made for an alternative. Unfortunately I've never had any other language give me that much trouble as Elixr has. Personally, I detest Go dependency and build management (and the Google involvement), but the simplicity of concurrency and deployment combined with the breadth of the standard library make a very compelling case for Go IMO. Hell, I would reach for Clojure before Elixr because at least then you're dealing with the comparatively mature Java VM.
Personally I've gone down the Rust road, but even then I'm not sure I'd want to deploy a Rust web app in production just yet (although I really do like Rocket).
What are you viewing as mature? It's a loaded word and many people use it with a different meaning in mind.
> Ecto is still going through some massive changes (ActiveRecord is comparatively stable)
As of the latest release of Ecto -- 3.0 -- the maintainers said they consider it mostly complete and said they will not do breaking API changes [0]; this part in particular:
"With the release of Ecto 3.0, I would like to announce that I finally consider Ecto to provide a stable API. This means no more new features, although we will continue providing bug fixes and updates. For everyone running Ecto in production, rest assured that Ecto will continue to be a well maintained project with the same production quality and polish that it has today."
So the first part of your statement is factually false.
For ActiveRecord being stable... subjective, I'll give you this much. Try and migrate a Rails 4.0 app to 5.x and come cry with me over a dozen beers. ;)
> Personally I think that Elixr is an interesting language but it's not one I'd want to mess with in a production environment.
Many people and organizations are "messing" with Elixir in production with great -- and increasing -- success.
Phoenix at the moment is one of the very few frameworks that delay your scalability problems much farther into the future than most me and many others have worked with. Phoenix can easily give you thousands of requests per second on a $5 DigitalOcean droplet. Rails and several C# and Java frameworks cannot.
I am not attacking you and I hope I don't sound that way -- but you seem to have a non-factually supported negative bias against Elixir. It gets more mature by the day and is quite capable of very serious work in pretty tough environments. Positive case studies spring into existence often.
[0] https://elixirforum.com/t/ecto-3-0-is-out-and-stable-api/173...
If deployments are broken for months[1] with no fix in sight, what do you expect? I'm currently seeing zero requests per second with Elixr. If the sole maintainer of the sole deployment tool is too disengaged to reply to bug reports I don't care one way or another what sort of performance a product (or its fanbase) are claiming. If the product can't be deployed it's not going to scale. Period.
It's a bit silly to talk performance comparisons between Ruby and Elixr as the premise of this article was that Ruby is simply too slow. Are you going to have a harder time scaling Go or Rust than Elixr? I doubt it. I have no idea if you're going to have a harder time scaling Java than Erlang, but Java is popular enough in the enterprise space that finding people with that sort of experience isn't so difficult. The only time I've seen Erlang at scale was with Megacorp's Enterprise Chef deployment. There was easily tens of thousands of dollars in hardware there and the Chef server was still regularly brought to its knees with well less than a thousand total users (and well fewer than that at any given time).
As for deployments, I've setup several of them in the last 2 months -- from scratch, and successfully. There's an initial learning curve that might be way too annoying for many. The deployment story is one of the weaker parts of Elixir -- I am not running away from that.
As for scaling, you might be mistaken. Erlang/Elixir can be scaled with almost zero effort up to 50 or so machines before you need to introduce special libraries or any extra tooling at all.
Of course, you can do the same with many other languages if you put Kubernetes or HAProxy in the picture. Point is, with Erlang/Elixir, it is 99% effortless up to a certain scale which most projects won't ever hit.
If you were talking about raw speed however, I can't argue that Erlang/Elixir are just a little faster than a very optimized JS (and still plenty faster than Python, Ruby or PHP). But nobody advocates Elixir for raw number crunching.
Of course. How many languages have a single deployment story maintained by a single person though? That level of fragility is something I wouldn't put in production. Period. Not even on Linux.
And, yes, you could just compile the app in production (and watch the security team lose their shit). Or you can blow everything away for each deployment. Or you could use a tool that's simply less tedious to deploy (e.g. Rust, Go, Java, Clojure, ClojureScript, Javascript).
To put it another way, if deploying is a pain, scaling is a pain.
I can't understand that argument. Would you please expand?
---
I agree it doesn't look very trustworthy that the only viable deployment option in Elixir is kind of stalled lately. Of course. What I am saying is, what we have at the moment works plenty well -- if you can get over the fact that enabling deployment in an Elixir app is needlessly complex.
As is said many times here in HN, judging an open-source project by its frequency and recency of commits is quite a flawed strategy.
See the Github issue linked (and the related issues). Distillery is known broken. Who cares if Elixr or Erlang scales really well if you can't even get it deployed? That Distillery is, for all intents and purposes, abandoned is secondary. It wasn't left in a usable state.
Interesting to see an outside take on the situation though. Thank you.
(EDIT: Also, in the issue it's pointed out that a newer Erlang OTP release fixes the problem.)
I would compare Elixr to Go, Java (OpenJDK), Javascript (node) and Rust here. All have passive support for the BSDs, and yet all three have actively maintained native packages (rustup and/or ports tree). That neither the Distllery author nor the BSD users have managed to come up with a solution is quite telling — deployments on Elixir are nightmarishly complex. I'm most familiar with Rust, so in contrast if you look at the the BSD specific issues you'll find a very engaged userbase.
Deploying unmaintained software in production is sometimes a necessity with legacy stuff but is almost always a bad idea for new deployments. Elixir has plenty of passionate advocates but no good deployment or support stories. That's just a long-winded way of saying Elixir/Phoenix, unfortunately, aren't things I would be comfortable deploying in production (Linux or not) no matter how many compelling ideas they dangle in front of you. And, as has been pointed out, Elixr doesn't offer significant (if any performance benefits) over modern Ruby (and by extension Java, Go, or Rust).
vOv
Phoenix doesn't hold a candle to anything JVM or Golang though: https://www.techempower.com/benchmarks/
The main value proposition of Erlang/Elixir is: a very acceptable performance combined with unparalleled concurrency primitives, plus resiliency and high availability. Not performance alone.
Elixir + Phoenix is no faster than CRuby + Sequel/Roda today.
When Elixir was started the common Ruby version was 1.8, a tree walking interpreter with no parallelism. Today's Ruby is nothing like that.
But I almost haven't seen a Rails project using Sequel for 6 years of working with it. 99% of the projects use ActiveRecord.
Since you said you like Rails, have you tried using Ruby with Sequel instead of AR? AR is incredibly convenient but performance isn't a strong point.
Elixir does not have the language patterns of Ruby, though it has a deceptive visual similarity.
As for the reasoning please see https://news.ycombinator.com/item?id=18973348
But then take on the disadvantages of acquiring talent and less adopted programming paradigms (e.g. functional programming)? Elixir/Phoenix is awesome, but it's not a panacea for everything.
Language/framework choices aren't done in a vacuum.
IMO Go is perfect for big companies and somewhat middle companies where they have some heavy traffic that needs to be addressed. I guess Golang is also easier to start with and craft something very fast as opposed to Elixir. (You can check multiple topics on elixirforum.com where people ask why their first-iteration code is slower than that in ruby/python.)
I can be wrong, but I haven't found any golang opinioned-matured web framework, because most of the community is okay with building from the ground up. This may suggest that golang would be preferable in complex/enterprise systems?
I'd choose Elixir for something that has to be done fast and be reliable and open for a lot of modifications that can be introduced without sweating.
My point of view is based on building some simple product in Elixir and doing research. Also, a previous company I worked for had Golang and Ruby stack.
I’ve tinkered with Go, and while it was fairly enjoyable to work with on the small scale, but the lack of generics and constant err != nil checks, and Go 2 on the horizon, I decided to hold off on building anything non-trivial with it.
I’m currently rewriting a Rails app into smaller elixir components, the Rails app is mostly consists of several potentially long running processes that gathers large amounts of data from various sources, does some light transformations, and then combines it and outputs it in various forms. Elixir has been immensely more pleasurable to write in, as OTP, along with things like GenStage and Flow, seem like a perfect fit for this task. And, while go’s channels are cool, they don’t seem nearly as powerful as elixirs actor model/OTP — at least for this example.
The one advantage of Go I can immediately think of is using it for some networking heavy app, which is an area Elixir/Erlang has room for improvement, as making some simple outside http requests isn’t nearly as dead simple, iirc.
- Some programmers don't like functional programming (I'm not one of them)
- Go has static typing and I find it really cuts away bugs
- Go is backed by giants and has the horse power to push forward regardless of "Github stars"
- Go is easy to compile and run on most/many platforms
- I find myself more able to understand third party code
As a web developer, would I use Go as opposed to Phoenix/Elixir? Yes, I am actually using it in production on a fairly big project [1]. I tried Phoenix and I found it "weird" for my liking. The authentication part of a web app was a real deal-braker for me = too complicated to implement (not bad, just too complicated).
I'm the type of guy that brainstorms (90% of my projects are always "close to completion" though) a lot of ideas and wants to go up and running really fast. I can't do that with Python/Elixir/Ruby without many tests written because I don't trust the code/myself all that much.
Where would I use Elixir/Phoenix:
- a chat/support app or anything that relies heavily on websockets
- real-time apps (related to first point)
- apps that rely heavily on distributed tasks
Earnest question: isn't Elixir dynamically typed? If so, how is Go's type system worse? You can always drop down to `interface{}` (the dynamic type) if you like, after all.
> And, while go’s channels are cool, they don’t seem nearly as powerful as elixirs actor model/OTP — at least for this example.
I haven't used Elixir, but I suspect this is true. Elixir/Erlang are probably the only two languages that probably have a better concurrency story than Go; however, there are other facets (tooling, deployment story, learning curve, etc) to consider in choosing a programming language, and I think Go is a really strong language on balance.
Elixir has built in support for type specifications and supports static analysis for (among other things) typechecking via dialyzer, a static analysis tool from the Erlang distribution for the BEAM VM.
As another sibling comment said: they serve different niches. I'd always reach for Elixir/Phoenix for any web app, or even API (if it's a big app). Also anything that requires heavy concurrency -- web spiders, data collectors of many kinds, scatter/gather flows (or any multi-stage flows; Elixir makes those processes brain-dead easy to code) -- then Erlang/Elixir are a no-brainer. People keep wrongfully underestimating them.
But if I am to write a CLI app or a very heavy-duty network daemon, Go is IMO hands down unbeaten and the best possible choice. Also anything that requires serious number crunching.
To be clear, I claimed nothing to the contrary. :) I only argued that concurrency isn't the only criteria in choosing a programming language for a particular project.
Sorry, didn't mean to leave you with the impression that you misworded your comment! :)
Phoenix is a joy to work with, so I like Elixir for the full-stack crud apps that you might otherwise do in Rails. The server-rendered HTML experience is every bit as painless as it is in Rails (this is not a selling point for Go), you get very good tooling for free, Elixir is fun to write, depending on the application the channels/websocket stuff can be a huge lift, etc.
I like Go for stuff that doesn't have a web front end - APIs, CLI tools, background services that need to be fast, etc. In my personal experience based on the small number of Elixir & Go apps I've written (only a few of each), Go gets the edge for performance and server cost. It isn't as quick to prototype in Go as it is in Elixir, but the type system pays off over the long haul.
Again just my quick take - both are really great IMO.