Live data from Hacker News

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

youtube.com

11–20 of 69 posts

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

#11

Earlier quoted context omitted.

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

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…

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.

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

#12

Earlier quoted context omitted.

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

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…

As far as I can tell, a static, strong typing system sets a baseline of assumptions that you must further verify as an exercise to the business logic programmer. With more dynamic, weak type systems, more tests must exist to achieve a similar level of guarantees. For me, this all seems vaguely similar to when people argued about garbage collectors v. manually managed memory and it's become more that you've traded one set of problems for another, and as far as pragmatic engineering goes I think that's perfectly fine as long as we're better equipped to handle the new problems.

But yes, I'll take strong tests mostly because I can only spend so much time verifying that a type system aligns with my business logic (granted, QuickCheck is neat but requires a high price in flexibility of language choices) and I'd rather take the approach of weaker type systems with partial correctness than the oftentimes all-or-nothing demands of a rigorously structured business framework within a mathematically oriented language. This is very much a "worse is better" sort of approach to me and I argue it's why imperative and OOP languages will continue to dominate in anything outside academic programming.

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

#13
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…

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.

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

#14

Earlier quoted context omitted.

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

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…

> Given a mutually exclusive choice, I'll take a strong test suite over a strong type system any day

That's great as long as you'll only ever work on that one project.

A test-suite yields benefits for one project, a type-system yields benefits for every project.

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

#15
post #13
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…

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.

An Elixir startup?

Which one was this?

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

#16
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…

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

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

#17

Previous discussion: [0] Talk on lowering the barrier to entry into Erlang ecosystem: [1] (slides: [2]) [0] https://news.ycombinator.com/item?id=7927849 [1] https://www.youtube.com/watch?v=Djv4C9H9yz4 [2] http://www.erlang-factory.com/static/upload/media/1404379022...

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

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

#18
Warning: wall of text ahead.

My Erlang experience is admittedly hobbyist, and mostly as a consequence of working my way through Fred's excellent http://learnyousomeerlang.com/ and fooling around with side projects.

As I see it, Erlang does a lot of cool stuff, at a semantic and systems level, but utterly fails when it comes to things like approachability and marketing. These topics are universal to all languages, so I feel that my experience as a relative noob may help to illuminate the general outsider's perception.

First, the things it does well (taken from my admittedly tiny experience with the system):

- Simple language: I love that the surface area of the language really is not that large.

- Concurrency is built in to the core: unlike most languages, the concurrency story is just "there". There isn't fuss or ceremony or terror around it. It has been well thought out, and learning actors in their beautiful Erlang implementation helped me take that knowledge elsewhere (mainly Scala, which I'll come back to).

- Legacy: you hear about the systems people have built with it and it just blows your mind. The ability of the language and runtime to behave as a cohesive, robust unit exists in few other places, if at all. The sort of reliability and scale achieved as a result of this fact is incredible.

And not so well:

- Beginner's story: The build tool was not immediately apparent, and it seemed like the community had still not settled on one. The dependency story seemed primitive and still not settled. The repl is pretty shit compared to every other repl I've ever used: ruby, python, clojure, scala, etc. These are obviously "subjective" perceptions, but I'm a fairly captive audience. I already wanted to learn Erlang, so these things will put me off much less than someone who has to be sold on it.

- General marketing: everyone keeps talking about phone switches and Whatsapp, but I'm not writing software for a phone switch or Whatsapp. I know Erlang works for other uses because I've seen some of the cool stuff the community has done, but I don't think the rest of the world goes out of their way to find awesome uses. It's still seen as this extremely narrow, focused language, when actually people are using it for all sorts of things. A robust general-purpose library ecosystem goes a long way to address this, as people see a lib for their task and go, "ahh, a library for Foo! I can use Erlang!"

- Reliability marketing: Reliability for most programmers is not "Nine 9's of uptime". It's "how badly does this environment let me fuck up before everything goes to hell?" They are effectively two sides of the same coin, with one focused on a negative and the other on a positive. I see a huge, neglected part of Erlang's potential sell in its inability to market itself as letting you move faster and break more things. This doesn't mean you get to be an idiot, but it effectively says to the programmer "I'm going to make it harder for you to create a brittle system. Go on and try to build that adventurous new feature, because I've got your back if shit hits the fan".

Related to these points is that there are other environments that get people "most of the way there" without having to learn a totally alien ecosystem. These are, namely, Go and Scala.

Erlangers will argue that with Go or Scala you may get some of the features of Erlang, you don't get the whole package. This is true, but people don't think this way. People think "does this sufficiently solve my problem, and does it do so at a cost I can live with?" For people familiar with C, the cost of doing a Go project is minimal. Basically, you get concurrency and GC taken care of, while maintaining most of the syntax, semantics, deployment strategy, and programming styles you already know.

With Scala, you get robustness, concurrency, and distributed computing in the form of Akka (to a level that satisfies most people), while preserving access to Java libraries.

Personally, Scala's arguments have been persuasive to me, which is why I'm attempting to introduce it at work in lieu of Erlang. In addition to being more approachable for my mostly Ruby and Javascript-programming colleagues than Erlang (I concede that this point is definitely debatable), I can do nearly goddamn anything in Scala: data analysis, NLP, network services, webapps,number crunching, etc. I work mostly in data on a team that has a large deployment of microservices, and for many questions we face I wouldn't even know where to begin in Erlang. Scala, despite its flaws in terms of binary compatibility, immaturity, type-snobbery, retains a relentlessly practical, marketable feel, that I feel much more confident in bringing before a group of programmers who know neither ecosystem.

If the Erlang community hopes to see the language and system achieve greater general adoption, it has to learn to sell to the general case. It doesn't have to win, but it has to make it easy for people to reap Erlang's amazing features while not missing their Java, Ruby, or Python libs too much, or taking too long to get started. Big ups to Elixir, as its community seems to be working hard to address these problems, and hopefully greater-Erlang can capitalize on the momentum.

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

#19
post #14

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…

> Given a mutually exclusive choice, I'll take a strong test suite over a strong type system any day That's great as long as you'll only ever work on that one project. A test-suite yields benefits for one project, a type-system yields benefits for every project.

True, however. Test suits tests things that a type system never is able to test.

In general, if you reach a non trivial size of code you have to have unit tests in order to stay productive and speedy at a high quality level.

A type-system only speeds you up in the beginning.

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

#20
post #17

Previous discussion: [0] Talk on lowering the barrier to entry into Erlang ecosystem: [1] (slides: [2]) [0] https://news.ycombinator.com/item?id=7927849 [1] https://www.youtube.com/watch?v=Djv4C9H9yz4 [2] http://www.erlang-factory.com/static/upload/media/1404379022...

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?
Post reply on HN