4 ms·

What are you using it for, out of curiosity? I am not at all saying this is you, to be clear, but one problem I have had in the past looking for Erlang jobs is

by davidw 3y ago

What are you using it for, out of curiosity? I am not at all saying this is you, to be clear, but one problem I have had in the past looking for Erlang jobs is that occasionally you find people who view it as some kind of magic sauce, or "I'm curious to see what it's like". In the former case, they think just writing their code in Erlang is going to give it magic scaling powers. This is probably less common these days, but I recall a while back when Erlang first got a bit of hype, there were people who weren't thinking very clearly about it. In the latter case, sometimes it's not the best tool for the job but someone wanted to learn the intriguing new thing. Edit: and of course there are great use cases for it. See my other comment elsewhere on a system where it was a great fit. I'm always curious to see where others are using it successfully.

sph 3y ago
There is no silver bullet. but also Choose the right tool for the job. Plenty of people build highly tolerant, robust distributed system of top of regular languages when Erlang exists, and no one bats an eye. Erlang is no magic sauce, but for its niche it is unrivalled and yet routinely ignored in favour of subpar platforms because of dubious concerns such as "there are no Erlang/Elixir developers around", which is nonsense. The true reason is that there are plenty of engineers and architects that have no exposure to the BEAM, so have no idea how productive they could be developing their distributed system on it. They simply do not know what Erlang & co. could do for them.
- davidw 3y ago
  > Choose the right tool for the job. Certainly, but for each and every small task you do, you don't evaluate a new language for it. If you have a web application that's done in Rails and have a bunch of Ruby programmers, if you need to, say, add a simple web scraping system to it in house, you're likely going to reach for a Ruby tool at first. On one side, you have shops that are like "we only use Java". They're maybe missing out on some good tools for various tasks. The other extreme would be a big list of languages, and that's difficult to maintain as people come and go.
  - sph 3y ago
    Erlang is not just a language, is a different paradigm, and it is worth evaluating, just like deciding whether you need a native language, or Python's enough. Are you building a distributed system? Are you building a highly concurrent IO-bound server? Are you building a system that needs to be fault-tolerant? Going for anything other than Erlang/Elixir is a misinformed choice.
    - davidw 3y ago
      Yes, I'm quite familiar with BEAM and OTP, having used it for nearly 20 years. See my comments elsewhere. The thing is, most people don't start out wanting a distributed system, it's something you get when you've scaled to a certain size. If you know you need it, and Erlang's version of it is a good fit, yes, it's a good way to start.
    - bongobingo1 3y ago
      For me the question often hasn't been "is it distributed" but "how often do you need to spawn some async task (that can be run supervised, or unsupervised, in a fault tolerant manner)". I find that is often a lot more relatable to average-joe-tasks than bigger picture distributed ideas, even if they're actually the same thing at their heart. I just don't want one request to blow out the system, or some sporadically turned remote API to hose everything, Elixir gives me that (with the simplicity other languages often need other stuff stuck onto to handle).
      - davidw 3y ago
        It's kind of ironic that stock Erlang/OTP has fairly crude tools for "spawn some async task" and deal with it failing. Your options are * Keep trying to restart it forever if it fails (by setting the timeout so low that it'll keep trying) * Try a set number of restarts, then pass the failure higher up, potentially taking down the whole system if there are enough failures. * Just let it fail and walk away. https://www.erlang.org/doc/design_principles/sup_princ.html#restart-strategy https://www.erlang.org/doc/design_principles/sup_princ.html#... If you have something like a web site with a database, where 1) the database is critical to the normal functioning of the system, but 2) you still want the site up to let users know that "it's broken and we're fixing it", and maybe also send some alerts out, you might want something more like an exponential backoff or some other more involved strategy, which isn't shipped with Erlang.
l72 3y ago
My company has a real time communication system: Real time video/audio/chat. Elixir/Erlang works fantastic for this, as you are doing a lot of real time message passing, creating temporary sessions/channels for communication, and monitoring tasks. We've been able to easily scale with minimal effort and have never had downtime.

by davidw 3y ago

sph 3y ago

There is no silver bullet. but also Choose the right tool for the job. Plenty of people build highly tolerant, robust distributed system of top of regular languages when Erlang exists, and no one bats an eye. Erlang is no magic sauce, but for its niche it is unrivalled and yet routinely ignored in favour of subpar platforms because of dubious concerns such as "there are no Erlang/Elixir developers around", which is nonsense. The true reason is that there are plenty of engineers and architects that have no exposure to the BEAM, so have no idea how productive they could be developing their distributed system on it. They simply do not know what Erlang & co. could do for them.

davidw 3y ago
> Choose the right tool for the job. Certainly, but for each and every small task you do, you don't evaluate a new language for it. If you have a web application that's done in Rails and have a bunch of Ruby programmers, if you need to, say, add a simple web scraping system to it in house, you're likely going to reach for a Ruby tool at first. On one side, you have shops that are like "we only use Java". They're maybe missing out on some good tools for various tasks. The other extreme would be a big list of languages, and that's difficult to maintain as people come and go.
- sph 3y ago
  Erlang is not just a language, is a different paradigm, and it is worth evaluating, just like deciding whether you need a native language, or Python's enough. Are you building a distributed system? Are you building a highly concurrent IO-bound server? Are you building a system that needs to be fault-tolerant? Going for anything other than Erlang/Elixir is a misinformed choice.
  - davidw 3y ago
    Yes, I'm quite familiar with BEAM and OTP, having used it for nearly 20 years. See my comments elsewhere. The thing is, most people don't start out wanting a distributed system, it's something you get when you've scaled to a certain size. If you know you need it, and Erlang's version of it is a good fit, yes, it's a good way to start.
  - bongobingo1 3y ago
    For me the question often hasn't been "is it distributed" but "how often do you need to spawn some async task (that can be run supervised, or unsupervised, in a fault tolerant manner)". I find that is often a lot more relatable to average-joe-tasks than bigger picture distributed ideas, even if they're actually the same thing at their heart. I just don't want one request to blow out the system, or some sporadically turned remote API to hose everything, Elixir gives me that (with the simplicity other languages often need other stuff stuck onto to handle).
    - davidw 3y ago
      It's kind of ironic that stock Erlang/OTP has fairly crude tools for "spawn some async task" and deal with it failing. Your options are * Keep trying to restart it forever if it fails (by setting the timeout so low that it'll keep trying) * Try a set number of restarts, then pass the failure higher up, potentially taking down the whole system if there are enough failures. * Just let it fail and walk away. https://www.erlang.org/doc/design_principles/sup_princ.html#restart-strategy https://www.erlang.org/doc/design_principles/sup_princ.html#... If you have something like a web site with a database, where 1) the database is critical to the normal functioning of the system, but 2) you still want the site up to let users know that "it's broken and we're fixing it", and maybe also send some alerts out, you might want something more like an exponential backoff or some other more involved strategy, which isn't shipped with Erlang.

l72 3y ago

My company has a real time communication system: Real time video/audio/chat. Elixir/Erlang works fantastic for this, as you are doing a lot of real time message passing, creating temporary sessions/channels for communication, and monitoring tasks. We've been able to easily scale with minimal effort and have never had downtime.