5 ms·

Meanwhile te company I work for is moving away from it. We cannot find enough people with enough knowledge to be already productive in it. Not many want to lear

Meanwhile te company I work for is moving away from it. We cannot find enough people with enough knowledge to be already productive in it. Not many want to learn it because it is considered pretty niche, and the ones willing to learn will need many months or years to be productive and build with some level of quality, and once they learn they move away to bigger companies which pay more. We end up paying to people to learn to then "graduate" and we end up with a platform built by people that were learning. Some people here say the tooling is great. Compared to what? The editor plugins are terrible, slow, and blow away your CPU doing god knows what kind of indexing. Compilation is slow and takes a lot of time (in CI for example). Libraries for things you give for granted in other platforms (java, javascript, python, ruby) are non existent, implemented in erlang, unmantained, poorly documented, not popular enough, or a combination of these. People are using it for creating traditional CRUD apps, and it is totally overkill. Something you would do in a day with django or ruby on rails takes a lot of time. Ok, you have tons of concurrency and scaling and.....but... unless you are facebook or google or amazon you won't need this anyway. Probably all of these things will be solved in the future, but at this moment, using Elixir for real production code in product focused companies is just a terrible mistake in my opinion. Certainly the ideas, the technology, and the BEAM are awesome...and it is technically superior to everything I've seen out there. But from a business perspective, it makes no sense to use it unless you're building the next whatsapp or similar.

cpursley 6y ago
> once they learn they move away to bigger companies which pay more Maybe consider paying your people more or moving to a better company?
- likortera 6y ago
  > Maybe consider paying your people more Salaries are actually pretty good. Not facebook salaries, but good enough and certainly above average. The company can already get very proefficient, experienced developers in Ruby and JavaScript. > moving to a better company? I certainly could. But how does this solve the business problem I'm talking about? The reason I'm not moving to another place and instead helping transition back to normality is because I actually like the company, and my coworkers, and I like to focus on building our product and solve the real problems the company was created for. Elixir can be a great tech (the best) for certain kind of problems. In our case (and any other "CRUD" like web application like 80% of the internet) is an expensive, distracting toy.
  - conradfr 6y ago
    So, totally disinterested question, can you name those companies paying well for Elixir in Europe? :) Otherwise I agree with a good part of your post. For CRUD work I feel way more productive with PHP/Symfony than with Elixir/Phoenix, especially for outputting HTML. Part of it is the DX with the templating and type hinting but also the unbeatable amount of libraries and manpower behind the language and framework. Otherwise the plugin for Jetbrain's IDEs works OK for me (but again it can't beat the Symfony plugin with PHPStorm features).
desmondmonster 6y ago
It sounds like you're recruiting from a pool of junior developers and convincing them to use Elixir instead of attracting folks who are already interested in the language. Not only is that community sizable, but it's experienced- surveys of attendees at my conference (https://empex.co https://empex.co) consistently show that 50% have >5 years and 30% have >10 years in the industry. Elixirists really are senior developers and Elixir is usually their fourth or fifth language. If it's taking your hires years to get up to speed, then I would look at your hiring practices before blaming the community. As for libraries, I challenge anyone to name an unmet dependency in Elixir that is 1) trivial to implement and 2) not for some niche application. My company has built a scalable platform with 3 engineers. I don't even think about maintenance, I just think about delivering new features. So business wins are higher velocity + lower hosting costs + less downtime + senior team. You don't need to be WhatsApp to appreciate those benefits.
- likortera 6y ago
  The folks you're talking about are a lot more expensive (in Europe at least) than the equivalent folks for more traditional platforms. Again, and without centering ourselves in pure technical and our own careers and CVs. How does that help the business?. Regarding to libraries, there's not much to discuss. Just look at the number of available packages as right now: rubygems: 164,235 (source: https://rubygems.org/stats https://rubygems.org/stats) NPM: millions (source: https://en.wikipedia.org/wiki/Npm_(software) https://en.wikipedia.org/wiki/Npm_(software)) PyPI: 283,519 (source: https://pypi.org/ https://pypi.org/) HEX:: 12 252 I'm pretty sure I can find more than one package I'll miss. > My company has built a scalable platform with 3 engineers. I don't even think about maintenance, I just think about delivering new features. So business wins are higher velocity + lower hosting costs + less downtime + senior team. You don't need to be WhatsApp to appreciate those benefits. Hosting costs are a lot cheaper for us than developer's time. Downtime has never been an issue given "cloud" (docker based) infrastructure. The productivity part is something we're not seeing to be any better than with more traditional technology, and the reason we're moving away. I wonder if what your team of 3 people is building couldn't have been built with just one engineer and ruby on rails at the expense of paying for two more servers.
s3cur3 6y ago
I don't say this to dismiss your experience, but just to share a counterexample: I found Elixir extremely easy to learn (despite having no Ruby experience, nor any significant experience in any functional languages). I went through the (excellent) official tutorial in a couple days, skimmed parts of Saša Juric's book, and felt reasonably confident diving in to actually writing code. Within a couple weeks I felt like I "got" OTP and idiomatic Elixir. I do agree that, at least for somebody who uses Intellij IDEs exclusively, the lack of good first-party support sucks. I do most of my debugging via unit tests and "printf" because the Intellij Elixir plugin's interpreted mode is just too slow for the debugger to be useful to me.
- wmock 6y ago
  I have found Elixir as a whole to be amazing, but the debugging process to be painful. Maybe its because I'm used to using Chrome's developer tools (since I mostly debug JavaScript), but I really wish that debugging on Elixir could be simpler. Using printf's is just too painful and feels backwards.
  - strzibny 6y ago
    Debugging in IEx is actually quite nice (https://nts.strzibny.name/elixir-interactive-shell-iex/ https://nts.strzibny.name/elixir-interactive-shell-iex/), but I agree that GUI-wise there is nothing I want to use.
  - e_proxus 6y ago
    I would recommend you learn the dbg module that comes with Erlang. Its a great tracing debugger able to trace existing code in runtime without having to modify the source. There are also several wrappers on top of the Erlang tracing tools, like Recon for example.
    - wmock 6y ago
      I'll need to do more research and maybe see if there are videos online showing how other developers debug in Elixir with those libraries.
amattn 6y ago
Anecdotally, having managed elixir teams and talked to other managers of elixir teams: - The learning curve is real. but 2-6 months for us, not years. It's not particularly hard, just longer than a small language like go. - Having Ruby and/or functional programming experience shortens that learning curve. - Developer experience/satisfaction is very high. This helps retention - Some devs will just never "get/grok" Elixir. They may have 20 years of java experience or a new dev better suited to a FE role. This doesn't mean they are bad, just not a great fit. - The devs that do get it? They are quite productive. Feature velocity is high. I disagree that Elixir/Phoenix isn't a fit for CRUD apps. I'm seeing high feature velocity across small and large scale products. In particular, feature velocity per engineer is quite high. A smaller team in Elixir/Phoenix/LiveView can outpace a similar full stack team.
didibus 6y ago
Hey, thanks for providing your personal feedback. Could you provide a little bit more context around where it's coming from so I know how to interpret it? Are you someone who recently joined this company and is now having to learn Elixir? If so, are you finding it difficult? Has it been taking you months or years to learn it and still feel like you don't know it well enough? How long have you spent trying to learn? Or are you someone who knows Elixir very well and has worked at the company for a long time doing Elixir work and you're observing the struggle to find new junior hires that are willing to learn it and finding it hard to teach it to them? It be nice if you could tell us the number of years of experience you have with Beam and Elixir as well. Thanks
jswny 6y ago
> and the ones willing to learn will need many months or years to be productive That’s interesting. I’ve been doing Elixir for a while and found it almost overwhelmingly simple. As in, I’d do something in a very simple way which would usually take me a lot longer and have to think whether it was actually right because I’m not used to that. I recently learned Go and I think it was only slightly more difficult to learn than elixir. I could see having trouble if you have never done functional before, but that’s kind of a separate issue. The language itself is tiny. OTP is one thing that can take a bit of getting used to. But again, I think that’s only for people who are only used to traditional threading methods of concurrency, which is again a separate issue. OTP and the actor model themselves are dead simple in terms of how to use them. > The editor plugins are terrible, slow, and blow away your CPU doing god knows what kind of indexing Without even looking I already know what this is. You are using ElixirLS and you are hitting the Dialyzer PLT generation which is needed for type assistance. Elixir LS gives you a pop-up (at least in VSCode) telling you that it's building the PLT and it might take a while. You can disable this if you really want. Most importantly it ONLY RUNS ONE TIME. So, if you've already generated the PLT for a project, it will NEVER run again until you upgrade Elixir or something major. Other than that, I rarely ever see Elixir LS taking up any noticeable CPU. > Compilation is slow and takes a lot of time Yes it does. However, you can just cache the _build/ directory in CI. Then it will act like it does locally, only recompiling what has changed and doing it very quickly. Usually, dependencies will not need to be recompiled if they haven't changed. Also, testing in Elixir is crazy fast and everything runs nicely async by default, even database tests with Ecto.
deleted 6y ago
[deleted]
mwcampbell 6y ago
Just curious, what is your company moving to, and are you far enough into the transition to verify that productivity and retention are better with the new language?
dimgl 6y ago
Thanks for sharing your experience. I love Elixir, but I have yet to find a way to be truly productive with it. Funnily enough I had a very similar experience with Go. * It was very hard for our startup to find any Go developers. * The Go language server would very often cause massive CPU spikes. * At the time I was using it, the community support in Go was really, really bad. I'm sure things have changed a bit, but there are always growing pains when choosing a niche technology.
blackrock 6y ago
What are you paying your engineers?
ellyagg 6y ago
Probably true for you and your team. Definitely not true if you fully grok all the advantages of the BEAM. Elixir is much faster to prototype modern web apps than alternatives and then also naturally seques into scaling if the need happens to arise.

cpursley 6y ago

> once they learn they move away to bigger companies which pay more Maybe consider paying your people more or moving to a better company?

likortera 6y ago
> Maybe consider paying your people more Salaries are actually pretty good. Not facebook salaries, but good enough and certainly above average. The company can already get very proefficient, experienced developers in Ruby and JavaScript. > moving to a better company? I certainly could. But how does this solve the business problem I'm talking about? The reason I'm not moving to another place and instead helping transition back to normality is because I actually like the company, and my coworkers, and I like to focus on building our product and solve the real problems the company was created for. Elixir can be a great tech (the best) for certain kind of problems. In our case (and any other "CRUD" like web application like 80% of the internet) is an expensive, distracting toy.
- conradfr 6y ago
  So, totally disinterested question, can you name those companies paying well for Elixir in Europe? :) Otherwise I agree with a good part of your post. For CRUD work I feel way more productive with PHP/Symfony than with Elixir/Phoenix, especially for outputting HTML. Part of it is the DX with the templating and type hinting but also the unbeatable amount of libraries and manpower behind the language and framework. Otherwise the plugin for Jetbrain's IDEs works OK for me (but again it can't beat the Symfony plugin with PHPStorm features).

desmondmonster 6y ago

It sounds like you're recruiting from a pool of junior developers and convincing them to use Elixir instead of attracting folks who are already interested in the language. Not only is that community sizable, but it's experienced- surveys of attendees at my conference (https://empex.co https://empex.co) consistently show that 50% have >5 years and 30% have >10 years in the industry. Elixirists really are senior developers and Elixir is usually their fourth or fifth language. If it's taking your hires years to get up to speed, then I would look at your hiring practices before blaming the community. As for libraries, I challenge anyone to name an unmet dependency in Elixir that is 1) trivial to implement and 2) not for some niche application. My company has built a scalable platform with 3 engineers. I don't even think about maintenance, I just think about delivering new features. So business wins are higher velocity + lower hosting costs + less downtime + senior team. You don't need to be WhatsApp to appreciate those benefits.

likortera 6y ago
The folks you're talking about are a lot more expensive (in Europe at least) than the equivalent folks for more traditional platforms. Again, and without centering ourselves in pure technical and our own careers and CVs. How does that help the business?. Regarding to libraries, there's not much to discuss. Just look at the number of available packages as right now: rubygems: 164,235 (source: https://rubygems.org/stats https://rubygems.org/stats) NPM: millions (source: https://en.wikipedia.org/wiki/Npm_(software) https://en.wikipedia.org/wiki/Npm_(software)) PyPI: 283,519 (source: https://pypi.org/ https://pypi.org/) HEX:: 12 252 I'm pretty sure I can find more than one package I'll miss. > My company has built a scalable platform with 3 engineers. I don't even think about maintenance, I just think about delivering new features. So business wins are higher velocity + lower hosting costs + less downtime + senior team. You don't need to be WhatsApp to appreciate those benefits. Hosting costs are a lot cheaper for us than developer's time. Downtime has never been an issue given "cloud" (docker based) infrastructure. The productivity part is something we're not seeing to be any better than with more traditional technology, and the reason we're moving away. I wonder if what your team of 3 people is building couldn't have been built with just one engineer and ruby on rails at the expense of paying for two more servers.

s3cur3 6y ago

I don't say this to dismiss your experience, but just to share a counterexample: I found Elixir extremely easy to learn (despite having no Ruby experience, nor any significant experience in any functional languages). I went through the (excellent) official tutorial in a couple days, skimmed parts of Saša Juric's book, and felt reasonably confident diving in to actually writing code. Within a couple weeks I felt like I "got" OTP and idiomatic Elixir. I do agree that, at least for somebody who uses Intellij IDEs exclusively, the lack of good first-party support sucks. I do most of my debugging via unit tests and "printf" because the Intellij Elixir plugin's interpreted mode is just too slow for the debugger to be useful to me.

wmock 6y ago
I have found Elixir as a whole to be amazing, but the debugging process to be painful. Maybe its because I'm used to using Chrome's developer tools (since I mostly debug JavaScript), but I really wish that debugging on Elixir could be simpler. Using printf's is just too painful and feels backwards.
- strzibny 6y ago
  Debugging in IEx is actually quite nice (https://nts.strzibny.name/elixir-interactive-shell-iex/ https://nts.strzibny.name/elixir-interactive-shell-iex/), but I agree that GUI-wise there is nothing I want to use.
- e_proxus 6y ago
  I would recommend you learn the dbg module that comes with Erlang. Its a great tracing debugger able to trace existing code in runtime without having to modify the source. There are also several wrappers on top of the Erlang tracing tools, like Recon for example.
  - wmock 6y ago
    I'll need to do more research and maybe see if there are videos online showing how other developers debug in Elixir with those libraries.

amattn 6y ago

Anecdotally, having managed elixir teams and talked to other managers of elixir teams: - The learning curve is real. but 2-6 months for us, not years. It's not particularly hard, just longer than a small language like go. - Having Ruby and/or functional programming experience shortens that learning curve. - Developer experience/satisfaction is very high. This helps retention - Some devs will just never "get/grok" Elixir. They may have 20 years of java experience or a new dev better suited to a FE role. This doesn't mean they are bad, just not a great fit. - The devs that do get it? They are quite productive. Feature velocity is high. I disagree that Elixir/Phoenix isn't a fit for CRUD apps. I'm seeing high feature velocity across small and large scale products. In particular, feature velocity per engineer is quite high. A smaller team in Elixir/Phoenix/LiveView can outpace a similar full stack team.

didibus 6y ago

Hey, thanks for providing your personal feedback. Could you provide a little bit more context around where it's coming from so I know how to interpret it? Are you someone who recently joined this company and is now having to learn Elixir? If so, are you finding it difficult? Has it been taking you months or years to learn it and still feel like you don't know it well enough? How long have you spent trying to learn? Or are you someone who knows Elixir very well and has worked at the company for a long time doing Elixir work and you're observing the struggle to find new junior hires that are willing to learn it and finding it hard to teach it to them? It be nice if you could tell us the number of years of experience you have with Beam and Elixir as well. Thanks

jswny 6y ago

> and the ones willing to learn will need many months or years to be productive That’s interesting. I’ve been doing Elixir for a while and found it almost overwhelmingly simple. As in, I’d do something in a very simple way which would usually take me a lot longer and have to think whether it was actually right because I’m not used to that. I recently learned Go and I think it was only slightly more difficult to learn than elixir. I could see having trouble if you have never done functional before, but that’s kind of a separate issue. The language itself is tiny. OTP is one thing that can take a bit of getting used to. But again, I think that’s only for people who are only used to traditional threading methods of concurrency, which is again a separate issue. OTP and the actor model themselves are dead simple in terms of how to use them. > The editor plugins are terrible, slow, and blow away your CPU doing god knows what kind of indexing Without even looking I already know what this is. You are using ElixirLS and you are hitting the Dialyzer PLT generation which is needed for type assistance. Elixir LS gives you a pop-up (at least in VSCode) telling you that it's building the PLT and it might take a while. You can disable this if you really want. Most importantly it ONLY RUNS ONE TIME. So, if you've already generated the PLT for a project, it will NEVER run again until you upgrade Elixir or something major. Other than that, I rarely ever see Elixir LS taking up any noticeable CPU. > Compilation is slow and takes a lot of time Yes it does. However, you can just cache the _build/ directory in CI. Then it will act like it does locally, only recompiling what has changed and doing it very quickly. Usually, dependencies will not need to be recompiled if they haven't changed. Also, testing in Elixir is crazy fast and everything runs nicely async by default, even database tests with Ecto.

deleted 6y ago

[deleted]

mwcampbell 6y ago

Just curious, what is your company moving to, and are you far enough into the transition to verify that productivity and retention are better with the new language?

dimgl 6y ago

Thanks for sharing your experience. I love Elixir, but I have yet to find a way to be truly productive with it. Funnily enough I had a very similar experience with Go. * It was very hard for our startup to find any Go developers. * The Go language server would very often cause massive CPU spikes. * At the time I was using it, the community support in Go was really, really bad. I'm sure things have changed a bit, but there are always growing pains when choosing a niche technology.

blackrock 6y ago

What are you paying your engineers?

ellyagg 6y ago

Probably true for you and your team. Definitely not true if you fully grok all the advantages of the BEAM. Elixir is much faster to prototype modern web apps than alternatives and then also naturally seques into scaling if the need happens to arise.