Do any Ruby programmer find Elxir easier to write or read? Im genuinely curious to hear about this because a lot of Ruby devs are writing Elixir.
Ultimately I find it's easier to go back to some Elixir code and understand what it does, compared to Ruby.
The main reason is (to me) the fact that I now see Ruby object instances as "living things" (with always something hidden underneath, that can change), while Elixir types are more like "stable messages".
So yes, I believe doing Elixir maintenance is ultimately going to be easier than with Ruby.
(Note that I work with both Elixir & Ruby now, and also with Node & other platforms, I don't intend to stop using Ruby at all).
It was helpful that I wrote a bunch of Scala from 2013-2015, so I was familiar with working in an immutable FP style -- that made it a gentler transition for sure.
What have you found hard to read about it? The community is still settling on what code style "should" look like, so maybe you saw some funky Elixir, or maybe it's something deeper.
Not the OP, but: keeping state: Agents, GenServers etc. FP/immutable approach does offer some great advantages, but also makes some otherwise trivial stuff (say, something akin to setting an ivar in Ruby) convoluted and tough to read.
I don't claim to know about your personal situation. Just throwing out a relevant observation.
About 3 weeks ago I dove into Elixir for a big rewrite of a side project as a learning exercise. In the beginning it feels strange, mostly because of the functional way of thinking required and some new types to get used to (structs, keyword lists, etc.). Once you get the hang of it however it feels really, really nice. I dread going back to my rails app now... Others in the thread have stated most of the reasons why so I won't go into that.
I'm looking forward to launching this re-written side project in a few weeks and seeing what the performance is like. (This is currently a stale Django app). Running locally in dev mode the performance (Phoenix) seems like it will be excellent.
In Erlang, I look at 'module_name:function_name' I can simply open the module file and look at the function definition.
In Elixir, I had to ask "Was this function aliased?", "Is it imported from a module? Which module?", "Was it imported/aliased through a use statement?" The code was more concise, but harder to read IMO. Of course you can simply reference functions by their full name in Elixir as well, which is what I'm doing with my own code.
Elixir is pretty great and enthusiasm is good but I feel this leaves a large group of people in the dark.
Perhaps what you mean to say is that you'd like to see more folks in your own communities writing about Elixir with your relevant needs and perspectives in mind.
If you want Elixir to remain obscure as well, keep hoping that it doesn't get picked up by web developers and Rubyists.
I for one want the language to eventually overtake Ruby in popularity (hopefully with Phoenix overtaking Rails). So yeah, the more individuals and communities that adopt it, the better.
With Node, you can cobble together pretty much everything I've described (except for maybe pattern matching) above but it's a bit of a kluge IMO. You can program functionally. And you can make yourself a kind of "compiler" via linting or perhaps by using Flow or Typescript. I've yet to find the experience fluid or pleasant. The language is just not designed for that stuff. ES6 is a huge improvement that said. And before you go thinking I am a node hater, I love JavaScript and use it all the time. I'm just painfully aware of its shortcomings because of how much I work with it.
My biggest issue with Elixir is that it's hard to set up a proper CI/Deployment pipeline. It CAN be done and I've done it but nothing "just works" like it does with Node. Try dockerizing a phoenix app or setting up a heroku instance to see what I mean. All of these things work but it's an obscure language so one needs to be more advanced to understand and address problems in that area.
To sum up: very excited about Elixir and hope it continues to grow. If I was starting a new project I would probably use it.
At Bleacher Report, we've definitely reduced operating costs on some of our services by switching to Elixir and running on fewer/smaller machines, and we routinely pick Elixir for new services now. But we also recently launched a Node service which could handle all frontend traffic on a single server, so in some ways it's hard to say whether the gains are more due to the technology or improvements in the service design.
This can lead to a more complicated architecture than with Elixir, where a single Elixir process will be able to use more RAM & all the cores, too.
On the other hand, I love the dynamism of the Elixir ecosystem, but it's not yet as rich as Node's one, and it's still harder to find a proficient Elixir developer, than a Node one.
But personally yes: the fundations of Elixir are very, very strong, and I'm investing in it completely (in addition to Ruby & Node, which I already use).
* I like the concurrency model better. Lightweight processes vs callbacks and futures. I find processes as concurrency units maps better to problems I had to solve. So there is less impedance mismatch. That makes a huge deal in a larger project. (eg.: a user request as an isolated process vs a chain of callbacks). OS design got this right years ago -- think how most modern popular operating systems represent concurrency - an isolated process.
* Safety & fault tolerance. Processes are isolated. So you can build very robust systems. That simply puts money in your pocket just due to ops costs. A non-critical / experimental part of backend is crashing at 4am and restarting? No, problem, keep sleeping. Rest of the service will stay up and you can fix it in the morning.
* Debuggability and inspection. BEAM VM comes with built in ability to debug, inspect and trace out of the box. That has saved so much time (and money) over the years.
* Hot code reload. This is a first class feature. We don't rely on it to do upgrades. But it proved invaluable to fix an issues or two for a high value customer without taking down the services. Or simply to add extra logging to monitor a pathological edge-case.
Node.js's biggest concurrency perk is non-blocking I/O thanks to a cooperative scheduler. When I/O is about to happen, the scheduler relinquishes control.
Elixir has non-blocking everything. Each process is prescheduled making it impossible for a runaway method to completely takeover the process.
The a comparative example server with millions of small requests in each language. An infinite loop in node would disrupt every other request to the server. In Elixir, the other requests would go on as if nothing happened.
The tradeoff to prescheduling is that you'll never hit a top end benchmark with Elixir vs other fast languages, but you'll get a very consistent response time. Makes it ideal for real time work, which is what most servers really are.
There's many more that other folks are describing here. Natural clustering ability due to lack of shared memory, immutability, message passing, etc. Really cheap processes (goroutine = 2k, elixir process = 0.5k) that makes it so cheap that the model is to create two. One as a supervisor and the other as the actual process. If anything crashes the process, the supervisor instantly restarts it.
The combination of the supervisor tree and prescheduling make it possible to run entire applications within the runtime that other parts of the system depend on. Imagine running a database INSIDE of your Node application. Pair that with the natural clustering ability and you get the ideal platform for a self-contained distributed system. Just keep tacking on servers as you grow.
You'll hear the term "OTP" a lot and that's essentially a set of patterns on top of the foundation that I just described that provides best-practices and models for utilizing the stack in different scenarios.
From what I've seen, people investigate Elixir for the functional programming but stay for the concurrency.
No confusion as to how to import a module and what to namespace it. Just call it. No fuss.
Immutability. Your functions returns transformed data, you don't transform the data itself. That's liberating and makes for such a compelling unit testing experience you find yourself writing more tests to make 100% sure that function does what you want it to do and handle edge cases.
With Node (Javascript), you don't have that. You have a cobbled together solution that works just barely. But how? I don't know.
You npm installed something now the project won't work, you spend three hours debugging and out of desperation you npm install again and now it's working - but why, who knows. Multiply this strange experience to 5 times a day and you get kind of exhausted of Javascript.
Maybe it's not Javascripts fault. Maybe it's Node/NPM itself that ruined the experience, I haven't used Yarn yet.
To summarize his best point: Processor manufacturers are betting the farm on multi-core. They want to increase performance by giving you more running cores, so you should be using a language that makes multiprocess programming easier. Functional languages, especially ones like erlang, do precisely that.
Elixir Should Take Over the World by Jessica Kerr: https://www.youtube.com/watch?v=X25xOhntr6s
What every Node.js developer needs to know about Elixir - Bryan Hunter: https://www.youtube.com/watch?v=q8wueg2hswA
FP and the Erlang VM gives you a great deal of advantages, which you should be aware of.
Ultimately I would also look into node.js, since it's so popular it's becoming a reference, and jobs for javascript/node are easy to get.
1. Has a better standard library, plus easy access to all of Erlang's standard library.
2. Handles concurrency, instead of having to rely on an event loop, and does so in a clean and accessible way.
3. Makes it easy to communicate between processes, not on the same machine, but processes running on other machines as well.
4. Is faster and consumes less resources.
5. Is easier to create, manage, and maintain code and deployments.
My last point is subjective, but I like Elixir's syntax much, much better than Javascript's.
In my opinion, comparing Elixir to Node is like comparing a Tesla to a high-end roller skate.
If you have difficult scaling problems that need stateful servers and clever cross server web socket implementations like Phoenix.Presence or 2 million web socket connection on a single huge machine, Elixir with the OTP is more likely to give you tools to build this difficult to scale thing.
Elixir is a programming language whereas node is a framework.
Something like Express would be more analogous to Phoenix in Elixir.
edit: meant to say phoenix, not elixir.
As far as ivars, you'll have to work hard to emulate that. There are no classes or instances. Probably you want to just use a map or a struct to represent an instance and its state.
Elixir seems poised to keep growing on the backend, so it's probably not a bad one to learn either.
My real advice to someone starting out would be to learn a language but focus on learning general programming and computing concepts through it. The better you are at programming and computing, the more easily you can pick up new languages and switch between them seamlessly.
Also, as you learn new languages, focus on learning the right way to do things in that language. It's extremely helpful to be able to separate programming concepts from language constructs.
Edit: fixed typo referring to Elixir as a framework
I find my IDE to be helpful in this situation, since all macros are compile time and thus can be unwrapped by the IDE.
1. Node has a lot of packages to be sure, but a lot of them are redundant, and a lot of them are packages that overcome some weakness in the Javascript standard library. Elixir doesn't have as many duplicates in its ecosystem, and its standard library is robust enough that you don't have to search for packaged one-liners to overcome some missing feature that should come standard with the language.
2. Node has access to Erlang's standard library and packages. It is also trivial to include external Erlang code and libraries in an Elixir application.
2/ Did you mean "Elixir has access to Erlang ..." rather than "Node...", I assume?
I'm well aware of that (I also use Java libraries quite a lot with JRuby etc, similarly), yet having worked with Erlang developers (in polyglot apps), I still personally find that there is more choice for me in both Node & Rubygems, compared to raw Erlang, at least for the topics we had to cover.
Well - I guess it depends on what your actual needs are, YMMV!
> where a single Elixir process will be able to use more RAM & all the cores, too.
I think you mean a "single instance of the BEAM" here as a single Elixir process is pegged to 1 CPU core.