7 ms·

As an Erlang developer for the past couple years now, I love seeing the adoption and excitement around Elixir and the BEAM. I will admit I always shudder when p

As an Erlang developer for the past couple years now, I love seeing the adoption and excitement around Elixir and the BEAM. I will admit I always shudder when people very quickly call out on Erlang's syntax as a reason not to use it. Feels like a pretty lame excuse... All that said however, it kind of bugs me when I see posts like this (no matter the language) that go somewhere along the lines of "I managed to introduce language X and it was all rainbows and unicorns! Everybody loves it and work is fun again". Like, you had absolutely no problems with it? In my experience, people don't immediately grasp the actor model or how to manage processes (i.e. should I spawn a process for a short-lived task? should this monitor another process? should I link? should it need supervision?). Given that you're basically changing a methodology amongst your devs, it can be expected that things won't get written "right" the first time. I'm not referring to little idiosyncrasies like coding convention or best practices but literally misunderstanding of gen_servers and supervisors. Sure, perhaps transferring from Ruby to Scala to Elixir helped made the transfer less painful given their similarities but surely there were complications?

dudul 8y ago
Your first comment is kind of funny, because while Elixir's syntax may appear more "esthetic", I find Erlang's way more consistent and logical.
- OvermindDL1 8y ago
  Entirely agreed. Elixir's Macro's are awesome, and Erlang could definitely use an Elixir-Macro-Like Parse Transform library (could definitely exist), Erlang's syntax I find far more readable, consistent, and logical as well. Elixirs syntax has a lot needless, hard-to-read, noise, but it's not hard to overcome the noise to get the benefits of the overall ecosystem and macros.
  - pera 8y ago
    This topic is quite subjective, but could you provide some example? Overall Elixir seems to me a bit easier to read, for instance: Elixir: "Hello,How,Are,You,Today" |> String.split(",") |> Enum.join(".") |> IO.puts Erlang: -module(tok). -export([start/0]). start() -> Lst = string:tokens("Hello,How,Are,You,Today",","), io:fwrite("~s~n", [string:join(Lst,".")]), ok.
    - dxhdr 8y ago
      > This topic is quite subjective, but could you provide some example? Elixir's pin operator is a good example of unnecessary complexity.
      - dopamean 8y ago
        Why is it unnecessary?
        OvermindDL1 8y ago
        It's unnecessary in the 'erlang' ecosystem because erlang doesn't have variable rebinding, Elixir 'does' have variable rebinding so it needs some way to distinguish between rebinding and matching, and it was decided to use `^` to mark matching, when honestly I think it would have been smarter to specify it (or something similar) as rebinding. In quite a few cases rebinding leads to bugs (accidentally rebinding something that you still need an old value of).
        mmartinson 8y ago
        I think I would also prefer there to be no reminding. On the topic of the pin operator though, it seems more clear to me that it's an assertive component of a match, rather than needing to reference all variables in a scope in the case where there was no rebinding, to determine if something matching has already been assigned.
        dnautics 8y ago
        A buddy of mine and I were talking at length about this and we came to the consensus that the smartest choice would have been: no rebinding by default, if you want rebinding, make it available, say, using "var", or a sigil
        OvermindDL1 8y ago
        This is precisely how I think as well, some declaration like `let` or `var` or so to say "This is a new binding"
- mercer 8y ago
  I also found Elixir to sometimes be a bit too 'messy' in it syntax. A bunch of it made more sense when I understood why the choice had been made. The one that I still feel uncomfortable with, and where I haven't heard a proper justification, is how you can leave out [] for a keyword list when it's the last function parameter (I think they call it an options list?). It's already a bit confusing how a keyword list translates to a list of tuples, so adding that bit of sugar just further confuses things. It reminds me too much of Ruby's implicit block parameter (or whatever it's called), which I never was a fan of. Other than that Elixir might be my one of my favorite programming languages.
freedomben 8y ago
Having only written a couple small apps in Phoenix, none of which have needed to scale beyond a single instance yet, I think it's quite possible to build a Phoenix app without even knowing about the actor model or what OTP is. I read Dave Thomas's book first so I've built toy apps using Gen Servers, Supervisors, etc, but so far have needed none of that to write apps in Phoenix. (CRUD apps that make calls to 3rd party servers). That said, I wouldn't advocate jumping into Phoenix with zero Elixir knowledge. You'll have a tough time. And knowing about OTP/supervision is also recommended because you'll be much better off in the long term. I don't think you can avoid it forever.
seangrogg 8y ago
> As an Erlang developer for the past couple years now, I love seeing the adoption and excitement around Elixir and the BEAM. I will admit I always shudder when people very quickly call out on Erlang's syntax as a reason not to use it. Feels like a pretty lame excuse... I have mixed feelings here. From a purely implementation standpoint I totally agree - I don't particularly enjoy using certain tools at work but that is not a valid excuse for me to not get work done. At the same time, as a psych grad turned developer, I'm intimately aware of the effect that dreading a journey can have on attaining a goal and this is no less true of mapping developer experience to productivity - thus we should always be striving to make sure that the goals of the team are not undermined by the requirements to get there. If I had an objective that couldn't be solved in Elixir I would invest time in groking Erlang but its syntax does deter me from wanting to make that investment until I need to. > All that said however, it kind of bugs me when I see posts like this (no matter the language) that go somewhere along the lines of "I managed to introduce language X and it was all rainbows and unicorns! Everybody loves it and work is fun again". Totally agree, especially with your points on the gen_* family which are all vastly useful once you understand them but took me some time to bridge that gap. I feel that it's just as important to understand the pain points such that others reading this post and wanting to be the catalyst for similar change can prepare for these issues themselves should they ever want to take the leap.
- keithnoizu 8y ago
  I did erlang programming for about a year before switching to elixir for the last 3 years. I have a large server cluster serving 275k sensor devices averaging one report per minute containing 1 to 4 readings (temp, humidity, rainfall, wind speed, heading, etc.) calculating daily, weekly, monthly, yearly, hourly, and smaller high/low/average/tally aggregates and allowing users to setup complex alerts against these values. It would have take me a huge amount longer to write the same in erlang. The difference between readability and usability of Elixir and Erlang syntax is night and day, especially as someone coming from 20 years of working with imperative languages. I can feel comfortable handing out small tasks to a lay developer in elixir and getting back a response pretty quickly, it has a much easier on boarding. It has it's flaws of course. It's much easier to write programs that will crash in elixir, etc. but that concession with a more approachable syntax and methodology coupled with the benefits of OTP and Beam seems like a much more compelling sell than pure erlang.
rapind 8y ago
Instagrammification of tech blogs.
- rs86 8y ago
  Agree
bradgessler 8y ago
How interesting would it be to read the article about the company that looked at doing the big, dramatic rewrite, but didn’t, and was successful? This has happened at my company with a service called Firehose, which is basically PubSub over WS and HTTP written in Ruby Event Machine. It’s unstylish for a lot of technical reasons and an eng even tried to rewrite it in Elixir. We ended up scraping the rewrite project because the Ruby code just works and rarely gives us any problems in production. The problem with that story though is it won’t attract engineers who like new shiny stuff.
- methyl 8y ago
  > eng even tried to rewrite it in Elixir. We ended up scraping the rewrite project because the Ruby code just works and rarely gives us any problems in production. If your Ruby code just worked, why did you try to rewrite it in Elixir?

dudul 8y ago

Your first comment is kind of funny, because while Elixir's syntax may appear more "esthetic", I find Erlang's way more consistent and logical.

OvermindDL1 8y ago
Entirely agreed. Elixir's Macro's are awesome, and Erlang could definitely use an Elixir-Macro-Like Parse Transform library (could definitely exist), Erlang's syntax I find far more readable, consistent, and logical as well. Elixirs syntax has a lot needless, hard-to-read, noise, but it's not hard to overcome the noise to get the benefits of the overall ecosystem and macros.
- pera 8y ago
  This topic is quite subjective, but could you provide some example? Overall Elixir seems to me a bit easier to read, for instance: Elixir: "Hello,How,Are,You,Today" |> String.split(",") |> Enum.join(".") |> IO.puts Erlang: -module(tok). -export([start/0]). start() -> Lst = string:tokens("Hello,How,Are,You,Today",","), io:fwrite("~s~n", [string:join(Lst,".")]), ok.
  - dxhdr 8y ago
    > This topic is quite subjective, but could you provide some example? Elixir's pin operator is a good example of unnecessary complexity.
    - dopamean 8y ago
      Why is it unnecessary?
      - OvermindDL1 8y ago
        It's unnecessary in the 'erlang' ecosystem because erlang doesn't have variable rebinding, Elixir 'does' have variable rebinding so it needs some way to distinguish between rebinding and matching, and it was decided to use `^` to mark matching, when honestly I think it would have been smarter to specify it (or something similar) as rebinding. In quite a few cases rebinding leads to bugs (accidentally rebinding something that you still need an old value of).
        mmartinson 8y ago
        I think I would also prefer there to be no reminding. On the topic of the pin operator though, it seems more clear to me that it's an assertive component of a match, rather than needing to reference all variables in a scope in the case where there was no rebinding, to determine if something matching has already been assigned.
        dnautics 8y ago
        A buddy of mine and I were talking at length about this and we came to the consensus that the smartest choice would have been: no rebinding by default, if you want rebinding, make it available, say, using "var", or a sigil
        OvermindDL1 8y ago
        This is precisely how I think as well, some declaration like `let` or `var` or so to say "This is a new binding"
mercer 8y ago
I also found Elixir to sometimes be a bit too 'messy' in it syntax. A bunch of it made more sense when I understood why the choice had been made. The one that I still feel uncomfortable with, and where I haven't heard a proper justification, is how you can leave out [] for a keyword list when it's the last function parameter (I think they call it an options list?). It's already a bit confusing how a keyword list translates to a list of tuples, so adding that bit of sugar just further confuses things. It reminds me too much of Ruby's implicit block parameter (or whatever it's called), which I never was a fan of. Other than that Elixir might be my one of my favorite programming languages.

freedomben 8y ago

Having only written a couple small apps in Phoenix, none of which have needed to scale beyond a single instance yet, I think it's quite possible to build a Phoenix app without even knowing about the actor model or what OTP is. I read Dave Thomas's book first so I've built toy apps using Gen Servers, Supervisors, etc, but so far have needed none of that to write apps in Phoenix. (CRUD apps that make calls to 3rd party servers). That said, I wouldn't advocate jumping into Phoenix with zero Elixir knowledge. You'll have a tough time. And knowing about OTP/supervision is also recommended because you'll be much better off in the long term. I don't think you can avoid it forever.

seangrogg 8y ago

> As an Erlang developer for the past couple years now, I love seeing the adoption and excitement around Elixir and the BEAM. I will admit I always shudder when people very quickly call out on Erlang's syntax as a reason not to use it. Feels like a pretty lame excuse... I have mixed feelings here. From a purely implementation standpoint I totally agree - I don't particularly enjoy using certain tools at work but that is not a valid excuse for me to not get work done. At the same time, as a psych grad turned developer, I'm intimately aware of the effect that dreading a journey can have on attaining a goal and this is no less true of mapping developer experience to productivity - thus we should always be striving to make sure that the goals of the team are not undermined by the requirements to get there. If I had an objective that couldn't be solved in Elixir I would invest time in groking Erlang but its syntax does deter me from wanting to make that investment until I need to. > All that said however, it kind of bugs me when I see posts like this (no matter the language) that go somewhere along the lines of "I managed to introduce language X and it was all rainbows and unicorns! Everybody loves it and work is fun again". Totally agree, especially with your points on the gen_* family which are all vastly useful once you understand them but took me some time to bridge that gap. I feel that it's just as important to understand the pain points such that others reading this post and wanting to be the catalyst for similar change can prepare for these issues themselves should they ever want to take the leap.

keithnoizu 8y ago
I did erlang programming for about a year before switching to elixir for the last 3 years. I have a large server cluster serving 275k sensor devices averaging one report per minute containing 1 to 4 readings (temp, humidity, rainfall, wind speed, heading, etc.) calculating daily, weekly, monthly, yearly, hourly, and smaller high/low/average/tally aggregates and allowing users to setup complex alerts against these values. It would have take me a huge amount longer to write the same in erlang. The difference between readability and usability of Elixir and Erlang syntax is night and day, especially as someone coming from 20 years of working with imperative languages. I can feel comfortable handing out small tasks to a lay developer in elixir and getting back a response pretty quickly, it has a much easier on boarding. It has it's flaws of course. It's much easier to write programs that will crash in elixir, etc. but that concession with a more approachable syntax and methodology coupled with the benefits of OTP and Beam seems like a much more compelling sell than pure erlang.

rapind 8y ago

Instagrammification of tech blogs.

rs86 8y ago
Agree

bradgessler 8y ago

How interesting would it be to read the article about the company that looked at doing the big, dramatic rewrite, but didn’t, and was successful? This has happened at my company with a service called Firehose, which is basically PubSub over WS and HTTP written in Ruby Event Machine. It’s unstylish for a lot of technical reasons and an eng even tried to rewrite it in Elixir. We ended up scraping the rewrite project because the Ruby code just works and rarely gives us any problems in production. The problem with that story though is it won’t attract engineers who like new shiny stuff.

methyl 8y ago
> eng even tried to rewrite it in Elixir. We ended up scraping the rewrite project because the Ruby code just works and rarely gives us any problems in production. If your Ruby code just worked, why did you try to rewrite it in Elixir?