5 ms·

I think the main argument is that Elixir isn't as mainstream which is a fair point. That said I agree with everything, Erlang pioneered in this space and has s

I think the main argument is that Elixir isn't as mainstream which is a fair point. That said I agree with everything, Erlang pioneered in this space and has shown to scale very well[1] in a proven way over the last few decades. [1] https://phoenixframework.org/blog/the-road-to-2-million-websocket-connections https://phoenixframework.org/blog/the-road-to-2-million-webs...

mirceal 8y ago
Yes. Because mainstream is what you should select for when choosing your tools. On a more serious note: I’m very wary of people that have discovered the one true language, framework, etc. That’s how you end up with 100 lines of go instead a one line bash script. That’s how you end up with “java developers” that are more concerned with design patterns instead of actual working code. I could go on. Learn about as many things possible, form your own opinions, choose the right tool for the job.
- hmschreck 8y ago
  We had a developer interview here who was an Elixir zealot - and I use that word entirely purposefully. He was very adamant that we needed to rewrite our entire platform in Elixir because it was obviously better. We ended up not hiring; he refused to touch certain technologies that make up a core part of our stack (Node being the biggest issue), and he was honestly something of a massive tool -- on our take-home thing (takes most developers maybe a few hours) he limited himself to one hour, didn't get it done, wasn't even solving the right problem, and, when he sent in his solution... "It's ok, I know you won't get it, but that's OK."
  - EpicEng 8y ago
    Run, run far away... (I realize you did, but man...)
  - mirceal 8y ago
    a zealot is a zealot is a zealot. you don't get much info from the strong preferences of a zealot. you just quickly learn that you need to avoid them. refusing to touch the tech stack of the person that pays your bills if flat out stupid. if you don't touch it why am I hiring you? depending on how much experience this person had this behavior may be correctable if he/she is lucky enough to find a more senior developer that can show them how their [stupid] choices impact the project and how they can eliminate whole classes of problems by choosing the right tool.
  - fnordsensei 8y ago
    Being selective about the language you work with is entirely valid. But why would you go to an interview where they're not looking for your language and try to convince them otherwise? It seems futile.
    - tsmarsh 8y ago
      I had a weird experience where I was offered an interview at a company I respected, but who used ruby a lot. I explained that to everyone in the chain that I'd want to try and work to change that, and eventually got rejected because I didn't like ruby. It was a weird experience. But I got a nice lunch out of it. I'm still not sure what they got out of it.
- CydeWeys 8y ago
  I've found that being mainstream is the most important factor in choosing tooling. Being mainstream has incredible advantages. It means you're going to find lots of help, resources, answers to questions, sample code, and high quality and well maintained libraries.
  - mmjaa 8y ago
    .. and of course, the old standard, if its mainstream .. you are replaceable.
    - fixermark 8y ago
      Totally agree, with the added observation that as a software engineer, I want to be replaceable. If my software can't be divorced from its creator, it can't outlive me. I don't want to be glued to my work inextricably; if you can't be replaced, you can't be promoted.
      - mirceal 8y ago
        being replaceable is a noble goal. the problem is that maybe some people don't want to be replaceable and maybe they want/seek to gain some kind of job security through the tooling they use, their idiosyncratic processes or just through rejection of new technology. those people are IMHO doomed to obsolescence.
    - nicheftw93 8y ago
      Anecdote time: making yourself too specialized makes you easily replaceable too. At a previous gig, a problem dev, who insisted on only using Erlang, was painted into a corner by eng at large who did not want to learn/support another language (Ruby, Python, JS, Java, and R were all over). This dev eventually got fired, as they didn't really contribute much to "the big picture". Since their efforts were so limited in scope, their Erlang work was quickly replaced using the other languages, and consumers of the results never noticed. YMMV. But that's a old standard that should probably die
  - cube2222 8y ago
- EpicEng 8y ago
  >Yes. Because mainstream is what you should select for when choosing your tools It's a hugely important consideration. More devs, larger community, better support, more/better tooling, more libs, etc. If you don't think those matter then you're only concerned with pet/toy projects.
  - fnordsensei 8y ago
    There's also a zero chance of working with anything that's better than mainstream.
    - EpicEng 8y ago
      Ummm... ok? I don't know about you, but I like building things that solve problems. Tools are important, but they're not a goal unto themselves. If your 'better' language is beautiful, but lacks the ecosystem people solving real problems actually need to get work done, it's not actually better.
      - fnordsensei 8y ago
        Language is too restrictive to consider in isolation if we're talking about "the tools". And I'm personally more interested in effectiveness than beauty, although I'll grant that beauty could have some influence on effectiveness perhaps. Ecosystem is not a binary proposition: either there, or not there. At some point the ecosystem becomes solid enough for some purposes. Finally, if no outliers were ever a better choice than the status quo, the status quo would never change. Therefore, there are always some outliers that can be chosen for greater effect at the cost of accepting some perceived risk. Using tooling smack in the middle of the average zeroes the potential increase in effectiveness as well as the perceived risk.
- xor1 8y ago
  >Yes. Because mainstream is what you should select for when choosing your tools. Ease of hiring experienced developers should absolutely be a part of selection criteria, but of course it should not be the only one. What good is it going to do you when you picked Elixir/Scala/Rust over Python/Go/Ruby, you need to hire senior engineers who can hit the ground running ASAP, and you have limited resources/budget? It's going to be harder to find them (especially if you're not in SF), it's a harder/longer initial learning curve if you hire senior engineers without prior experience, it's going to be harder to find non-seniors, you're going to have to pay more to get what you want...the list goes on.
  - mirceal 8y ago
    a senior developer, by definition, will hit the ground running with mostly anything you use. that's the senior part in senior developer. also if you believe that people need years of use to be good in any language/tools/framework you need to figure out how to attract better people. also, the question you need to ask yourself is: do you want to build something with a technology you've selected and think it's the best or do you want to have someone that can pick the right tool for the job pick the tech? sometimes, not building something or various parts of something is more valuable that building something that you don't need fast.
    - xor1 8y ago
      >a senior developer, by definition, will hit the ground running with mostly anything you use. that's the senior part in senior developer. a senior developer also gets to be picky in what stacks they want to work with. usually it's what they are familiar and comfortable with, or something similar to it >also if you believe that people need years of use to be good in any language/tools/framework you need to figure out how to attract better people. even the best engineers have ramp-up time when starting a new job that involves a new code base. that ramp-up time is increased significantly when it's a language that they aren't familiar with. feel free to convince me otherwise, im all ears >sometimes, not building something or various parts of something is more valuable that building something that you don't need fast. what about when it's not?
  - 8y ago

mirceal 8y ago

Yes. Because mainstream is what you should select for when choosing your tools. On a more serious note: I’m very wary of people that have discovered the one true language, framework, etc. That’s how you end up with 100 lines of go instead a one line bash script. That’s how you end up with “java developers” that are more concerned with design patterns instead of actual working code. I could go on. Learn about as many things possible, form your own opinions, choose the right tool for the job.

hmschreck 8y ago
We had a developer interview here who was an Elixir zealot - and I use that word entirely purposefully. He was very adamant that we needed to rewrite our entire platform in Elixir because it was obviously better. We ended up not hiring; he refused to touch certain technologies that make up a core part of our stack (Node being the biggest issue), and he was honestly something of a massive tool -- on our take-home thing (takes most developers maybe a few hours) he limited himself to one hour, didn't get it done, wasn't even solving the right problem, and, when he sent in his solution... "It's ok, I know you won't get it, but that's OK."
- EpicEng 8y ago
  Run, run far away... (I realize you did, but man...)
- mirceal 8y ago
  a zealot is a zealot is a zealot. you don't get much info from the strong preferences of a zealot. you just quickly learn that you need to avoid them. refusing to touch the tech stack of the person that pays your bills if flat out stupid. if you don't touch it why am I hiring you? depending on how much experience this person had this behavior may be correctable if he/she is lucky enough to find a more senior developer that can show them how their [stupid] choices impact the project and how they can eliminate whole classes of problems by choosing the right tool.
- fnordsensei 8y ago
  Being selective about the language you work with is entirely valid. But why would you go to an interview where they're not looking for your language and try to convince them otherwise? It seems futile.
  - tsmarsh 8y ago
    I had a weird experience where I was offered an interview at a company I respected, but who used ruby a lot. I explained that to everyone in the chain that I'd want to try and work to change that, and eventually got rejected because I didn't like ruby. It was a weird experience. But I got a nice lunch out of it. I'm still not sure what they got out of it.
CydeWeys 8y ago
I've found that being mainstream is the most important factor in choosing tooling. Being mainstream has incredible advantages. It means you're going to find lots of help, resources, answers to questions, sample code, and high quality and well maintained libraries.
- mmjaa 8y ago
  .. and of course, the old standard, if its mainstream .. you are replaceable.
  - fixermark 8y ago
    Totally agree, with the added observation that as a software engineer, I want to be replaceable. If my software can't be divorced from its creator, it can't outlive me. I don't want to be glued to my work inextricably; if you can't be replaced, you can't be promoted.
    - mirceal 8y ago
      being replaceable is a noble goal. the problem is that maybe some people don't want to be replaceable and maybe they want/seek to gain some kind of job security through the tooling they use, their idiosyncratic processes or just through rejection of new technology. those people are IMHO doomed to obsolescence.
  - nicheftw93 8y ago
    Anecdote time: making yourself too specialized makes you easily replaceable too. At a previous gig, a problem dev, who insisted on only using Erlang, was painted into a corner by eng at large who did not want to learn/support another language (Ruby, Python, JS, Java, and R were all over). This dev eventually got fired, as they didn't really contribute much to "the big picture". Since their efforts were so limited in scope, their Erlang work was quickly replaced using the other languages, and consumers of the results never noticed. YMMV. But that's a old standard that should probably die
- cube2222 8y ago
EpicEng 8y ago
>Yes. Because mainstream is what you should select for when choosing your tools It's a hugely important consideration. More devs, larger community, better support, more/better tooling, more libs, etc. If you don't think those matter then you're only concerned with pet/toy projects.
- fnordsensei 8y ago
  There's also a zero chance of working with anything that's better than mainstream.
  - EpicEng 8y ago
    Ummm... ok? I don't know about you, but I like building things that solve problems. Tools are important, but they're not a goal unto themselves. If your 'better' language is beautiful, but lacks the ecosystem people solving real problems actually need to get work done, it's not actually better.
    - fnordsensei 8y ago
      Language is too restrictive to consider in isolation if we're talking about "the tools". And I'm personally more interested in effectiveness than beauty, although I'll grant that beauty could have some influence on effectiveness perhaps. Ecosystem is not a binary proposition: either there, or not there. At some point the ecosystem becomes solid enough for some purposes. Finally, if no outliers were ever a better choice than the status quo, the status quo would never change. Therefore, there are always some outliers that can be chosen for greater effect at the cost of accepting some perceived risk. Using tooling smack in the middle of the average zeroes the potential increase in effectiveness as well as the perceived risk.
xor1 8y ago
>Yes. Because mainstream is what you should select for when choosing your tools. Ease of hiring experienced developers should absolutely be a part of selection criteria, but of course it should not be the only one. What good is it going to do you when you picked Elixir/Scala/Rust over Python/Go/Ruby, you need to hire senior engineers who can hit the ground running ASAP, and you have limited resources/budget? It's going to be harder to find them (especially if you're not in SF), it's a harder/longer initial learning curve if you hire senior engineers without prior experience, it's going to be harder to find non-seniors, you're going to have to pay more to get what you want...the list goes on.
- mirceal 8y ago
  a senior developer, by definition, will hit the ground running with mostly anything you use. that's the senior part in senior developer. also if you believe that people need years of use to be good in any language/tools/framework you need to figure out how to attract better people. also, the question you need to ask yourself is: do you want to build something with a technology you've selected and think it's the best or do you want to have someone that can pick the right tool for the job pick the tech? sometimes, not building something or various parts of something is more valuable that building something that you don't need fast.
  - xor1 8y ago
    >a senior developer, by definition, will hit the ground running with mostly anything you use. that's the senior part in senior developer. a senior developer also gets to be picky in what stacks they want to work with. usually it's what they are familiar and comfortable with, or something similar to it >also if you believe that people need years of use to be good in any language/tools/framework you need to figure out how to attract better people. even the best engineers have ramp-up time when starting a new job that involves a new code base. that ramp-up time is increased significantly when it's a language that they aren't familiar with. feel free to convince me otherwise, im all ears >sometimes, not building something or various parts of something is more valuable that building something that you don't need fast. what about when it's not?
- 8y ago