3 ms·

I definitely see how this would be useful for automated tasks. I have some python scripts doing a fair bit of automated data munging that would probably benefit

by arms 12y ago

I definitely see how this would be useful for automated tasks. I have some python scripts doing a fair bit of automated data munging that would probably benefit from being written in Erlang/Elixir. Slight tangent - people often say learning Haskell is worth it for the eye opening experience it provides, regardless of whether you get to use it day-to-day. Would you say the same of Erlang and Elixir?

careersuicide 12y ago
Funny you should ask. I actually started giving an honest go at learning Haskell before I started learning Erlang and later Elixir. So for me, I wouldn't say they were as eye opening as Haskell (truthfully Common Lisp and Scheme gave me more "woah!" moments than anything else so far) simply because of the order in which I learned them. However, if you've never learned Haskell, OCaml, or F# I don't think it's a stretch to say that Elixir/Erlang's similar use of pattern matching and guards would have an eye opening effect that makes it worth learning. In both Haskell and Elixir/Erlang they're a core part of using the languages idiomatically. Once you see it in action you'd be hard pressed to not take some of the lessons with you elsewhere. So, yes. Elixir and Erlang will make you rethink some assumptions about how to solve problems you probably never knew you had. Such as the "necessity" of explicit conditional statements. If anything you'll get better at using recursion to solve actual problems instead of just for contrived classroom-type problems.
lostcolony 12y ago
I can't say explicitly; Haskell is something I keep coming back to playing with but I've never used for any real development, so I can't directly compare them. With that caveat though, Erlang and Elixir are gentler introductions to FP if you've never experienced one, yes. But I wouldn't describe them as functional programming languages, but rather -concurrent- ones. They -will- change how you think about concurrency, distribution, and fault tolerance if you're coming from a more typical OO paradigm. Let it crash, and all the mechanisms and decisions made to ensure that that is a viable strategy, the per process encapsulation of state, the message passing paradigm, the extremely cheap concurrency, and yes, the functional aspect of it, have changed my coding patterns in pretty fundamental ways. To give a real world implication, I had a situation where an unknown number of scheduled tasks had to fire, each one involving multiple steps, with each step being itself a scheduled event (and those times could change). Some could start at the same time. Each one entailed a non-trivial amount of work, IO bound. The traditional approach would be to create a thread pool of the maximal number of simultaneous things I wanted to support, create a heap or similar of all scheduled tasks, peek at the top of the heap, sleep until that amount of time, then put that task onto the threadpool. Repeat. Any changes though...the heap would have to be rebuilt. Or whatever. A whole lot of bookkeeping, basically, and a data structure that does not map to what I'm doing, and which requires locking, and possible race conditions and bottlenecking. In Erlang (and Elixir)? A new process per scheduled event, with a paired timer process to send it a message when it's supposed to start up. Each process is responsible for its own timer; updates to a process cause it to modify its timer, and if a task involves multiple time separated steps, it just creates a new timer when it finishes one, to wake it when it's supposed to do the next. There is no interaction between scheduled items, so why should I have to code around dealing with all of them simultaneously? No locks, no race conditions, no bottlenecking. Bugs are pretty much guaranteed to be in the task code itself, rather than in the task scheduling code, and are much easier to track down and solve.

by arms 12y ago

careersuicide 12y ago

Funny you should ask. I actually started giving an honest go at learning Haskell before I started learning Erlang and later Elixir. So for me, I wouldn't say they were as eye opening as Haskell (truthfully Common Lisp and Scheme gave me more "woah!" moments than anything else so far) simply because of the order in which I learned them. However, if you've never learned Haskell, OCaml, or F# I don't think it's a stretch to say that Elixir/Erlang's similar use of pattern matching and guards would have an eye opening effect that makes it worth learning. In both Haskell and Elixir/Erlang they're a core part of using the languages idiomatically. Once you see it in action you'd be hard pressed to not take some of the lessons with you elsewhere. So, yes. Elixir and Erlang will make you rethink some assumptions about how to solve problems you probably never knew you had. Such as the "necessity" of explicit conditional statements. If anything you'll get better at using recursion to solve actual problems instead of just for contrived classroom-type problems.

lostcolony 12y ago

I can't say explicitly; Haskell is something I keep coming back to playing with but I've never used for any real development, so I can't directly compare them. With that caveat though, Erlang and Elixir are gentler introductions to FP if you've never experienced one, yes. But I wouldn't describe them as functional programming languages, but rather -concurrent- ones. They -will- change how you think about concurrency, distribution, and fault tolerance if you're coming from a more typical OO paradigm. Let it crash, and all the mechanisms and decisions made to ensure that that is a viable strategy, the per process encapsulation of state, the message passing paradigm, the extremely cheap concurrency, and yes, the functional aspect of it, have changed my coding patterns in pretty fundamental ways. To give a real world implication, I had a situation where an unknown number of scheduled tasks had to fire, each one involving multiple steps, with each step being itself a scheduled event (and those times could change). Some could start at the same time. Each one entailed a non-trivial amount of work, IO bound. The traditional approach would be to create a thread pool of the maximal number of simultaneous things I wanted to support, create a heap or similar of all scheduled tasks, peek at the top of the heap, sleep until that amount of time, then put that task onto the threadpool. Repeat. Any changes though...the heap would have to be rebuilt. Or whatever. A whole lot of bookkeeping, basically, and a data structure that does not map to what I'm doing, and which requires locking, and possible race conditions and bottlenecking. In Erlang (and Elixir)? A new process per scheduled event, with a paired timer process to send it a message when it's supposed to start up. Each process is responsible for its own timer; updates to a process cause it to modify its timer, and if a task involves multiple time separated steps, it just creates a new timer when it finishes one, to wake it when it's supposed to do the next. There is no interaction between scheduled items, so why should I have to code around dealing with all of them simultaneously? No locks, no race conditions, no bottlenecking. Bugs are pretty much guaranteed to be in the task code itself, rather than in the task scheduling code, and are much easier to track down and solve.