4 ms·

I've been learning Elixir, which is really good for creating concurrent and scalable systems. Concurrency has always been something that has fascinated me and I

I've been learning Elixir, which is really good for creating concurrent and scalable systems. Concurrency has always been something that has fascinated me and I see in Elixir a chance to make very concurrent code without having to deal with locks, race conditions, and all the other icky low-level stuff. Elixir is also a functional language, making this is the first functional language I've learned, which is another reason I'm enjoying it. Over the past couple years, I've heard from developers who were very satisfied with Elixir, so I finally sat down and started to learn it. As I've been learning Elixir, I've been writing a series called "Learn with Me: Elixir" at https://inquisitivedeveloper.com https://inquisitivedeveloper.com. The idea is that anyone else who's also interested in Elixir can follow along as I learn it and learn it for themselves as well. Of course, playing around with it has also helped me learn far more than just reading about it. Writing about it has helped me learn a lot better, and my hope is that someone else will also find my writing useful.

ElijahLynn 8y ago
Nice, bookmarked as I may be hitting Elixir up soon. For those who want to start at post #1, here ya go > https://inquisitivedeveloper.com/lwm-elixir-1/ https://inquisitivedeveloper.com/lwm-elixir-1/
_asummers 8y ago
I love Elixir. There are very few things that it leaves me wanting from other languages, and I am happy for having added it to my professional tool belt a few years ago. I recommend it for beginners and experienced folk alike. The community is pleasant, industrious, and I feel like I get to code in a sane environment every day with escape hatches in just about every spot I would expect them to exist (due mostly to the macros + BEAM). Though I do not take advantage of this as often as I would like, being able to drop down to native Erlang trivially basically doubles the ecosystem size.
snake117 8y ago
For those who are not aware, Jose Valim (the creator of Elixir) live-streamed all his solutions to this years Advent of Code on Twitch (found here: https://www.twitch.tv/videos/346878345?collection=YDM6eKu6bhV1Nw https://www.twitch.tv/videos/346878345?collection=YDM6eKu6bh...). I found this to be very informative and enjoyable. It is definitely worth checking out regardless of your proficiency in Elixir.
freedomben 8y ago
I second Elixir, but I'd add Phoenix to the pile, especially if you do any web programming. Read these two books, in this order, and buy them from pragprog.com since they are DRM free there: 1. Programming Elixir by Dave Thomas (https://pragprog.com/book/elixir16/programming-elixir-1-6 https://pragprog.com/book/elixir16/programming-elixir-1-6) 2. Programming Phoenix by Chris McCord, Bruce Tate and José Valim (https://pragprog.com/book/phoenix14/programming-phoenix-1-4 https://pragprog.com/book/phoenix14/programming-phoenix-1-4)
freehunter 8y ago
I use Rails for my web programming needs, and I've heard a lot of people talk about switching from Ruby/Rails to Elixir/Phoenix because of "concurrency", but I'm going to be honest and say I don't know what that means. I'm not a CS grad and I'm not super familiar with all of the terminology. Can someone help me with two things? Really trying to understand the benefit. 1. When you say "concurrency" do you just mean "handles more users at the same time" or is there something more to concurrency? I keep seeing web chat applications in tutorials for Elixir but chat is such a small application of a technology that I find it hard to believe the majority of Elixir users are building chat systems. What are you using the concurrency for? Why isn't Rails sufficient for that application? 2. Given that most web apps are CRUD, are there any benefits to using Elixir for a typical CRUD website (other than less-than-tangible things like "it's functional")? Much appreciated!
- _asummers 8y ago
  I'm a single core server, and I have a queue of tasks. I can process them one at a time. But say I don't want to work on one task at a time. I might decide to do some database operation and while I'm waiting for the response to come back, I might decide to do some work on a separate thread so I'm not idling. We now have concurrency. If I add more cores, and my program is coded to be able to take advantage of that, I have more workers to execute that queue and now we have parallelism! If I then go and add separate computers (nodes) and connect them over a network, we have created a distributed system which itself may be a concurrent, parallel system. What Erlang and therefore Elixir gives you is a very sound mental model whereby your communication between nodes and separate workers is done via message passing between Erlang processes (read: not OS processes), and the receiving process may or may not be on the same computer as the sender. Those messages may also be synchronous or asynchronous, depending on what you're doing. It also gives you a nice mental model for failure. Imagine I'm doing some super big indexing of some alphabetized data. It may make sense to subdivide that work along letter bounds, where some worker does A, another does B, ... etc. Suppose the worker for Q failed. What do you do? You may have to kill the entire job, but you might be able to get away with just repeating Q, or maybe even some subset of Q. But you as the worker that just failed are not in the best position to make that decision, so you fail and let your supervisor know, just like in a large organizational structure. That supervisor may decide the whole job is unrecoverable and fail and let ITS supervisor decide what to do. Erlang/Elixir gives you a toolkit to describe these operations via constructs called GenServers and Supervisors that you organize into what are called "supervision trees". It also guarantees "fairness" between your jobs. Say you have the letter example, and whatever you're doing, the letter L s taking WAY more time than anyone else. To preserve overall system integrity, the Erlang VM will decide to say "hey man, you're gonna get a chance to finish but I'm gonna let M get some time for a bit and I'll come back to you." This is called "preemptive scheduling". This gives Erlang its "soft real time" properties. All this to say, you're really setting yourself up to build more complicated systems if you need to. But even if you're not, and you have a typical CRUD app, things like preemptive scheduling are super powerful. Consider a web server. It may make sense to give each request its own process. If you have one that's taking too much time, the system will make sure you're not backing up completely by making sure the next request can run, for at least a little bit. I'm kind of handwaving details here, but this is the general idea behind these types of systems. Erlang as originally designed was to handle telephony switches and such, and therefore had to handle many different callers all at the same time, on systems with not as much parallelism, and therefore being able to process jobs literally simultaneously, but they needed to ensure that the calls waiting to be connected could connect eventually. They also designed around being able to hot upgrade your system. If I'm a telephone pole computer, there's no way they're gonna send a guy out to me to upgrade my system, and I want to make sure I can update the computer while it's still servicing the calls coming through it.
mcintyre1994 8y ago
Elixir sounds like an awesome combination of the advantages of Golang and immutable + functional-first languages, nice!

ElijahLynn 8y ago

Nice, bookmarked as I may be hitting Elixir up soon. For those who want to start at post #1, here ya go > https://inquisitivedeveloper.com/lwm-elixir-1/ https://inquisitivedeveloper.com/lwm-elixir-1/

_asummers 8y ago

I love Elixir. There are very few things that it leaves me wanting from other languages, and I am happy for having added it to my professional tool belt a few years ago. I recommend it for beginners and experienced folk alike. The community is pleasant, industrious, and I feel like I get to code in a sane environment every day with escape hatches in just about every spot I would expect them to exist (due mostly to the macros + BEAM). Though I do not take advantage of this as often as I would like, being able to drop down to native Erlang trivially basically doubles the ecosystem size.

snake117 8y ago

For those who are not aware, Jose Valim (the creator of Elixir) live-streamed all his solutions to this years Advent of Code on Twitch (found here: https://www.twitch.tv/videos/346878345?collection=YDM6eKu6bhV1Nw https://www.twitch.tv/videos/346878345?collection=YDM6eKu6bh...). I found this to be very informative and enjoyable. It is definitely worth checking out regardless of your proficiency in Elixir.

freedomben 8y ago

I second Elixir, but I'd add Phoenix to the pile, especially if you do any web programming. Read these two books, in this order, and buy them from pragprog.com since they are DRM free there: 1. Programming Elixir by Dave Thomas (https://pragprog.com/book/elixir16/programming-elixir-1-6 https://pragprog.com/book/elixir16/programming-elixir-1-6) 2. Programming Phoenix by Chris McCord, Bruce Tate and José Valim (https://pragprog.com/book/phoenix14/programming-phoenix-1-4 https://pragprog.com/book/phoenix14/programming-phoenix-1-4)

freehunter 8y ago

I use Rails for my web programming needs, and I've heard a lot of people talk about switching from Ruby/Rails to Elixir/Phoenix because of "concurrency", but I'm going to be honest and say I don't know what that means. I'm not a CS grad and I'm not super familiar with all of the terminology. Can someone help me with two things? Really trying to understand the benefit. 1. When you say "concurrency" do you just mean "handles more users at the same time" or is there something more to concurrency? I keep seeing web chat applications in tutorials for Elixir but chat is such a small application of a technology that I find it hard to believe the majority of Elixir users are building chat systems. What are you using the concurrency for? Why isn't Rails sufficient for that application? 2. Given that most web apps are CRUD, are there any benefits to using Elixir for a typical CRUD website (other than less-than-tangible things like "it's functional")? Much appreciated!

_asummers 8y ago
I'm a single core server, and I have a queue of tasks. I can process them one at a time. But say I don't want to work on one task at a time. I might decide to do some database operation and while I'm waiting for the response to come back, I might decide to do some work on a separate thread so I'm not idling. We now have concurrency. If I add more cores, and my program is coded to be able to take advantage of that, I have more workers to execute that queue and now we have parallelism! If I then go and add separate computers (nodes) and connect them over a network, we have created a distributed system which itself may be a concurrent, parallel system. What Erlang and therefore Elixir gives you is a very sound mental model whereby your communication between nodes and separate workers is done via message passing between Erlang processes (read: not OS processes), and the receiving process may or may not be on the same computer as the sender. Those messages may also be synchronous or asynchronous, depending on what you're doing. It also gives you a nice mental model for failure. Imagine I'm doing some super big indexing of some alphabetized data. It may make sense to subdivide that work along letter bounds, where some worker does A, another does B, ... etc. Suppose the worker for Q failed. What do you do? You may have to kill the entire job, but you might be able to get away with just repeating Q, or maybe even some subset of Q. But you as the worker that just failed are not in the best position to make that decision, so you fail and let your supervisor know, just like in a large organizational structure. That supervisor may decide the whole job is unrecoverable and fail and let ITS supervisor decide what to do. Erlang/Elixir gives you a toolkit to describe these operations via constructs called GenServers and Supervisors that you organize into what are called "supervision trees". It also guarantees "fairness" between your jobs. Say you have the letter example, and whatever you're doing, the letter L s taking WAY more time than anyone else. To preserve overall system integrity, the Erlang VM will decide to say "hey man, you're gonna get a chance to finish but I'm gonna let M get some time for a bit and I'll come back to you." This is called "preemptive scheduling". This gives Erlang its "soft real time" properties. All this to say, you're really setting yourself up to build more complicated systems if you need to. But even if you're not, and you have a typical CRUD app, things like preemptive scheduling are super powerful. Consider a web server. It may make sense to give each request its own process. If you have one that's taking too much time, the system will make sure you're not backing up completely by making sure the next request can run, for at least a little bit. I'm kind of handwaving details here, but this is the general idea behind these types of systems. Erlang as originally designed was to handle telephony switches and such, and therefore had to handle many different callers all at the same time, on systems with not as much parallelism, and therefore being able to process jobs literally simultaneously, but they needed to ensure that the calls waiting to be connected could connect eventually. They also designed around being able to hot upgrade your system. If I'm a telephone pole computer, there's no way they're gonna send a guy out to me to upgrade my system, and I want to make sure I can update the computer while it's still servicing the calls coming through it.

mcintyre1994 8y ago

Elixir sounds like an awesome combination of the advantages of Golang and immutable + functional-first languages, nice!