Live data from Hacker News

Ask HN: Why isn't Erlang more popular?

news.ycombinator.com

91–100 of 244 posts

Re: Ask HN: Why isn't Erlang more popular?

#91

I haven't looked at Erlang before, so I thought I give it a quick look. Google led me to the Erlang home page[1], which has "What is Erlang" (sounds good) and "What is OTP" (which doesn't bother to define what O, T, and P stand for.) Following the Erlang Quickstart [2] link, I get a page that doesn't really tell me anything about the language. It demonstrates a program that implements a factorial function, then tells…

Ffs, you're not looking at some small product that an unknown company built. You're looking at something that is really well-known. What does the website of Google convey? Do you really decide whether you'd learn a language by looking at its website?

> "that the online reference doesn't cover interaction with anything outside of your program" This does NOT mean it does not teach you IO. The full bullet point is

> "How to communicate with the outside world and/or software written in other languages (ports). There is however a separate tutorial for this, Interoperability Tutorial"

It means it won't teach you FFI in a tutorial.

> "guessing that Erlang is one of those functional languages that are great for mathematical proof-like software development but not practical for solving actual problems because the world is mutable and the language constructs are not."

I don't know how you got to this dumb conclusion when "What is Erlang?" on the main page clearly states:

> Erlang is a programming language used to build massively scalable soft real-time systems with requirements on high availability. Some of its uses are in telecoms, banking, e-commerce, computer telephony and instant messaging. Erlang's runtime system has built-in support for concurrency, distribution and fault tolerance.

Re: Ask HN: Why isn't Erlang more popular?

#92
post #55

Earlier quoted context omitted.

Come on. Not exactly a good faith effort, is it? Why type in a rant like this, when you could have found a wonderful tutorial on Google in one tenth of the time it took you to write this?

He's doing this in good faith because I, the original poster, asked him too. This is the best answer on the page (for me).

But this doesn't tell you anything, other than that someone who's not interested and pressed for time won't put any effort into it. It's a trivial result.

Re: Ask HN: Why isn't Erlang more popular?

#93
I like a lot of things about Erlang. But the main reason I would be wary of using it is that it seems like an all-or-nothing kind of thing. The distributed actor model effectively means Erlang everywhere. This contrasts with RPC, queues, http, etc. where a variety of technologies (and languages) can be combined together. And an all-in approach seems laden with risk - all devs and relevant technologies need to fit in with the Erlang stack.

And if you are not using distributed actors, then why bother with Erlang at all?! (It's a nice language to be sure, but there are lots of nice functional languages available so the competition is pretty fierce).

Re: Ask HN: Why isn't Erlang more popular?

#94
post #52

Erlang is a very specialised language. It does one thing well (scalability) at the expense of not really being a general purpose language. The syntax is just weird, not only in a paradigm-way (pattern matching is not huge in most languages, but, hey, that's the way of doing stuff in functional programming), but on strange places ("read" lines ending on dot, semicolon takes time, it does not share any common syntax de…

This. It's amazing and powerful if you need 1m+ client connections per server. Outside of the epic scale engineering problems of facebook, twitter, google, amazon, whatsapp... It's very difficult to get anything done with Erlang. If you have fewer than a million people using your application at a time, you're probably better off writing it in a more normal language.

I'd say it works for small scale as well. The concurrency is awesome, but (and this may just be from limited experience) I've yet to see another language that handles binary matching and manipulation as well. I tried to sell my current office on erlang for one project. Take a dozen mutually incompatible protocols (used by systems that can't be updated easily to a new or common protocol, that's actually been tried and is why there are a dozen protocols now) and create a proxy/translator server for all of them. In essence we have a dozen networks that can't talk to each other, but send the same information using their own formats. Writing a translator from one protocol to another (or my suggestion of one protocol to intermediate representation to second protocol, need only 24 translation modules instead of 12! translation modules) was trivial for my proof of concept sytem. The concurrency was really just a nice bonus, in this case.

Re: Ask HN: Why isn't Erlang more popular?

#95

Earlier quoted context omitted.

Not knowing enough about Erlang/OTP or Go: Would it be possible for more of OTP to be replicated in a Go 2.0? What's missing? What would it take? What can never be replicated?

Besides the issues that jerf mentioned, Erlang also has per-process garbage collection built right into the VM. Last time I checked Go's garbage collection was still stop-the-world, mark-and-sweep, making it less suitable for soft real-time systems than Erlang.

"Go 2.0" probably can't ever quite fix that, but there's some potential for improvement; one can imagine as an optimization the compiler being able to determine a particular goroutine really is isolated (no shared state with anything else at start time, communicates only via channels that are full copiers of state, etc.) and independently GC's them, and also excludes them from the "stop" in the "stop the world". But yes, it is stop-the-world, and I'm keeping a close eye on the GC performance in the app I'm transitioning. (So far the numbers are working out OK, but it's definitely in the range I have to watch out.)

Re: Ask HN: Why isn't Erlang more popular?

#96
post #11

Earlier quoted context omitted.

Erlang is much easier than Haskell. Haskell breaks my mind, but Erlang is easy-peasy.

Yes, but newcomers don't know that. First thing they see is old school algol-like spaghetti. :) Haskell looks much nicer.

what does this nicer non-spaghetti do?

chunkWith :: ([a] -> ([a], [a])) -> [a] -> [[a]]

chunkWith _ [] = []

chunkWith f xs = let (h, t) = f xs in h : chunkWith f t

i'm sure that many here merely glance at that and understand it immediately. but as i typed above, it somehow makes me feel bad about my own stupidity. (no need for anyone to explain specifically what this tiny example does, (i actually happen to understand this one). the goal here is to admire the immediate obviousness of the syntax ;))

Re: Ask HN: Why isn't Erlang more popular?

#98
post #16

Honestly, I think what kills it is that it's not an Algol-descended language [1]. If Erlang was written with an Algol-esque syntax it would have taken off years ago. But instead it has this weird syntax, which it then doesn't really do that much with. What do I mean by that? Haskell has a radically different syntax, but it does things with that syntax and its pervasive currying to enable a powerful succinctness that…

The syntax issue is why I think the Elixir programming language[1] has a good chance of improving the ecosystem around the Erlang VM. Although, most Erlang programmers, who i've spoken to, feel the syntax is a non-issue, so it is more likely to convert programmers who are new to, or curious about, Erlang. It is also worth a note that Elixir adds language features, such as default UTF8 binary strings, real macros, Clo…

[deleted]

Re: Ask HN: Why isn't Erlang more popular?

#99
post #16

Honestly, I think what kills it is that it's not an Algol-descended language [1]. If Erlang was written with an Algol-esque syntax it would have taken off years ago. But instead it has this weird syntax, which it then doesn't really do that much with. What do I mean by that? Haskell has a radically different syntax, but it does things with that syntax and its pervasive currying to enable a powerful succinctness that…

I think this is mostly right. Erlang is, roughly, in the Lisp, Forth, Smalltalk bin, not the C, Ruby, Go bin. Its advocates are going to be going on about how "Erlang got that right in 199something" for years, even when things like Go have got most of what it has.

I wrote about Erlang 7 years ago, and a lot of that still holds true, IMO:

http://journal.dedasys.com/2007/09/22/erlang/

That said, I lately helped start a pretty big project in Erlang and have been using it a lot lately. It has improved, and it's a fun language to use in a lot of ways.

Re: Ask HN: Why isn't Erlang more popular?

#100
I fall under the "tried it & stopped" category.

I stumbled upon Erlang in 2011, and did the full "Learn You Some Erlang for Great Good!" tutorial and about 1/2 of the Erlang Programming book (and exercises). Where I ended up is that I had no real-world use cases that would benefit from Erlang, so I just kind of atrophied with it. It seems to me like Erlang is really really good at building programs that can be modeled with message passing (like chat), but a lot of problems are difficult to map to that paradigm (or perhaps my mind just has trouble envisioning how to do it yet). The closest I got was starting to use it to write a distributed Web crawler, but I ended up using scrapy (a Python framework) because the string manipulation was annoying with Erlang, and scrapy already had a lot of features that I would have had to re-implement on my own. But as I'm starting to try and manage crawler distribution with Celery and RabbitMQ, I find myself starting to think more and more about how Erlang would probably do this bit in particular better, so I might return to it.

The language that I've since discovered I really want for most tasks is Haskell. I've been programming Ruby full-time for the last few years, and I've grown really jaded with it. I get sick of having to write so many unit tests around everything in what I see as a poor fix for its loosy-goosyness. I'm still pretty early on in learning Haskell, but I find the approach towards correctness first to be exactly what I want, and while so far some of the material is pretty challenging I can see it will be very rewarding as well.

Post reply on HN