3 ms·

Erlang concepts of processes, list comprehensions, pattern matching and extremely simple file/socket interfaces just make problem solving a breeze. There is ve

by rapsey 6y ago

Erlang concepts of processes, list comprehensions, pattern matching and extremely simple file/socket interfaces just make problem solving a breeze. There is very little boilerplate and very little in the way of irrelevant details.

GordonS 6y ago
Not sure if you've used Elixir, but if so, how would you say it compares to Erlang? I've spent a single day with Elixir and really liked it (if it was statically typed, I would have stuck with it), but I've only ever seen Erlang code (and stack traces), and honestly, the syntax looks really intimidating.
- lostcolony 6y ago
  The syntax is alien (coming as it does from Prolog, which few people know), but it actually is as much a feature as an anti-feature. You end up not bringing your own understandings to the language (as illustrated by the one instance where it seems familiar - if statements do not behave the way you expect them to; it pattern matches and must match to true in one of its branches or it's a runtime error). It also doesn't have macros, so far less 'magic' in the libraries and things. Either way, the size of the language to grok is smaller than Elixir, so I'd argue in some ways it's easier, even if it's offputting. That said, Erlang has Dialyzer, which gives you 'optional' typing. Elixir can make use of it too, though I don't think it's quite as good (though I haven't used it in prod the same way). Basically, it'll walk through your code, infer types, and tell you anywhere the code can't work based on what it could infer. You can help it by adding type annotations as well. So for instance, you read from ETS; Dialyzer will infer it can be type "any". But, what's this, you append to it; it must be a list of some type then. So that place you're multiplying it by a number must be wrong, since you can't multiply a list by a number. But in reality what's coming out is a binary; both operations are wrong. Diyalyzer can't tell you that, but you can tell it that via type spec. Regardless, I'd probably create new projects in Elixir at this point; mix is such a good tool, and Elixir has some real niceties (looking at you, actual string type and pipe operator), to where it would probably be my default at this point.
  - dnautics 6y ago
    Elixir is arguably better with dialyzer than erlang, for various reasons, like the way that structs work.
    - mononcqc 6y ago
      In practice it is much worse because Elixir's structs boil down to maps with a special key, and the analysis in Dialyzer can get confused there because it works them with Erlang's map semantics rather than Elixir's. Far more Elixir developers I know have just given up on using Dialyzer altogether than the Erlang devs I know.
      - dnautics 6y ago
        Maybe I'm mistaken, but in my experience dialyzer has caught several typing errors I've made in structs, which I have gone on to successfully fix. As for why elixir devs give up on dialyzer, I suspect that sometimes the messages can be cryptic because they are formatted as erlang terms. This is basically now a nonissue due to elixir_ls.

by rapsey 6y ago

GordonS 6y ago

Not sure if you've used Elixir, but if so, how would you say it compares to Erlang? I've spent a single day with Elixir and really liked it (if it was statically typed, I would have stuck with it), but I've only ever seen Erlang code (and stack traces), and honestly, the syntax looks really intimidating.

lostcolony 6y ago
The syntax is alien (coming as it does from Prolog, which few people know), but it actually is as much a feature as an anti-feature. You end up not bringing your own understandings to the language (as illustrated by the one instance where it seems familiar - if statements do not behave the way you expect them to; it pattern matches and must match to true in one of its branches or it's a runtime error). It also doesn't have macros, so far less 'magic' in the libraries and things. Either way, the size of the language to grok is smaller than Elixir, so I'd argue in some ways it's easier, even if it's offputting. That said, Erlang has Dialyzer, which gives you 'optional' typing. Elixir can make use of it too, though I don't think it's quite as good (though I haven't used it in prod the same way). Basically, it'll walk through your code, infer types, and tell you anywhere the code can't work based on what it could infer. You can help it by adding type annotations as well. So for instance, you read from ETS; Dialyzer will infer it can be type "any". But, what's this, you append to it; it must be a list of some type then. So that place you're multiplying it by a number must be wrong, since you can't multiply a list by a number. But in reality what's coming out is a binary; both operations are wrong. Diyalyzer can't tell you that, but you can tell it that via type spec. Regardless, I'd probably create new projects in Elixir at this point; mix is such a good tool, and Elixir has some real niceties (looking at you, actual string type and pipe operator), to where it would probably be my default at this point.
- dnautics 6y ago
  Elixir is arguably better with dialyzer than erlang, for various reasons, like the way that structs work.
  - mononcqc 6y ago
    In practice it is much worse because Elixir's structs boil down to maps with a special key, and the analysis in Dialyzer can get confused there because it works them with Erlang's map semantics rather than Elixir's. Far more Elixir developers I know have just given up on using Dialyzer altogether than the Erlang devs I know.
    - dnautics 6y ago
      Maybe I'm mistaken, but in my experience dialyzer has caught several typing errors I've made in structs, which I have gone on to successfully fix. As for why elixir devs give up on dialyzer, I suspect that sometimes the messages can be cryptic because they are formatted as erlang terms. This is basically now a nonissue due to elixir_ls.