10 ms·

I run a growing agency and we run primarily on React + Django, but I really want to give Elixir a shot at some point. I find its concurrency features, purporte

I run a growing agency and we run primarily on React + Django, but I really want to give Elixir a shot at some point. I find its concurrency features, purported developer productivity, and it’s positioning as a “niche but popular” tech (these can be nice to acquire technical clients) very appealing. Does anyone have any experience running an Elixir consultancy / agency / software house? Or freelancing? How is the market and your general experience?

ipnon 5y ago
Anyone who knows Rails or Django can pick up Phoenix and anyone who likes Elixir is going to be the kind of person you want to hire.
- deleted 5y ago
  [deleted]
- cutler 5y ago
  Not so fast. Rubyists vary in the extent to which they fetishise OOP. Those that do are going to run a mile from Elixir once they peer beneath the surface/syntactic similarities. The Rubyists who revel in Ruby's procs, blocks and lambdas will find Elixir tantalising.
rubyn00bie 5y ago
I would probably recommend against this for most things if you're running an agency. Hiring experienced Elixir developers is not easy nor cheap; and for your clients, if they want to hire developers, at some point, are going to have a really difficult time.
- R0b0t1 5y ago
  Solution is to relax hiring requirements. The strength of the languages is what they do inherent to themselves due to their VM and standard library. You need people who know how to use them directing the effort, but once the design is there most people can pick it up.
  - rubyn00bie 5y ago
    > Solution is to relax hiring requirements. The strength of the languages is what they do inherent to themselves due to their VM and standard library. You need people who know how to use them directing the effort, but once the design is there most people can pick it up. Yeah, I gotta disagree... a lot of folks grossly underestimate the challenge of learning an _entirely_ new VM and language at the same time. Example, I can't count the number of silly things I've seen because someone obviously hasn't really grokked that BEAM will preempt processes. Or the amount of superfluous testing I see around gen servers when folks could directly call the function they intend to test...That is to say, I've watched a lot of folks try to write things coming from other VMs and languages and constantly miss the mark. What works for language or runtime X likely doesn't work that way on the BEAM and may not even translate.
    - sodapopcan 5y ago
      At the same token, I've seen programmers with 10+ years experience still royally mess up inheritance, brutally misuse design patterns, test private methods, shove view logic into every place they can think of that isn't an actual view, and so and and so forth. In my limited experience with BEAM, sure you can write shit code, but it's not like it's creating any bigger of a mess than anywhere else. The only advantage to not using BEAM is that you're creating a somewhat familiar mess.
      - exdsq 5y ago
        What's wrong with testing private methods?
      - joelbluminator 5y ago
        So when you hire a dev unfamiliar with your stack you risk having all that (bad engineering in genetral) plus all the possible mistakes they can do with the specific stack. Having good seniors on the team can mitigate this but honestly having people familar with your stack is a huge pro.
- innocentoldguy 5y ago
  This has not been my experience. I typically receive five to ten resumes from experienced Elixir programmers whenever we are hiring. There are a lot of Elixir shops in my area though.
- arcturus17 5y ago
  I wouldn’t ditch Django/Python and React - I still believe in them. This would be more of a tactical thing for projects where reqs are a good fit, and to slowly position ourselves as Elixir-competent, which may attract technical clients. I don’t think I’d have such a hard time hiring (we’re 100% remote) or training people gradually.
R0b0t1 5y ago
Erlang/Elixir were designed for telecommunication programs. If what you are doing is even vaguely like this Erlang/Elixir are going to be perhaps the best language you could pick. If you need to make a GUI or handle a CRUD app it may well be the worst language you could pick. Elixir is a lot more forgiving, but with Erlang you can tell it was made for telecom switches.
- OkayPhysicist 5y ago
  Have you used Phoenix? With it, Elixir is easily the best language to build CRUD app in. No other web framework even comes close.
- dnautics 5y ago
  > If you need to make a GUI or handle a CRUD app it may well be the worst language you could pick. I don't know how else to say this except that it's complete nonsense. I work for a place that deploys an elixir crud app and it's very nice despite tons of domain mistakes, annoying 3rd party APIs we connect to and bad architectural patterns that have accumulated over the course of several years of a brownfield project (I am a relatively recent hire). I can't imagine dealing with all that pain in another language
  - R0b0t1 5y ago
    Usually when I see a story like that it goes the other way. The friction of integrating ${nice_thing} with ${everything_else}. I'll take your word for it for now, but it seems like your honeymoon period with FP-heavy programming just coming into industry.
    - lostcolony 5y ago
      I've had over a decade of experience in this industry, ~2-3 with Erlang, ~3 with node, ~3 with Java, ~1 with Go, and a smattering of others (C#, Ruby), plus plenty of others outside of production deployments. Erlang was as easy as any of them for CRUD apps. I used Cowboy for it, which is comparable to Express (JS) or Gin (Go) in how it approaches things (i.e., simple request/response paradigm, with various helper functions to pull stuff out of the request data, or write into the response data, and easy to insert middleware as, again, just functions). Integrations outside of the app weren't especially painful; admittedly, we didn't have to integrate with an undocumented API whose only integration was via supplied library that was implemented only in Java or similar. Is your objection just "CRUD apps have to integrate with lots of downstreams, and so for that you want a language that has a huge plethora of libraries to make those integrations easy"? Because in that case "maybe". But that's orthogonal to being a CRUD app; that's simply because you have a bajillion dependencies that have existing libraries.
cultofmetatron 5y ago
I'm running an elixir startup pros: - web-socket story is the goat (and I used to write nodejs) - ecto database library is amazing - productivity is on par with django/rails - performance is comparable to go. sub 100ms response times are normal cons - not many drop in libraries. - hiring engineers is a pain but plenty are interested in learning - libraries are not as used so you're more likely to run into a big in edge libraries. - deployment is more complex if you want to use the mesh features So far, I'm happy with it. There are certain features specific to my startup that would elixir/otp made easy to create. We're getting traction and elixir's strengths are a huge part of that.
- ipnon 5y ago
  How hard is it for you to hire someone who knows how to program a web server, be it with Rails, Java, C#, or whatever, and have them be net productive with Elixir in a few weeks?
  - dnautics 5y ago
    It's easy if you have one senior in elixir to bootstrap off of. The right senior could probably bootstrap a junior fairly quickly too. If you don't have a senior, there's a good chance you'll miss your target if you "try to do it in a few weeks" since there's a lot of deprogramming your brain off of imperative pls that you have to do.
  - cultofmetatron 5y ago
    not hard. I learned enough to be productive after a few weeks of self study 4 years ago when there were way less resources for learning. we had a subcontractor helping me who didn't' know elixir. I was able to get him running within a few days. his lack of sql knowledge was more of a bottleneck than his elixir proficiency.
- jkhdigital 5y ago
  +1 Ecto is killer, not just the library itself but also how it provides a slick example of a DSL using Elixir macros. I used to love Elixir for the syntax and actor model, but macros have gotten me all hot and bothered.
news_to_me 5y ago
I've been working on Elixir projects freelance for over a year now, and it's become my preference for new projects. Elixir is one of my favorite languages because I feel like it really increases the leverage each developer has in a project.
lawik 5y ago
Yeah, freelancing mostly. Lots of developers wanting to work with it, so finding engaged devs has been easy for me when I've wanted reinforcement. Haven't had a gap in clients for a year and a half of straight Elixir work. Have more opportunities than I can feasibly execute on. Finding the right companies and connections is a bit of luck and a bit of networking of course. But most of the companies I've worked with are not well known in the community. There's plenty of usage in the wild.

ipnon 5y ago

Anyone who knows Rails or Django can pick up Phoenix and anyone who likes Elixir is going to be the kind of person you want to hire.

deleted 5y ago
[deleted]
cutler 5y ago
Not so fast. Rubyists vary in the extent to which they fetishise OOP. Those that do are going to run a mile from Elixir once they peer beneath the surface/syntactic similarities. The Rubyists who revel in Ruby's procs, blocks and lambdas will find Elixir tantalising.

rubyn00bie 5y ago

I would probably recommend against this for most things if you're running an agency. Hiring experienced Elixir developers is not easy nor cheap; and for your clients, if they want to hire developers, at some point, are going to have a really difficult time.

R0b0t1 5y ago
Solution is to relax hiring requirements. The strength of the languages is what they do inherent to themselves due to their VM and standard library. You need people who know how to use them directing the effort, but once the design is there most people can pick it up.
- rubyn00bie 5y ago
  > Solution is to relax hiring requirements. The strength of the languages is what they do inherent to themselves due to their VM and standard library. You need people who know how to use them directing the effort, but once the design is there most people can pick it up. Yeah, I gotta disagree... a lot of folks grossly underestimate the challenge of learning an _entirely_ new VM and language at the same time. Example, I can't count the number of silly things I've seen because someone obviously hasn't really grokked that BEAM will preempt processes. Or the amount of superfluous testing I see around gen servers when folks could directly call the function they intend to test...That is to say, I've watched a lot of folks try to write things coming from other VMs and languages and constantly miss the mark. What works for language or runtime X likely doesn't work that way on the BEAM and may not even translate.
  - sodapopcan 5y ago
    At the same token, I've seen programmers with 10+ years experience still royally mess up inheritance, brutally misuse design patterns, test private methods, shove view logic into every place they can think of that isn't an actual view, and so and and so forth. In my limited experience with BEAM, sure you can write shit code, but it's not like it's creating any bigger of a mess than anywhere else. The only advantage to not using BEAM is that you're creating a somewhat familiar mess.
    - exdsq 5y ago
      What's wrong with testing private methods?
    - joelbluminator 5y ago
      So when you hire a dev unfamiliar with your stack you risk having all that (bad engineering in genetral) plus all the possible mistakes they can do with the specific stack. Having good seniors on the team can mitigate this but honestly having people familar with your stack is a huge pro.
innocentoldguy 5y ago
This has not been my experience. I typically receive five to ten resumes from experienced Elixir programmers whenever we are hiring. There are a lot of Elixir shops in my area though.
arcturus17 5y ago
I wouldn’t ditch Django/Python and React - I still believe in them. This would be more of a tactical thing for projects where reqs are a good fit, and to slowly position ourselves as Elixir-competent, which may attract technical clients. I don’t think I’d have such a hard time hiring (we’re 100% remote) or training people gradually.

R0b0t1 5y ago

Erlang/Elixir were designed for telecommunication programs. If what you are doing is even vaguely like this Erlang/Elixir are going to be perhaps the best language you could pick. If you need to make a GUI or handle a CRUD app it may well be the worst language you could pick. Elixir is a lot more forgiving, but with Erlang you can tell it was made for telecom switches.

OkayPhysicist 5y ago
Have you used Phoenix? With it, Elixir is easily the best language to build CRUD app in. No other web framework even comes close.
dnautics 5y ago
> If you need to make a GUI or handle a CRUD app it may well be the worst language you could pick. I don't know how else to say this except that it's complete nonsense. I work for a place that deploys an elixir crud app and it's very nice despite tons of domain mistakes, annoying 3rd party APIs we connect to and bad architectural patterns that have accumulated over the course of several years of a brownfield project (I am a relatively recent hire). I can't imagine dealing with all that pain in another language
- R0b0t1 5y ago
  Usually when I see a story like that it goes the other way. The friction of integrating ${nice_thing} with ${everything_else}. I'll take your word for it for now, but it seems like your honeymoon period with FP-heavy programming just coming into industry.
  - lostcolony 5y ago
    I've had over a decade of experience in this industry, ~2-3 with Erlang, ~3 with node, ~3 with Java, ~1 with Go, and a smattering of others (C#, Ruby), plus plenty of others outside of production deployments. Erlang was as easy as any of them for CRUD apps. I used Cowboy for it, which is comparable to Express (JS) or Gin (Go) in how it approaches things (i.e., simple request/response paradigm, with various helper functions to pull stuff out of the request data, or write into the response data, and easy to insert middleware as, again, just functions). Integrations outside of the app weren't especially painful; admittedly, we didn't have to integrate with an undocumented API whose only integration was via supplied library that was implemented only in Java or similar. Is your objection just "CRUD apps have to integrate with lots of downstreams, and so for that you want a language that has a huge plethora of libraries to make those integrations easy"? Because in that case "maybe". But that's orthogonal to being a CRUD app; that's simply because you have a bajillion dependencies that have existing libraries.

cultofmetatron 5y ago

I'm running an elixir startup pros: - web-socket story is the goat (and I used to write nodejs) - ecto database library is amazing - productivity is on par with django/rails - performance is comparable to go. sub 100ms response times are normal cons - not many drop in libraries. - hiring engineers is a pain but plenty are interested in learning - libraries are not as used so you're more likely to run into a big in edge libraries. - deployment is more complex if you want to use the mesh features So far, I'm happy with it. There are certain features specific to my startup that would elixir/otp made easy to create. We're getting traction and elixir's strengths are a huge part of that.

ipnon 5y ago
How hard is it for you to hire someone who knows how to program a web server, be it with Rails, Java, C#, or whatever, and have them be net productive with Elixir in a few weeks?
- dnautics 5y ago
  It's easy if you have one senior in elixir to bootstrap off of. The right senior could probably bootstrap a junior fairly quickly too. If you don't have a senior, there's a good chance you'll miss your target if you "try to do it in a few weeks" since there's a lot of deprogramming your brain off of imperative pls that you have to do.
- cultofmetatron 5y ago
  not hard. I learned enough to be productive after a few weeks of self study 4 years ago when there were way less resources for learning. we had a subcontractor helping me who didn't' know elixir. I was able to get him running within a few days. his lack of sql knowledge was more of a bottleneck than his elixir proficiency.
jkhdigital 5y ago
+1 Ecto is killer, not just the library itself but also how it provides a slick example of a DSL using Elixir macros. I used to love Elixir for the syntax and actor model, but macros have gotten me all hot and bothered.

news_to_me 5y ago

I've been working on Elixir projects freelance for over a year now, and it's become my preference for new projects. Elixir is one of my favorite languages because I feel like it really increases the leverage each developer has in a project.

lawik 5y ago

Yeah, freelancing mostly. Lots of developers wanting to work with it, so finding engaged devs has been easy for me when I've wanted reinforcement. Haven't had a gap in clients for a year and a half of straight Elixir work. Have more opportunities than I can feasibly execute on. Finding the right companies and connections is a bit of luck and a bit of networking of course. But most of the companies I've worked with are not well known in the community. There's plenty of usage in the wild.