5 ms·

Erlang has been around since the 80s and OTP the early 90s. Elixir for a decade.

DandyDev 3y ago
And yet people are reinventing parts of OTP in other languages and through tooling and infrastructure (e.g. Kubernetes). What does that tell you?
- cpursley 3y ago
  It tells us that people aren’t aware of OTP.
  - DandyDev 3y ago
    Or that people find OTP/Erlang/Elixir hard to use. OTP has either a usability issue or a marketing issue
    - eyelidlessness 3y ago
      It doesn’t even necessarily say that. People may reasonably evaluate OTP/Erlang/Elixir[/other BEAM languages] and find them appealing, but elect to use another stack because it appeals more for reasons beyond OTP/etc’s appeal. I made that choice once, but I wouldn’t hesitate to consider OTP/etc again the next time I’m working on a problem they solve well.
      - DandyDev 3y ago
        Thanks for proving the whole point of this thread (No snark meant). People are indeed recreating parts of OTP in other languages because there are all kinds of reasons to pick a different language than Erlang/Elixer and still want some of the advantages of those languages
atombender 3y ago
As someone who adhores OTP in the abstract but uses mostly Go, I can tell you why I don't use it. Static typing: I've worked for years with dynamically typed languages and won't go back. Dynamic typing was a big mistake that have wasted years of developer time. Dialyzer isn't an option. Syntax: Erlang's syntax is not great. Enough said. I think Elixir isn't better, or at least doesn't offer enough of a value proposition over straight Erlang. Native compilation: Erlang works well for control systems. It's absolutely subpar for anything requiring compute performance or I/O. This means you may find yourself in a sticky position if your backend app has hotspots needing very low-latency, high-performant logic. You may have to write bits in C or some other natively compiled language. Friction: Erlang is hardly used anywhere. It is sufficiently weird (functional, Prolog syntax, immutable, the process model, antique tooling, not to mention OTP itself) that it's not just something most developers are going to pick up in a day. Forcing Erlang on a team not consisting of a monoculture of Erlang developers is a huge ask in any company. It's hard to hire for. You can't just reassign a random "full stack" developer within a company to a team that uses Erlang, if all they know is JavaScript/TypeScript or Go for that matter. I think fans of Erlang have to realize that no matter how much they post comments like yours, it's just not going to take off. Sometimes superior tech just doesn't pan out (Amiga, BeOS, QNX), but we move on. I am optimistic about Gleam, though. A much better language that I would actually want to use, and there's interop with Erlang/OTP, which is a great way to bootstrap a language.
- toast0 3y ago
  > Native compilation: Erlang works well for control systems. It's absolutely subpar for anything requiring compute performance or I/O. This means you may find yourself in a sticky position if your backend app has hotspots needing very low-latency, high-performant logic. You may have to write bits in C or some other natively compiled language. This is mostly accurate, but I think Erlang is a good fit for network I/O, especially network I/O with lots of concurrent clients. > Friction: Erlang is hardly used anywhere. It is sufficiently weird (functional, Prolog syntax, immutable, the process model, antique tooling, not to mention OTP itself) that it's not just something most developers are going to pick up in a day. At my Erlang job, almost nobody we hired had Erlang experience. It certainly took longer than a day, but IIRC, my first big Erlang server stuff deployed (and mostly worked) a month in, and I was focusing on a PHP service. I probably did some minor stuff earlier, but I no longer have changelogs to reference. Yeah, some of the OTP philosophy takes a while to understand. As for antique tooling, we just used Make, and that's what I continue to use for my Erlang projects, and well Make is Make... once you learn it, it works. Figuring out how to get dist running and pop debug shells when and where you need them is work, but if you're dropped into a place that already has that, you don't need to figure it out yourself, either.

And yet people are reinventing parts of OTP in other languages and through tooling and infrastructure (e.g. Kubernetes). What does that tell you?

cpursley 3y ago
It tells us that people aren’t aware of OTP.
- DandyDev 3y ago
  Or that people find OTP/Erlang/Elixir hard to use. OTP has either a usability issue or a marketing issue
  - eyelidlessness 3y ago
    It doesn’t even necessarily say that. People may reasonably evaluate OTP/Erlang/Elixir[/other BEAM languages] and find them appealing, but elect to use another stack because it appeals more for reasons beyond OTP/etc’s appeal. I made that choice once, but I wouldn’t hesitate to consider OTP/etc again the next time I’m working on a problem they solve well.
    - DandyDev 3y ago
      Thanks for proving the whole point of this thread (No snark meant). People are indeed recreating parts of OTP in other languages because there are all kinds of reasons to pick a different language than Erlang/Elixer and still want some of the advantages of those languages

atombender 3y ago

As someone who adhores OTP in the abstract but uses mostly Go, I can tell you why I don't use it. Static typing: I've worked for years with dynamically typed languages and won't go back. Dynamic typing was a big mistake that have wasted years of developer time. Dialyzer isn't an option. Syntax: Erlang's syntax is not great. Enough said. I think Elixir isn't better, or at least doesn't offer enough of a value proposition over straight Erlang. Native compilation: Erlang works well for control systems. It's absolutely subpar for anything requiring compute performance or I/O. This means you may find yourself in a sticky position if your backend app has hotspots needing very low-latency, high-performant logic. You may have to write bits in C or some other natively compiled language. Friction: Erlang is hardly used anywhere. It is sufficiently weird (functional, Prolog syntax, immutable, the process model, antique tooling, not to mention OTP itself) that it's not just something most developers are going to pick up in a day. Forcing Erlang on a team not consisting of a monoculture of Erlang developers is a huge ask in any company. It's hard to hire for. You can't just reassign a random "full stack" developer within a company to a team that uses Erlang, if all they know is JavaScript/TypeScript or Go for that matter. I think fans of Erlang have to realize that no matter how much they post comments like yours, it's just not going to take off. Sometimes superior tech just doesn't pan out (Amiga, BeOS, QNX), but we move on. I am optimistic about Gleam, though. A much better language that I would actually want to use, and there's interop with Erlang/OTP, which is a great way to bootstrap a language.

toast0 3y ago
> Native compilation: Erlang works well for control systems. It's absolutely subpar for anything requiring compute performance or I/O. This means you may find yourself in a sticky position if your backend app has hotspots needing very low-latency, high-performant logic. You may have to write bits in C or some other natively compiled language. This is mostly accurate, but I think Erlang is a good fit for network I/O, especially network I/O with lots of concurrent clients. > Friction: Erlang is hardly used anywhere. It is sufficiently weird (functional, Prolog syntax, immutable, the process model, antique tooling, not to mention OTP itself) that it's not just something most developers are going to pick up in a day. At my Erlang job, almost nobody we hired had Erlang experience. It certainly took longer than a day, but IIRC, my first big Erlang server stuff deployed (and mostly worked) a month in, and I was focusing on a PHP service. I probably did some minor stuff earlier, but I no longer have changelogs to reference. Yeah, some of the OTP philosophy takes a while to understand. As for antique tooling, we just used Make, and that's what I continue to use for my Erlang projects, and well Make is Make... once you learn it, it works. Figuring out how to get dist running and pop debug shells when and where you need them is work, but if you're dropped into a place that already has that, you don't need to figure it out yourself, either.