So I am trying to move away from NodeJs for my next project and I can't decide between Elixir and Go. Can't decide what to choose, any idea if there is any advantage for a noob to learn one or the other?
I built a web app in Go recently, and while it was enjoyable, progress was pretty slow. I eventually decided to change gears and rebuild it in Elixir, and so far I have no regrets. Phoenix is pretty fast, awesome, and powerful. There are a few concepts you have to learn, but overall it's been a much simpler experience and way faster to prototype with.
I don't think getting started is hard, but diving into the heavy concepts could be overwhelming. Macros can be weird, and I still have to think through a lot whenever I make a foreign table relation in Ecto, since you have to create the migration (which is a way to build your database with code) AND the changeset (which is basically an elixir object that maps to the table).
Anyways, Elixir is functional, which isn't that difficult. Javascript is partially functional, but if you're used to Java or C++ you'll want to approach it with an open mind. If you've ever used F#, or C# with LINQ before, then you'll be familiar waters.
I bought the Programming Phoenix book, and it does a pretty good job, but with Phoenix 1.3 it's already out-of-date. However, it's still good reference material for the underlying concepts.
This list of open-source phoenix apps has saved my ass a couple times as well. I probably look at changelog.com's source the most since it's by far the most active project here: https://github.com/droptheplot/awesome-phoenix
I know it's not the most helpful information, but truth be told there's no secret to learn it, you just gotta do it and fuck it up a few times to get it right.
I don’t see why you move away from Node unless it was for a JAVA spring boot or .net core, especially now that node has actually begun to enter real world usage and enterprise on a large scale.
Then again I would have said something similar about picking up Node in the earlier days, so who knows.
I doubt Go and Ekixir will ever gain the same reach Node has though. Node has the advantage of JavaScript being an unavoidable part of your web stack, so it’ll always have value. With more and more IoT picking up Node as well, it has a bright future.
Given the two choices, I’d go with Elixir. Golang is hyped in America, but it has really terrible production times and isn’t really good at anything except a few use cases.
This won’t be a popular opinion, but my context is Danish enterprise, and I’ve never seen anyone hire a Go or Elixir programmer, and I honestly doubt I ever will because the majority of our backend workforce is either JAVA or .Net.
Learning new tech is great of course, but I’d rather hire someone who was really great at one particularly stack than someone who was mediocre at multiple. Anyone can make a simple web-app in Go, Node, Elixir, Django, Asp or Java, but what I would need my hires to do was things like OIOSAML authentication with ADFS, and if you can’t do that because you learned Go instead of playing around with passport.js, you’d quite honestly not get hired.
I'm looking for a web job in Paris at the moment and there is definitely many Go offering, maybe not be as much as Java or C# (I don't look for those) but still.
Also I went to the last Elixir meetup and there is some companies hiring, but it's obviously very new.
I’d say it depends on what you want to build (disclaimer: I have written a lot of Go but have only read Elixir source). If full stack monolith, use Elixir because of Phoenix; if microservice arch, use Go with gRPC protobufs for messaging.
IMO, both languages seem to result in very readable source code; and many examples of how to do either exist on GitHub.
Scaling parts of the application independently from each other. If traffic spikes in one part of the application (e.x.: your image categorization web app was posted in a cat forum) more nodes can be added to that one resource to handle the load. Another reason could be worker processes that ran intermittently at midnight every day (e.x.: to email users top pics they missed that day).
Isn't that the whole point of the Erlang/Elixir/OTP actor model and BEAM VM? It seems like many systems with microservice architecture are reinventing that wheel only worse - except in the cases where the system needs to use legacy or polyglot services.
The difference is in the network boundaries. I write most of my code as microservices, but it would be incredibly easy to wrap it all up into a single binary.
It's not uncommon for go code to have one binary for separate microservice functions (see OKLog). This way you can change between a microservice, or a monolith (ish) with a CLI flag.
Why not both? Take the most popular web frameworks and see how quickly you ramp up in say a week or two week sprint.
I'm more of a fan of the Ruby syntax and the Phoenix framework is definitely a breath of fresh air. My next web project wants to be with Elixir but for a generic cross platform cli program, I'm eager to learn Go.
Do both and and then make an educated decision on which languages fits best for the project goals. They are different tools. But to be honest, I'm an Elixir fan :-)
When I decide about a tool/language (I have learned now dozens) I just think in the HARDEST task that I could possible anticipate. Also, I do some basic stuff. In my case, I try to see how well is to interface with RDBMS.
I try to do it with them and then decide.
So, in short, build a mental "benchmark" that is representative to help to decide if X is right for you