Live data from Hacker News

Why the Cool Kids Don't Use Erlang [video]

youtube.com

41–50 of 69 posts

Re: Why the Cool Kids Don't Use Erlang [video]

#41
post #3

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 O…

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…

> 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.

Re: Why the Cool Kids Don't Use Erlang [video]

#42
post #3

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 O…

"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 a…

I've never used Erlang, but Cloud Haskell (http://haskell-distributed.github.io/) and Elm's hot-swapping (http://elm-lang.org/blog/Interactive-Programming.elm) seem to combine an ML-like type system with some of the features you list.

Re: Why the Cool Kids Don't Use Erlang [video]

#43

Earlier quoted context omitted.

"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 a…

I've never used Erlang, but Cloud Haskell ( http://haskell-distributed.github.io/ ) and Elm's hot-swapping ( http://elm-lang.org/blog/Interactive-Programming.elm ) seem to combine an ML-like type system with some of the features you list.

Cloud haskell is interesting but doesn't even approach the level of the same capabilities as Erlang w/ OTP and BEAM, and the creator of Elm has described it as a language primarily oriented for responding to UI concerns, not a systems language

Re: Why the Cool Kids Don't Use Erlang [video]

#44

Earlier quoted context omitted.

"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 a…

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.

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

Re: Why the Cool Kids Don't Use Erlang [video]

#45

Earlier quoted context omitted.

"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 a…

> Are you sure that's even possible? No. Simon Marlow and Philip Wadler tried to make a type system for Erlang and couldn't do it [1]. And if they couldn't do it... well, it's a very hard problem, for many of the reasons you cited. From what I understand, the general consensus is that Erlang's dynamic types are a small price to pay for the flexibility and features afforded by the runtime. To be fair, what makes Erlan…

I don't believe that one should attempt to copy the Erlang model in a typed language (and this is one reason I don't particularly like Akka). There are many facilities, some noted in other comments, that make statically typing Erlang difficult but I don't believe most of these are necessary.

Can send any message to any actor? Probably a bug.

Hot code swapping? Never had a need for this. Restarts are fine. Any distributed system is supposed to be crash resistant. A restart is just another crash.

I much prefer the CSP model to the Actor model in any case (with asynchronous channels available), and it is much easier to type CSP.

Interested in others thoughts.

Re: Why the Cool Kids Don't Use Erlang [video]

#46

Earlier quoted context omitted.

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.

>Compile time checking basically replaces a large chunk of unit tests one would have to write and maintain to cover the same issues. As does static analysis. You do use a ruby static analysis tool on your project, right?

The last ruby project that I worked on laughed at static analysis tools before pitching them into halting problems. You have to execute ruby code just to assemble the classes, it's quite resistant to static analysis unless you artificially restrict yourself to a subset of the language.

If you're going to limit yourself to the statically checkable part of the language then you might as well just use a language that was designed for it. The fundamental feature of dynamic languages is variations on the theme of self-modifying code - behaviour is determined at runtime. This feature is not normally considered compatible with static analysis, because you have to execute an unbounded amount of the program to find out what it does.

The important thing about static type checking on languages like ocaml is that it can be both "sound" and "complete" - any type error is an error in your program, and a program that type checks cannot go wrong according to the constraints of the type system. In order to make this possible, we have a body of theory on how to design type systems that are constrained just enough to be checkable while still expressing everything you want them to say.

Re: Why the Cool Kids Don't Use Erlang [video]

#47
post #25
post #24

Earlier quoted context omitted.

Kent Beck invented TDD while programming in Smalltalk, having recalled reading a paper on using TDD with punched tape. I think Rob Pike is confused in his history/assertion.

It may be that the popularity of TDD was fueled by this, if not its existence directly.

Yes, TDD became popular many, many years after smalltalk.

Re: Why the Cool Kids Don't Use Erlang [video]

#48

Earlier quoted context omitted.

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'r…

Strong type systems (as opposed to weak) come at very little cost, though. There really isn't any reason not to use a language with a strong type system. It will catch a massive multitude of otherwise uncaught bugs and slash unexpected behavior. It doesn't magically replace all tests, but it means you need fewer of them to achieve the same level of quality. Static typing has a similar effect, but it's weaker (number…

The issue is that imperative languages with strong type systems essentially haven't been a thing until Rust[0], and not everyone enjoys working in Haskell's world of applicatives, monads and functors - you certainly can't say that it's an easy replacement for, say, Python in most companies.

Hopefully Rust will encourage the next generation of programming languages to follow its lead.

[0] And possibly Nim? I've not looked into it to see how strong its type system is, though.

Re: Why the Cool Kids Don't Use Erlang [video]

#49
post #17

Earlier quoted context omitted.

I feel like Elixir in general goes a long way to lowering the barrier to using BEAM and OTP.

Do you think folks who are just getting started in the Erlang ecosystem would be better to learn Elixir before Erlang?

I'm at a basic level with Elixir (played around a little bit with Erlang first), and so far I'd say definitely - the syntax choices seem very, very good, and it's a pleasure to work with. I can now read Erlang code pretty easily because of this, the concepts and structure are often the same, but introduced in a far more understandable way, and it's felt a hell of a lot smoother than going Erlang first - YMMV of course.

Re: Why the Cool Kids Don't Use Erlang [video]

#50
post #28

Earlier quoted context omitted.

> 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 repu…

AliceML is worth a look, though development seems to have died out a few years ago :( http://www.ps.uni-saarland.de/alice/

I've been helping keep the bitrot away at https://github.com/aliceml/aliceml if you're interested in using it.
Post reply on HN