I’ve seen ex python or node.js developers say they are just as productive in Rust.
After a few years of Rust experience, it still pales in comparison to Erlang productivity for me.
After a few years of Rust experience, it still pales in comparison to Erlang productivity for me.
It's based on PureScript, which has a great reputation, but adds all the benefits of Erlang.
> very carefully constructed set of trade offs
But also the VM has changed since 1980 (for example there are maps now) and the programming ecosystem has changed (we know what drives productivity in terms of how to effectively test, document, deploy, good documentation > separate header files), we also know more about things like how lexical metaprogramming is maybe not the best idea for IDEs or language servers, it's really tough to say that Erlang got everything right for time immemorial. And on some things Erlang hasn't moved yet (thankfully it seems like there's movement in documentation).
Elixir aimed for 100% Erlang compatibility.
It also provides minuscule overhead for each process so that creating a supervising process for every item isn't really a cost.
When you start talking distribution across nodes and hot loading code, that's where static typing starts to really bite you back because you don't have any way to enforce it across nodes or during a hot loading transition.
I agree, the status quo is that static typing often gives you more of a headache than profit. But I think that it actually could be the other way around, we just need to start thinking backwards-compatibility-first static typing, and it looks like an exciting area to explore.
https://github.com/purerl/purerl
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?
Eg: https://bravenewmethod.com/2011/02/22/socket-binary-data-str...
I don't know if any other language can do it this trivially.
match msg {
pattern1 => action1,
pattern2 => action2,
_ => {} // silently ignore
}There is very little boilerplate and very little in the way of irrelevant details.
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.
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.
Far more Elixir developers I know have just given up on using Dialyzer altogether than the Erlang devs I know.
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.
Developers have perverse incentives, like endlessly refactoring the same codebase or architecting "scalable" and "abstract" solutions.