4 ms·

After many conversations on the topic with good to great Erlang programmers (I also have 7 years of experience under my belt) I come to the conclusion that they

by loxs 6y ago

After many conversations on the topic with good to great Erlang programmers (I also have 7 years of experience under my belt) I come to the conclusion that they just "don't get it". Probably there is a subset of extremely smart people who can write good and very reliable software in a dynamic language without going mad, but I am not among them. In the end I just left the language and now I am much happier with a mix of TypeScript, OCaml and Rust Also the reliability they are talking about is quite different from the reliability that most people (especially ones who have not worked on erlang-y systems) think of when they hear the word. The Erlang reliability is about finding bugs and patching them (often in production) and not about avoiding them in the first place. Also it's about avoiding total system failure because of some bug in a part in it. This is a nice to have thing in all systems, but Erlang makes it easier to implement. Of course, they also like to avoid bugs, but for that they use testing. And of course, we have to mention dialyzer which is something like TypeScript for Erlang but a lot less polished and with practically no tooling support. It is used in every significant Erlang project but the process is IMO quite sub-optimal and the price you pay (in suffering) is quite high.

coldcode 6y ago
I've never worked in Erlang, but I did use Objective-C for a long time, and switched to Swift almost 5 years ago. Strong types makes it massively easier to ship high quality applications, while I could do so in the C variant it took a lot more effort and testing. In Swift I can make the language make it almost impossible to create erroneous code. It's not that you can't make good code in any language, but the cost is often not worth it; anything that makes it easier and more reliable saves you time and effort in the long run.
- Multicomp 6y ago
  Your last paragraph is why I enjoy F# and rust as much as I do. If the computer can do more to help you make illegal States unrepresentable then why not let it? Hence I am waiting on Gleam before I invest in Erlangy stuff. In the meantime I will explore the actor model of concurrency with F# Mailboxes.
  - loxs 6y ago
    Yes, for me the big revelation was when I learned OCaml (coming from Erlang) it was such a massive relief, it felt like half of my brain got freed to think about things that matter. After that, once it clicked, most languages of this caliber feel "at home" and I can use them quite easily - F#, Rust, Swift, TypeScript.
lostcolony 6y ago
'Of course, they also like to avoid bugs, but for that they use testing.' This is kind of the key bit. To caveat this - I'd like better typing in Erlang, and when i last used it in production I added type annotations to everything and ran Dialyzer as part of the build. But this is personal preference, and I'm not convinced it was the best use of my time; just the most conservative way to approach things for a system I needed extremely high uptime on. You have to write tests anyway. Just because a statically typed system compiles doesn't mean your test load is reduced. While it eliminates certain classes of bugs, those same classes mostly get covered just by writing functional tests of sufficient coverage. Between that, and Erlang's supervision tree (so that if you DO get a type error at runtime, it would be in a path you haven't adequately tested, and so not your expected 'happy path', and as such, can reasonably be restarted), it strikes me as a reasonable position to take.
- loxs 6y ago
  Regarding dialyzer: Yes, it's sane to use it although it's a massive PITA, especially when you have to collaborate with people who do not write type annotations or use such libraries. Regarding testing - I think it depends on the type of application you are writing. If you need 99.99% uptime, probably you have to have almost full test coverage. But for the kind of software that I write (at least lately), I rely on "let's make illegal states unrepresentable" to a large degree, then write a small number of regression tests (or fix the types) when we find bugs... This has proven (at least to me) to be good enough, especially compared to my clients' previous experience, which is usually very poor: extremely buggy software in a dynamic language with almost no tests and docs. Perfect quality is usually not needed or at least not worth the price.

by loxs 6y ago

coldcode 6y ago

I've never worked in Erlang, but I did use Objective-C for a long time, and switched to Swift almost 5 years ago. Strong types makes it massively easier to ship high quality applications, while I could do so in the C variant it took a lot more effort and testing. In Swift I can make the language make it almost impossible to create erroneous code. It's not that you can't make good code in any language, but the cost is often not worth it; anything that makes it easier and more reliable saves you time and effort in the long run.

Multicomp 6y ago
Your last paragraph is why I enjoy F# and rust as much as I do. If the computer can do more to help you make illegal States unrepresentable then why not let it? Hence I am waiting on Gleam before I invest in Erlangy stuff. In the meantime I will explore the actor model of concurrency with F# Mailboxes.
- loxs 6y ago
  Yes, for me the big revelation was when I learned OCaml (coming from Erlang) it was such a massive relief, it felt like half of my brain got freed to think about things that matter. After that, once it clicked, most languages of this caliber feel "at home" and I can use them quite easily - F#, Rust, Swift, TypeScript.

lostcolony 6y ago

'Of course, they also like to avoid bugs, but for that they use testing.' This is kind of the key bit. To caveat this - I'd like better typing in Erlang, and when i last used it in production I added type annotations to everything and ran Dialyzer as part of the build. But this is personal preference, and I'm not convinced it was the best use of my time; just the most conservative way to approach things for a system I needed extremely high uptime on. You have to write tests anyway. Just because a statically typed system compiles doesn't mean your test load is reduced. While it eliminates certain classes of bugs, those same classes mostly get covered just by writing functional tests of sufficient coverage. Between that, and Erlang's supervision tree (so that if you DO get a type error at runtime, it would be in a path you haven't adequately tested, and so not your expected 'happy path', and as such, can reasonably be restarted), it strikes me as a reasonable position to take.

loxs 6y ago
Regarding dialyzer: Yes, it's sane to use it although it's a massive PITA, especially when you have to collaborate with people who do not write type annotations or use such libraries. Regarding testing - I think it depends on the type of application you are writing. If you need 99.99% uptime, probably you have to have almost full test coverage. But for the kind of software that I write (at least lately), I rely on "let's make illegal states unrepresentable" to a large degree, then write a small number of regression tests (or fix the types) when we find bugs... This has proven (at least to me) to be good enough, especially compared to my clients' previous experience, which is usually very poor: extremely buggy software in a dynamic language with almost no tests and docs. Perfect quality is usually not needed or at least not worth the price.