7 ms·

I tried to do a startup in Erlang a few years ago. Haven't been able to watch the video because there aren't subtitles or a transcript, but here is why I don't

I tried to do a startup in Erlang a few years ago. Haven't been able to watch the video because there aren't subtitles or a transcript, but here is why I don't use Erlang anymore: the type system. Erlang/OTP does MANY things correctly, where "correctly" is taken to be "in line with my tastes", and yes this includes the inane issue of syntax. But the type system? Normally that wouldn't bother me, but I'm coming from OCaml, where exhaustive checking of algebraic data types makes me invincible. With dynamic typing, my code feels extremely vulnerable, especially when refactoring a codebase. Of course, Erlang isn't alone in this (I abandoned Ruby for similar reasons), but the pain of refactoring feels more acute in Erlang -- perhaps because idiomatic Erlang uses many short functions, making it easy to miss usages. So you have to rely on run-time testing to ensure complete coverage -- and that is nowhere near as easy nor reliable as a compiler that automatically checks everything for you. My dream language is one with ML semantics running on top of BEAM. That seems like a natural progression for a platform that was designed to be reliable -- while there have been attempts to graft a more versatile type system onto the Erlang base language, the cleanest way forward seems to be a language purpose-built for the task.

felixgallo 12y ago
Out of curiosity, did you try using dialyzer? I understand ADTs are strictly better, but was there a particular problem that dialyzer couldn't pragmatically solve for you?
- jallmann 12y ago
  Yes, while Dialyzer was somewhat useful, it only seemed to catch a subset of possible errors. The set of errors it missed was large enough that I just gave up on Erlang altogether. I never took the time to figure out what Dialyzer could and couldn't catch. This was a few years ago, so I don't really have any particular examples in mind anymore, but IIRC it may have had to do with being mostly unable to validate the structure of tuples as parameters to functions.
  - oinksoft 12y ago
    > validate the structure of tuples as parameters to > functions. Dialyzer can definitely do that, you just need to specify a type that is a tuple: -type something() :: {Thing :: thingtype(), Thing2 :: thing2type()}. %% ... -spec foo(something()) -> thingtype(). But I agree that Dialyzer can feel incomplete. It's been a little while now but I recall having to use `term()' in specs (basically, untyped) to suppress false positives in some cases. It was also quite slow. Still, a much better situation than Ruby.
    - phamilton 12y ago
      Also worth noting that erlc catches typos, again unlike Ruby.
deleted 12y ago
[deleted]
foobarian 12y ago
I have similar issues with Ruby. We have a large codebase spanning many years and stuff like typos in variable names make it past tests into production. Compile time checking basically replaces a large chunk of unit tests one would have to write and maintain to cover the same issues.
- themartorana 12y ago
  In an absolutely brilliant video[0] on Microsoft's Channel 9, called "Panel: Systems Programming in 2014 and Beyond" (with Charles Torre, Niko Matsakis, Andrei Alexandrescu, Rob Pike, and Bjarne Stroustrup), Rob Pike makes a comment (I'm paraphrasing) that in making Go, he realized that testing in general and the idea of TDD was due to dynamic languages not having any compile-time checking. The panel seemed to agree. If you have the time, you really should watch. It's fun to see all these guys on the same panel. [0] http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Panel-Systems-Programming-Languages-in-2014-and-Beyond http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pan...
  - angersock 12y ago
    Absolutely brilliant video. One of the best parts was when Pike brings up Erlang, and everyone just kind of mutters and looks down. I also like the part where Pike was like "Yeah, we statically verified the Plan 9 kernel somewhere, but nobody cared. :(" The important thing to note, though, was the thing they all agreed on: type systems don't magically replace tests, and don't magically save you from things when you're developing real software. Given a mutually exclusive choice, I'll take a strong test suite over a strong type system any day--because one of those lets me vastly screw with the implementation details and still make sure I'm meeting my business requirements.
    - themartorana 12y ago
      I agree. Thank goodness they're not mutually exclusive! I happen to be a Go fan, and thankful testing is well supported in the language and tooling. After having worked heavily in both compiled and dynamic software environments, I do like having compile-time checks on stupid things like typos. All my love to Python, which we use heavily, but my, what some compilation-like tooling would save me. (Nim has really caught my eye recently.) Although after having been spoiled with the static analyzer in Objective-C, probably a contender for my all time favorite language (take from that what you will) I do miss it in Go.
devbug 12y ago
This was the bane of our (backend developers) existence at an Elixir startup. Even if you maintained typespecs--good luck!--and signatures it was still a nightmare.
- angersock 12y ago
  An Elixir startup? Which one was this?
  - devbug 12y ago
    Bex (http://www.bex.io/ http://www.bex.io/).
    - angersock 12y ago
      So, how did you guys end up jumping on the Elixir train? New shiny, or practical reasons? :)
      - bvanslyke 12y ago
        Hm seeing as it's a bitcoin startup with an .io domain.....
colanderman 12y ago
Meh. Dialyzer mostly remedies Erlang's dynamic typing for me (also a big OCaml fan). Almost a little freeing. What kills me is that Erlang's design makes it practically impossible to statically check messaging. ! must be /dev/null as far as Dialyzer is concerned. (Not that solving this is an easy problem! But in an environment as dependent on messaging as OTP, it's a painful shortcoming.)
- davidw 12y ago
  > ! must be /dev/null as far as Dialyzer is concerned. In day to day use with OTP, you don't use ! much, directly - you're much more likely to do a gen_server:call/cast from within a function that you can easily spec out.
mercurial 12y ago
> My dream language is one with ML semantics running on top of BEAM. That seems like a natural progression for a platform that was designed to be reliable -- while there have been attempts to graft a more versatile type system onto the Erlang base language, the cleanest way forward seems to be a language purpose-built for the task. On the other hand, OCaml is pretty fast in most cases. BEAM doesn't have the same reputation. I think I'd rather have a better parallel and distributed computing story (complete with monitoring capabilities) for the existing OCaml ecosystem. The soft realtime guarantees that Erlang offers are IMHO too much of a price to pay.
- zem 12y ago
  AliceML is worth a look, though development seems to have died out a few years ago :( http://www.ps.uni-saarland.de/alice/ http://www.ps.uni-saarland.de/alice/
  - doublec 12y ago
    I've been helping keep the bitrot away at https://github.com/aliceml/aliceml https://github.com/aliceml/aliceml if you're interested in using it.
  - mercurial 12y ago
    This looks interesting. Once I find OCaml too mainstream, I'll have to look at it :)
saosebastiao 12y ago
I'm in the same boat as far as dream languages go. But just out of curiosity, what is it about F# or Scala that you don't like? For me Scala is an amazing language that sacrificed what could have been a clean design for the sake of Java interop, while inheriting a bunch of the baggage of the Java ecosystem (no closures until recently, type erasure, needless boxing, etc). And F# is still a windows-first ecosystem, as much as they would like to tell you otherwise. I'm currently using both, and while I like both of them well enough, I can't ever shake the feeling like I'm missing out on something better.
- jallmann 12y ago
  > what is it about F# or Scala that you don't like Haven't used either, so giving an opinion on those wouldn't be fair.
- mercurial 12y ago
  > I'm currently using both, and while I like both of them well enough, I can't ever shake the feeling like I'm missing out on something better. You'd probably like OCaml, considering how F# is basically "OCaml for .NET". And it definitely cannot be accused of having a "Windows-first" ecosystem.
jeffdavis 12y ago
"while there have been attempts to graft a more versatile type system onto the Erlang base language, the cleanest way forward seems to be a language purpose-built for the task." Are you sure that's even possible? Erlang is fundamentally a dynamic system, with hot code (re)loading, processes starting and stopping (possibly crashing), and nodes attaching and detaching. Moreover, the idea that a message can be sent to any PID seems fundamentally at odds with type checking at compile time. You'd probably need to do something more like channels. Perhaps an ML-like type system can work with all of that, but it sounds like a research problem.
- NotableAlamode 12y ago
  Typing a the message-passing part of a language like Erlang is very much an open research problem. I spoke about this at length with the session type community. They are thinking about this, but it's at least a decade away.
  - platz 12y ago
    Isn't Akka planning to add types w/ typed akka? If they can pull that off some subset of Erlang should be doable as well
    - saryant 12y ago
      That's their plan for Akka 3.0. I believe this is the current status: https://github.com/akka/akka/pull/16665 https://github.com/akka/akka/pull/16665
    - mafribe 12y ago
      From a superficial reading I think what they are doing is quite simplistic. Basically they want to provide typed channels, e.g. ActorRef[T] that only accepts T messages. That's the easy part. What you really want is something like type-based guarantees that a the interaction between actors cannot get stuck. Achieving this is fraught with difficulties.
      - 12y ago

felixgallo 12y ago

Out of curiosity, did you try using dialyzer? I understand ADTs are strictly better, but was there a particular problem that dialyzer couldn't pragmatically solve for you?

jallmann 12y ago
Yes, while Dialyzer was somewhat useful, it only seemed to catch a subset of possible errors. The set of errors it missed was large enough that I just gave up on Erlang altogether. I never took the time to figure out what Dialyzer could and couldn't catch. This was a few years ago, so I don't really have any particular examples in mind anymore, but IIRC it may have had to do with being mostly unable to validate the structure of tuples as parameters to functions.
- oinksoft 12y ago
  > validate the structure of tuples as parameters to > functions. Dialyzer can definitely do that, you just need to specify a type that is a tuple: -type something() :: {Thing :: thingtype(), Thing2 :: thing2type()}. %% ... -spec foo(something()) -> thingtype(). But I agree that Dialyzer can feel incomplete. It's been a little while now but I recall having to use `term()' in specs (basically, untyped) to suppress false positives in some cases. It was also quite slow. Still, a much better situation than Ruby.
  - phamilton 12y ago
    Also worth noting that erlc catches typos, again unlike Ruby.

deleted 12y ago

[deleted]

foobarian 12y ago

I have similar issues with Ruby. We have a large codebase spanning many years and stuff like typos in variable names make it past tests into production. Compile time checking basically replaces a large chunk of unit tests one would have to write and maintain to cover the same issues.

themartorana 12y ago
In an absolutely brilliant video[0] on Microsoft's Channel 9, called "Panel: Systems Programming in 2014 and Beyond" (with Charles Torre, Niko Matsakis, Andrei Alexandrescu, Rob Pike, and Bjarne Stroustrup), Rob Pike makes a comment (I'm paraphrasing) that in making Go, he realized that testing in general and the idea of TDD was due to dynamic languages not having any compile-time checking. The panel seemed to agree. If you have the time, you really should watch. It's fun to see all these guys on the same panel. [0] http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Panel-Systems-Programming-Languages-in-2014-and-Beyond http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pan...
- angersock 12y ago
  Absolutely brilliant video. One of the best parts was when Pike brings up Erlang, and everyone just kind of mutters and looks down. I also like the part where Pike was like "Yeah, we statically verified the Plan 9 kernel somewhere, but nobody cared. :(" The important thing to note, though, was the thing they all agreed on: type systems don't magically replace tests, and don't magically save you from things when you're developing real software. Given a mutually exclusive choice, I'll take a strong test suite over a strong type system any day--because one of those lets me vastly screw with the implementation details and still make sure I'm meeting my business requirements.
  - themartorana 12y ago
    I agree. Thank goodness they're not mutually exclusive! I happen to be a Go fan, and thankful testing is well supported in the language and tooling. After having worked heavily in both compiled and dynamic software environments, I do like having compile-time checks on stupid things like typos. All my love to Python, which we use heavily, but my, what some compilation-like tooling would save me. (Nim has really caught my eye recently.) Although after having been spoiled with the static analyzer in Objective-C, probably a contender for my all time favorite language (take from that what you will) I do miss it in Go.

devbug 12y ago

This was the bane of our (backend developers) existence at an Elixir startup. Even if you maintained typespecs--good luck!--and signatures it was still a nightmare.

angersock 12y ago
An Elixir startup? Which one was this?
- devbug 12y ago
  Bex (http://www.bex.io/ http://www.bex.io/).
  - angersock 12y ago
    So, how did you guys end up jumping on the Elixir train? New shiny, or practical reasons? :)
    - bvanslyke 12y ago
      Hm seeing as it's a bitcoin startup with an .io domain.....

colanderman 12y ago

Meh. Dialyzer mostly remedies Erlang's dynamic typing for me (also a big OCaml fan). Almost a little freeing. What kills me is that Erlang's design makes it practically impossible to statically check messaging. ! must be /dev/null as far as Dialyzer is concerned. (Not that solving this is an easy problem! But in an environment as dependent on messaging as OTP, it's a painful shortcoming.)

davidw 12y ago
> ! must be /dev/null as far as Dialyzer is concerned. In day to day use with OTP, you don't use ! much, directly - you're much more likely to do a gen_server:call/cast from within a function that you can easily spec out.

mercurial 12y ago

> My dream language is one with ML semantics running on top of BEAM. That seems like a natural progression for a platform that was designed to be reliable -- while there have been attempts to graft a more versatile type system onto the Erlang base language, the cleanest way forward seems to be a language purpose-built for the task. On the other hand, OCaml is pretty fast in most cases. BEAM doesn't have the same reputation. I think I'd rather have a better parallel and distributed computing story (complete with monitoring capabilities) for the existing OCaml ecosystem. The soft realtime guarantees that Erlang offers are IMHO too much of a price to pay.

zem 12y ago
AliceML is worth a look, though development seems to have died out a few years ago :( http://www.ps.uni-saarland.de/alice/ http://www.ps.uni-saarland.de/alice/
- doublec 12y ago
  I've been helping keep the bitrot away at https://github.com/aliceml/aliceml https://github.com/aliceml/aliceml if you're interested in using it.
- mercurial 12y ago
  This looks interesting. Once I find OCaml too mainstream, I'll have to look at it :)

saosebastiao 12y ago

I'm in the same boat as far as dream languages go. But just out of curiosity, what is it about F# or Scala that you don't like? For me Scala is an amazing language that sacrificed what could have been a clean design for the sake of Java interop, while inheriting a bunch of the baggage of the Java ecosystem (no closures until recently, type erasure, needless boxing, etc). And F# is still a windows-first ecosystem, as much as they would like to tell you otherwise. I'm currently using both, and while I like both of them well enough, I can't ever shake the feeling like I'm missing out on something better.

jallmann 12y ago
> what is it about F# or Scala that you don't like Haven't used either, so giving an opinion on those wouldn't be fair.
mercurial 12y ago
> I'm currently using both, and while I like both of them well enough, I can't ever shake the feeling like I'm missing out on something better. You'd probably like OCaml, considering how F# is basically "OCaml for .NET". And it definitely cannot be accused of having a "Windows-first" ecosystem.

jeffdavis 12y ago

"while there have been attempts to graft a more versatile type system onto the Erlang base language, the cleanest way forward seems to be a language purpose-built for the task." Are you sure that's even possible? Erlang is fundamentally a dynamic system, with hot code (re)loading, processes starting and stopping (possibly crashing), and nodes attaching and detaching. Moreover, the idea that a message can be sent to any PID seems fundamentally at odds with type checking at compile time. You'd probably need to do something more like channels. Perhaps an ML-like type system can work with all of that, but it sounds like a research problem.

NotableAlamode 12y ago
Typing a the message-passing part of a language like Erlang is very much an open research problem. I spoke about this at length with the session type community. They are thinking about this, but it's at least a decade away.
- platz 12y ago
  Isn't Akka planning to add types w/ typed akka? If they can pull that off some subset of Erlang should be doable as well
  - saryant 12y ago
    That's their plan for Akka 3.0. I believe this is the current status: https://github.com/akka/akka/pull/16665 https://github.com/akka/akka/pull/16665
  - mafribe 12y ago
    From a superficial reading I think what they are doing is quite simplistic. Basically they want to provide typed channels, e.g. ActorRef[T] that only accepts T messages. That's the easy part. What you really want is something like type-based guarantees that a the interaction between actors cannot get stuck. Achieving this is fraught with difficulties.
    - 12y ago