I've been on the fence in learning erlang. I use python mostly and the industry around me uses Java or maybe golang.
I have wanted to learn Rust and Erlang, but I've wanted to learn Erlang longer. I know there are different reasons to learn either, but what makes you feel erlang makes you more productive?
Yeah but what happens in rust if your match doesn't match the pattern? The compiler won't let you. In erlang, it throws an error, which you can let the runtime eat up. This can be a strategy for extremely lazy error handling.
I know about Erlang's let it fail philosophy but why would you want something to be caught at runtime when it could be caught at compile time? It doesn't seem to have any valid reasons.
Netsplits, for example. You don't want to keep track of every service that needs to be taken down with the dropped connection and notify them something bad has happened. Log, crash, cleanup the failure domain, restart, back off, reconnect later. Zero lines of code in erlang.
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.
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.
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.
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.
I have wanted to learn Rust and Erlang, but I've wanted to learn Erlang longer. I know there are different reasons to learn either, but what makes you feel erlang makes you more productive?