11 ms·

We use elixir 24/7 on all projects. All the new programmers that ever worked with us never knew Elixir in the first place. And all of them picked it up in a co

We use elixir 24/7 on all projects. All the new programmers that ever worked with us never knew Elixir in the first place. And all of them picked it up in a couple of weeks to a level where they could start making changes to code. I think we are overestimating the amount of time it takes to learn a new language. The hardest thing to grok with FP is immutable data. Once you get past that, you're rolling. But the speed and concurrency is no laughing matter. Miles and miles and miles ahead of ruby, python, etc in that matter. Task.start(...) Spin off a background process from a web request where you don't care to get back something. Basically eliminate Redis or caching. Just need Postgresql/Mysql. If you're wild eyed you can use Mnesia without the databases. Run jobs across a cluster sanely with a good job library that only needs Postgresql. The story goes on and on. Unless you have tons and tons invested into what you're doing right now, it makes a lot of sense to start to spin up things on the edge of your monolith or SOA with Elixir. New projects should be started with Elixir. The idea that it's "hard to find programmers" -- does not really stand up. Because anyone who can't grok a new programming language in a short time, is not really a good programmer.

gameswithgo 5y ago
elixr vs clojure? f#?
- macintux 5y ago
  Clojure if you need JVM integration. F# if you need to run on Windows (the BEAM runs under Windows, but it's to the best of my recollection not a point of emphasis). Elixir if you want a robust concurrency story and a rock-solid way of handling errors without lots of code cluttering up your business logic. I'd pick Erlang myself, but Elixir is compelling.
  - RexM 5y ago
    I’ve had no issues running the BEAM on Windows.
    - macintux 5y ago
      I see it’s running now using WSL; I don’t believe that was the case when I worked with Erlang years ago, but it’s pretty fuzzy at this point.
      - lostcolony 5y ago
        Not sure about that particular point, but I will agree from experience that working with Erlang on Windows years back was painful, and that it is relatively pain free nowadays.
  - Nelkins 5y ago
    Just to clear up a common misconception, you can run F# on Windows, Linux, or macOS. I worked at a company for two years writing F# and never touched a Windows machine.
ashton314 5y ago
> The idea that it's "hard to find programmers" -- does not really stand up. Because anyone who can't grok a new programming language in a short time, is not really a good programmer. This this THIS! I have a profound philosophical disagreement with CS professors (usually professors who retired from industry into academia) who think that part of the job of the CS curriculum is to equip students with a language and think that learning multiple languages will dilute their focus or some bull crap like that. Learning new languages is not hard! It is much better to learn how to learn new languages, than it is to learn one language really really well. Learning multiple languages will give you the mental tools to use other languages to their fullest extent.
- chii 5y ago
  > learn how to learn new languages that's unfortunately not taught at university. people who are already quite bright will pick this skill up by osmosis or naturally. People who dont know how to learn often struggle. at no stage in the k-12 education curriculum does learning how to learn gets taught systematically.
  - chakkepolja 5y ago
    This is true. I have had java professors never explain subtype relationship or interfaces properly. Without understanding basic concepts that underlie programming languages, mechanically teaching syntax (with language specific OOP buzz words), is ensured to only confuse students when learning new languages. Rather teach them how polymorphism works, what's a virtual function and a function pointer, any student worth their salt will understand why things are the way they are.
    - chii 5y ago
      > Without understanding basic concepts it's even more meta than that. Learning to learn is not easy, but can be taught. It requires some introspection - what it is that you don't understand about a subject, as well as _why_ you'd be learning it. In university classes, the professors aim is to teach the material (despite them mostly not wanting to do teaching, but merely a requirement to exist as a professor) - so a lot of them just teach the materials directly (aka, present facts). These sort of teaching style is only good if the student is already a sponge and can remember the material. For students who aren't interested, but their course requires it, the learning is stunted because there's no context for which the student can grab hold of to learn the material. And then, the order in which the material is presented makes a lot of difference - teaching OOP, in my experience, tends to start with inheritance, how the language (like java treats) inheritance, and so on, as the course goes along introducing more of the java language. But they don't teach the surrounding context, like how it compares to C++, or haskell, or LISP. Learning like this is like learning how to walk on stilts.
derefr 5y ago
> But the speed and concurrency is no laughing matter. Miles and miles and miles ahead of ruby, python, etc in that matter. People always make this comparison, which I feel is a bit weak/unconvincing. It's pretty easy to beat Ruby or Python in concurrency; most language runtimes do it. Something most people might not realize is that Erlang/BEAM is miles ahead of even Java/the JVM, when it comes to operationalizing its concurrency — that is, building services that are robust in the face of heterogeneous workloads and misbehaving clients. Ever tried to build a RESTful web service, that performs unpredictable-runtime tasks in response to user requests, but which budgets that runtime such that requests are hard-killed (and their resources freed) after a deadline, and/or if the client closes their TCP socket — even if they're in the middle of some some CPU-intensive hot loop — and which makes sure to "push down" that failure into resource-handles like DB sockets, such that the DB "sees" the failure and gives up on its related long-running CPU-intensive task as well? This is a Hard Problem in Java, with a huge number of little considerations involved: lots of calls to Thread.interrupted; async requests; CompletableFutures; moving any parallel streams to their own explicit ForkJoinPools, etc. You can see the Project Loom team slowly giving the Java stdlib a working-over in this style, but even after their work becoming Generally Available, library authors will still need to do all this stuff as well. In Erlang/Elixir, meanwhile: 1. the accepted TCP connection is a process, 2. the web request runs either inside it or in another process linked to it, such that either one dying kills the other, 3. any concurrent Tasks get linked to the TCP connection process that spawned them as well; 4. any DB calls temporarily link the checked-out DB connection to the request process as well; and 5. adding request deadlines is as easy as calling a function to spawn a deadline timer pointed at the spawning process's own head. Essentially, idiomatic Erlang/Elixir code gets this type of robustness for free, with zero additional lines of code. The moment you have an Erlang web server, you have a robust Erlang web server. (Erlang/BEAM is also miles ahead of Golang in operationalizing concurrency, for separate reasons, mostly to do with goroutine resource leaks. Separate topic, but I just figured someone would ask.) And then there's the fact that per-process heaps mean most short-running request-response type workloads can get away with never making a garbage-collection call, instead just allocating a pre-sized arena with each process, doing work, and then tossing away that arena when the process quits. So, as long as you've built your Erlang/Elixir app idiomatically, doing each task in a process that doesn't survive the lifetime of the task — then you'll never see the same sort of gradual "putting off GC for later" asymptotic allocated-memory climb that you see in a most GCed languages.
tiffanyh 5y ago
So many people talk Erlang / Elixir insane concurrency … but I’m struggling to reconcile the talk with what I find in stress testing and benchmarks results. Can you comment on why so many benchmarks show Erlang / Elixir performing significantly worse than other languages like Go. https://stressgrid.com/blog/webserver_benchmark/ https://stressgrid.com/blog/webserver_benchmark/ https://stressgrid.com/blog/cowboy_performance/ https://stressgrid.com/blog/cowboy_performance/ https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ EDIT: why the downvotes? I’d rather you post a comment to me so we can have a health dialogue.
- eric4smith 5y ago
  Elixir does not a fantastic computational story. That's why it has NIF's to bring in things like C or Rust to deal with the math stuff. Languages like Go, C, Rust will always beat Elixir/Erlang in the computationally intensive benchmarks. You would chose Elixir/Phoenix/Erlang for the concurrency and networking story.
  - tiffanyh 5y ago
    But note, all of the benchmarks I posted in my parent post(especially the first two) are concurrency workloads - not numeric. And Erlang still performed noticeably worse than other languages.
    - toolz 5y ago
      > Erlang still performed noticeably worse than other languages I think you need to define worse here...unpredictable spikes in latency will give you plenty of headaches when trying to guess how much hardware you should throw at a service. Erlang's consistent latency here is what I would choose above everything that benchmark shows for almost every problem I've ever solved. Going fast at all costs is not a desirable trait for my software and I suspect it isn't for most peoples software. I want predictable behavior that operates gracefully under extreme circumstances.
    - jerf 5y ago
killingtime74 5y ago
Many of these things are not exclusive to elixir though. Scala and Akka come to mind
devoutsalsa 5y ago
> The hardest thing to grok with FP is immutable data. A lack of understanding how concurrency works can really screw you up in Elixir. > Task.start(...) I almost never use task, because I like certainty. I've been bitten too badly by people using it who didn't understand it. I don't like having to explain `Enum.each(tasks, &Task.start/1 )` is going to screw up your order of operations to someone who doesn't get it. > Basically eliminate Redis or caching. It's easy to start off thinking that, but then you can end up spending a lot of time maintaining subpar libraries you've written in-house that don't have the nicer features of the thing you replaced. Also, caching can turn into quite the memory hog. > Run jobs across a cluster sanely with a good job library that only needs Postgresql. It's all fun & games until you have to undo everything so you can containerize the apps. > If you're wild eyed you can use Mnesia without the databases. I've used DETS & hate it quite a bit, I really don't want to be married to Mnesia. > New projects should be started with Elixir. I love Elixir, but I wouldn't use it for everything, and it's got a lot of sharp edges that can get you into a lot of trouble.
- rkangel 5y ago
  >> Task.start(...) > I almost never use task, because I like certainty. I've been bitten too badly by people using it who didn't understand it. I don't like having to explain `Enum.each(tasks, &Task.start/1 )` is going to screw up your order of operations to someone who doesn't get it. I don't understand this. In any language with any concurrency support there's a point where you spin up a bunch of threads to do something. That's a useful capability and developers should understand it. If you don't know Elixir then you need to learn what Task does, but that's true in any language.
  - valenterry 5y ago
    > In any language with any concurrency support there's a point where you spin up a bunch of threads to do something. No, that's not true. Think javascript (and I hate javascript): you can do concurrency even though you literally don't have a way to spin up a thread in the browser.
    - 5y ago
hinkley 5y ago
It does sort of seem like the majority of people who understand this end up at the sort of company that is willing to try out a new tool. I think in a lot of ways StackOverflow has changed this dynamic. Previously I benefited from memorizing all of the API functions that return slightly different responses than their peers. This one returns null instead of an empty array. This one mutates the second argument. This one has n^2 complexity, and so on. Now, after doing Java, Javascript, Ruby, lots of bash, a bit of Python, and a few sundry other things, I don't trust my memory. I go check every time, because it's cheap enough to find the comments that say "be careful". What I need most is a toolbox full of Important Questions. Important Questions scale logarithmically across languages and many problem domains. Important Answers do not.

gameswithgo 5y ago

elixr vs clojure? f#?

macintux 5y ago
Clojure if you need JVM integration. F# if you need to run on Windows (the BEAM runs under Windows, but it's to the best of my recollection not a point of emphasis). Elixir if you want a robust concurrency story and a rock-solid way of handling errors without lots of code cluttering up your business logic. I'd pick Erlang myself, but Elixir is compelling.
- RexM 5y ago
  I’ve had no issues running the BEAM on Windows.
  - macintux 5y ago
    I see it’s running now using WSL; I don’t believe that was the case when I worked with Erlang years ago, but it’s pretty fuzzy at this point.
    - lostcolony 5y ago
      Not sure about that particular point, but I will agree from experience that working with Erlang on Windows years back was painful, and that it is relatively pain free nowadays.
- Nelkins 5y ago
  Just to clear up a common misconception, you can run F# on Windows, Linux, or macOS. I worked at a company for two years writing F# and never touched a Windows machine.

ashton314 5y ago

> The idea that it's "hard to find programmers" -- does not really stand up. Because anyone who can't grok a new programming language in a short time, is not really a good programmer. This this THIS! I have a profound philosophical disagreement with CS professors (usually professors who retired from industry into academia) who think that part of the job of the CS curriculum is to equip students with a language and think that learning multiple languages will dilute their focus or some bull crap like that. Learning new languages is not hard! It is much better to learn how to learn new languages, than it is to learn one language really really well. Learning multiple languages will give you the mental tools to use other languages to their fullest extent.

chii 5y ago
> learn how to learn new languages that's unfortunately not taught at university. people who are already quite bright will pick this skill up by osmosis or naturally. People who dont know how to learn often struggle. at no stage in the k-12 education curriculum does learning how to learn gets taught systematically.
- chakkepolja 5y ago
  This is true. I have had java professors never explain subtype relationship or interfaces properly. Without understanding basic concepts that underlie programming languages, mechanically teaching syntax (with language specific OOP buzz words), is ensured to only confuse students when learning new languages. Rather teach them how polymorphism works, what's a virtual function and a function pointer, any student worth their salt will understand why things are the way they are.
  - chii 5y ago
    > Without understanding basic concepts it's even more meta than that. Learning to learn is not easy, but can be taught. It requires some introspection - what it is that you don't understand about a subject, as well as _why_ you'd be learning it. In university classes, the professors aim is to teach the material (despite them mostly not wanting to do teaching, but merely a requirement to exist as a professor) - so a lot of them just teach the materials directly (aka, present facts). These sort of teaching style is only good if the student is already a sponge and can remember the material. For students who aren't interested, but their course requires it, the learning is stunted because there's no context for which the student can grab hold of to learn the material. And then, the order in which the material is presented makes a lot of difference - teaching OOP, in my experience, tends to start with inheritance, how the language (like java treats) inheritance, and so on, as the course goes along introducing more of the java language. But they don't teach the surrounding context, like how it compares to C++, or haskell, or LISP. Learning like this is like learning how to walk on stilts.

derefr 5y ago

> But the speed and concurrency is no laughing matter. Miles and miles and miles ahead of ruby, python, etc in that matter. People always make this comparison, which I feel is a bit weak/unconvincing. It's pretty easy to beat Ruby or Python in concurrency; most language runtimes do it. Something most people might not realize is that Erlang/BEAM is miles ahead of even Java/the JVM, when it comes to operationalizing its concurrency — that is, building services that are robust in the face of heterogeneous workloads and misbehaving clients. Ever tried to build a RESTful web service, that performs unpredictable-runtime tasks in response to user requests, but which budgets that runtime such that requests are hard-killed (and their resources freed) after a deadline, and/or if the client closes their TCP socket — even if they're in the middle of some some CPU-intensive hot loop — and which makes sure to "push down" that failure into resource-handles like DB sockets, such that the DB "sees" the failure and gives up on its related long-running CPU-intensive task as well? This is a Hard Problem in Java, with a huge number of little considerations involved: lots of calls to Thread.interrupted; async requests; CompletableFutures; moving any parallel streams to their own explicit ForkJoinPools, etc. You can see the Project Loom team slowly giving the Java stdlib a working-over in this style, but even after their work becoming Generally Available, library authors will still need to do all this stuff as well. In Erlang/Elixir, meanwhile: 1. the accepted TCP connection is a process, 2. the web request runs either inside it or in another process linked to it, such that either one dying kills the other, 3. any concurrent Tasks get linked to the TCP connection process that spawned them as well; 4. any DB calls temporarily link the checked-out DB connection to the request process as well; and 5. adding request deadlines is as easy as calling a function to spawn a deadline timer pointed at the spawning process's own head. Essentially, idiomatic Erlang/Elixir code gets this type of robustness for free, with zero additional lines of code. The moment you have an Erlang web server, you have a robust Erlang web server. (Erlang/BEAM is also miles ahead of Golang in operationalizing concurrency, for separate reasons, mostly to do with goroutine resource leaks. Separate topic, but I just figured someone would ask.) And then there's the fact that per-process heaps mean most short-running request-response type workloads can get away with never making a garbage-collection call, instead just allocating a pre-sized arena with each process, doing work, and then tossing away that arena when the process quits. So, as long as you've built your Erlang/Elixir app idiomatically, doing each task in a process that doesn't survive the lifetime of the task — then you'll never see the same sort of gradual "putting off GC for later" asymptotic allocated-memory climb that you see in a most GCed languages.

tiffanyh 5y ago

So many people talk Erlang / Elixir insane concurrency … but I’m struggling to reconcile the talk with what I find in stress testing and benchmarks results. Can you comment on why so many benchmarks show Erlang / Elixir performing significantly worse than other languages like Go. https://stressgrid.com/blog/webserver_benchmark/ https://stressgrid.com/blog/webserver_benchmark/ https://stressgrid.com/blog/cowboy_performance/ https://stressgrid.com/blog/cowboy_performance/ https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ EDIT: why the downvotes? I’d rather you post a comment to me so we can have a health dialogue.

eric4smith 5y ago
Elixir does not a fantastic computational story. That's why it has NIF's to bring in things like C or Rust to deal with the math stuff. Languages like Go, C, Rust will always beat Elixir/Erlang in the computationally intensive benchmarks. You would chose Elixir/Phoenix/Erlang for the concurrency and networking story.
- tiffanyh 5y ago
  But note, all of the benchmarks I posted in my parent post(especially the first two) are concurrency workloads - not numeric. And Erlang still performed noticeably worse than other languages.
  - toolz 5y ago
    > Erlang still performed noticeably worse than other languages I think you need to define worse here...unpredictable spikes in latency will give you plenty of headaches when trying to guess how much hardware you should throw at a service. Erlang's consistent latency here is what I would choose above everything that benchmark shows for almost every problem I've ever solved. Going fast at all costs is not a desirable trait for my software and I suspect it isn't for most peoples software. I want predictable behavior that operates gracefully under extreme circumstances.
  - jerf 5y ago

killingtime74 5y ago

Many of these things are not exclusive to elixir though. Scala and Akka come to mind

devoutsalsa 5y ago

> The hardest thing to grok with FP is immutable data. A lack of understanding how concurrency works can really screw you up in Elixir. > Task.start(...) I almost never use task, because I like certainty. I've been bitten too badly by people using it who didn't understand it. I don't like having to explain `Enum.each(tasks, &Task.start/1 )` is going to screw up your order of operations to someone who doesn't get it. > Basically eliminate Redis or caching. It's easy to start off thinking that, but then you can end up spending a lot of time maintaining subpar libraries you've written in-house that don't have the nicer features of the thing you replaced. Also, caching can turn into quite the memory hog. > Run jobs across a cluster sanely with a good job library that only needs Postgresql. It's all fun & games until you have to undo everything so you can containerize the apps. > If you're wild eyed you can use Mnesia without the databases. I've used DETS & hate it quite a bit, I really don't want to be married to Mnesia. > New projects should be started with Elixir. I love Elixir, but I wouldn't use it for everything, and it's got a lot of sharp edges that can get you into a lot of trouble.

rkangel 5y ago
>> Task.start(...) > I almost never use task, because I like certainty. I've been bitten too badly by people using it who didn't understand it. I don't like having to explain `Enum.each(tasks, &Task.start/1 )` is going to screw up your order of operations to someone who doesn't get it. I don't understand this. In any language with any concurrency support there's a point where you spin up a bunch of threads to do something. That's a useful capability and developers should understand it. If you don't know Elixir then you need to learn what Task does, but that's true in any language.
- valenterry 5y ago
  > In any language with any concurrency support there's a point where you spin up a bunch of threads to do something. No, that's not true. Think javascript (and I hate javascript): you can do concurrency even though you literally don't have a way to spin up a thread in the browser.
  - 5y ago

hinkley 5y ago

It does sort of seem like the majority of people who understand this end up at the sort of company that is willing to try out a new tool. I think in a lot of ways StackOverflow has changed this dynamic. Previously I benefited from memorizing all of the API functions that return slightly different responses than their peers. This one returns null instead of an empty array. This one mutates the second argument. This one has n^2 complexity, and so on. Now, after doing Java, Javascript, Ruby, lots of bash, a bit of Python, and a few sundry other things, I don't trust my memory. I go check every time, because it's cheap enough to find the comments that say "be careful". What I need most is a toolbox full of Important Questions. Important Questions scale logarithmically across languages and many problem domains. Important Answers do not.