5 ms·

What language and programming style did you use prior to using Elixir the most? Have you been able to build systems of similar or even larger size as previous p

by dpflan 3y ago

What language and programming style did you use prior to using Elixir the most? Have you been able to build systems of similar or even larger size as previous projects in other languages, and what was that experience like (i.e. how did Elixir make things better)?

sph 3y ago
I've been doing this job for 20 years. I am fluent in C, Go, Rust, Python, as well as Elixir, and for my clients I have written concurrent systems running in production in all of these languages. I know how painful and complex the problem space is. My opinion is not that rare, so instead of listing my credentials, you can search and find many others that have found this platform to be a great fit, simply because it has been designed to solve this very problem since 1986 when everybody else was focusing on single core, isolated systems.
- SwiftyBug 3y ago
  Why specifically Elixir? Have you tried other languages that run on BEAM?
- dpflan 3y ago
  Sounds good, you make it sound like that Elixir is now your de-facto, even for non-distributed systems projects?
  - sph 3y ago
    Servers are 99% of the code I write, so yes I choose Elixir, though for very conservative clients and small projects I use Go. For everything else, which is not a lot, there's Rust, Scheme, Lisp and many other fun languages to explore. My focus these days is on my business rather than consulting, so I have a lot of freedom.
    - zelphirkalt 3y ago
      How do you manage to convince employers of such language choices? (Do you need to convince?) And what kind of jobs or positions are that? I would love to use my skills like that, instead of building CRUD in Python, not really being able to apply my skillset, but employers are not ready to make the smallest leap it seems.
      - cess11 3y ago
        I've convinced the CEO that Elixir/BEAM/OTP is a good choice for a fairly large, multi-application project. It wasn't very hard, factors like high availability, the same programming language and runtime in the entire system, extremely fast prototyping, battle tested in absurdly demanding settings, sounds very nice to a business strategist able to understand at least some of the implications. The drawbacks are basically in recruiting and a few other areas and quite manageable. Edit: There's a book for this particular purpose, convincing the suits, https://pragprog.com/titles/tvmelixir/adopting-elixir/ https://pragprog.com/titles/tvmelixir/adopting-elixir/ .
        zelphirkalt 3y ago
        Recruiting was exactly the one argument that I got to hear. That hiring people would be difficult and people demanding high wages and so on. I could not convince an employer to not weigh that heavily. At least that is the brought forward argument. There might also be an element of "don't know it myself, don't want it in my company".
        toast0 3y ago
        I worked at WhatsApp, one of the big Erlang users, almost none of our server team knew Erlang before joining, including me. Until we hired someone who actually used it before, I was the most knowledgeable pre-hire, because I remember seeing a post about it when Erlang open sourced it. Yes, we probably could have done some things better if we had a bit more Erlang experience on our team; at least while I was there, none of our applications were properly packaged as OTP applications, and maybe that could have been useful. But overall, we were smart, experienced server people who were willing to learn Erlang and we were handed a tool that fit our needs very well, so we all got Erlang books and figured it out. If you can recruit smart, experienced server people who are willing to learn a new language, you don't have a recruiting problem. I haven't personally worked with Elixir, but I feel like most of the unfamiliarity is going to come from the underlying BEAM and OTP, so same difference; Elixir just has different syntax and macros are more heavily used, IMHO both syntaxes are going to be unfamiliar to most.

by dpflan 3y ago

sph 3y ago

I've been doing this job for 20 years. I am fluent in C, Go, Rust, Python, as well as Elixir, and for my clients I have written concurrent systems running in production in all of these languages. I know how painful and complex the problem space is. My opinion is not that rare, so instead of listing my credentials, you can search and find many others that have found this platform to be a great fit, simply because it has been designed to solve this very problem since 1986 when everybody else was focusing on single core, isolated systems.

SwiftyBug 3y ago
Why specifically Elixir? Have you tried other languages that run on BEAM?
dpflan 3y ago
Sounds good, you make it sound like that Elixir is now your de-facto, even for non-distributed systems projects?
- sph 3y ago
  Servers are 99% of the code I write, so yes I choose Elixir, though for very conservative clients and small projects I use Go. For everything else, which is not a lot, there's Rust, Scheme, Lisp and many other fun languages to explore. My focus these days is on my business rather than consulting, so I have a lot of freedom.
  - zelphirkalt 3y ago
    How do you manage to convince employers of such language choices? (Do you need to convince?) And what kind of jobs or positions are that? I would love to use my skills like that, instead of building CRUD in Python, not really being able to apply my skillset, but employers are not ready to make the smallest leap it seems.
    - cess11 3y ago
      I've convinced the CEO that Elixir/BEAM/OTP is a good choice for a fairly large, multi-application project. It wasn't very hard, factors like high availability, the same programming language and runtime in the entire system, extremely fast prototyping, battle tested in absurdly demanding settings, sounds very nice to a business strategist able to understand at least some of the implications. The drawbacks are basically in recruiting and a few other areas and quite manageable. Edit: There's a book for this particular purpose, convincing the suits, https://pragprog.com/titles/tvmelixir/adopting-elixir/ https://pragprog.com/titles/tvmelixir/adopting-elixir/ .
      - zelphirkalt 3y ago
        Recruiting was exactly the one argument that I got to hear. That hiring people would be difficult and people demanding high wages and so on. I could not convince an employer to not weigh that heavily. At least that is the brought forward argument. There might also be an element of "don't know it myself, don't want it in my company".
        toast0 3y ago
        I worked at WhatsApp, one of the big Erlang users, almost none of our server team knew Erlang before joining, including me. Until we hired someone who actually used it before, I was the most knowledgeable pre-hire, because I remember seeing a post about it when Erlang open sourced it. Yes, we probably could have done some things better if we had a bit more Erlang experience on our team; at least while I was there, none of our applications were properly packaged as OTP applications, and maybe that could have been useful. But overall, we were smart, experienced server people who were willing to learn Erlang and we were handed a tool that fit our needs very well, so we all got Erlang books and figured it out. If you can recruit smart, experienced server people who are willing to learn a new language, you don't have a recruiting problem. I haven't personally worked with Elixir, but I feel like most of the unfamiliarity is going to come from the underlying BEAM and OTP, so same difference; Elixir just has different syntax and macros are more heavily used, IMHO both syntaxes are going to be unfamiliar to most.