Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's all this fuss about Erlang? (2007)

pragprog.com

Post reply on HN
Print view View original

41–50 of 193 posts

Re: What's all this fuss about Erlang? (2007)

#41

Post by lobster_johnson »

derefr wrote: post #12
davidw wrote: post #3

This was back in a brief period when Erlang was being hyped by people as a potential Next Big Thing. Unfortunately it never really got that much momentum though, until Elixir and Phoenix came along.

I've always thought that Erlang would be more successful if it had a better deployment story, along the lines of Go or Rust: e.g. if you had the option of baking an Erlang runtime into a static binary. As it stands, software like ejabberd and rabbitmq are pretty ugly in OS package form (because distro maintainers think such packages need to rely on a common, usually very old, Erlang runtime, instead of allowing them…

I think that would help, but in my opinion, Erlang's syntax and overall projected surface has always been its biggest hurdle to wide adoption. You can have the most amazing, powerful language ever, but it still won't receive popular adoption if you're too strange and you can only attract a certain type of highly-skilled senior devs.

I'm not a fan of Elixir's quasi-Ruby syntax — I think something closer to Go or Nim would have served it better — but it's certainly a step in the right direction.

The Erlang toolchain has a ton of ergonomic issues that could have been polished down a long time ago, but haven't been. Erlang simply feels oddly quirky and antiquated for anyone used to modern GNU tools or modern REPLs.

For example: Lack of Readline support (needs rlwrap to be usable, at least on Ubuntu), lack of GNU-style long options, the obnoxious ctrl-C behaviour that doesn't respect Unix conventions and gives you a prompt with confusing options (quick, what's the difference between "abort" and "kill"?) that seem aimed at developers and are completely wrong if you're just a user of an Erlang tool. (Couldn't they have relegated this to USR1 or something instead of INT, like a normal program?) On the server, the epmd process is a thorn in the side of any system administrator. Erlang devs also seem to think that emitting Erlang stack traces is a good replacement for proper English error messages, and if you're not an Erlang dev, you haven't seen stack traces until you've seen the kind of monstrous, obscure, deeply nested contextual dumps that Erlang programs can produce.

And so on. Little things, but important things that can completely kill the joy when you're a potential adopter.

Erlang shouldn't need Elixir to modernize, but there's probably very little incentive within the community to change quirks that they're all used to dealing with by now.

(I encountered similar issues with OCaml, which has many parallels to Erlang: Quirky, odd syntax, antiquated toolchain, etc. Facebook's cleanup effort [1] looks very promising.)

[1] https://facebook.github.io/reason/

Re: What's all this fuss about Erlang? (2007)

#42

Post by timClicks »

chrisseaton wrote: post #9

> Your Erlang program should just run N times faster on an N core processor But only if your program is embarrassingly parallel with at least N times available parallelism in the first place! If you have one of those it's already trivial to write a version that runs N times faster on N cores in C, Java, multi-process Python, whatever. If your program has sequential or less parallel phases or needs to communicate then…

That's true, but when I read that sentence I place the emphasis on should. I see it as aspirational.

A better way to phrase this would perhaps would be to say that perfectly preemptive scheduler should be able to keep all cores hot. Blocking of one Erlang process should not halt the program's progress.

As Erlang requires message passing overhead by design, it will never see perfectly linear scaling behaviour. Still, its scheduler, its GC model and M:N threading implementation are extremely robust and can be relied upon to write extremely reliable networked services.

Re: What's all this fuss about Erlang? (2007)

#43

Post by chrisseaton »

floatboth wrote: post #40
chrisseaton wrote: post #9

> Your Erlang program should just run N times faster on an N core processor But only if your program is embarrassingly parallel with at least N times available parallelism in the first place! If you have one of those it's already trivial to write a version that runs N times faster on N cores in C, Java, multi-process Python, whatever. If your program has sequential or less parallel phases or needs to communicate then…

Obviously said "program" must be a server that services independent requests. I mean, not obviously, but if you work in telecom, web, etc. that's pretty much all programs you see.

I get that, but as I say we already knew how to scale those linearly in most programming languages. Erlang brought nothing new there.

It does have advances in things like reloading and supervision.

Re: What's all this fuss about Erlang? (2007)

#44

Post by mnd »

slashdotdash wrote: post #4

Dave Thomas has described Elixir as follows: "Elixir took the Erlang virtual machine, BEAM, and put a sensible face on it. It gives you all the power of Erlang plus a powerful macro system."[1] [1] https://startlearningelixir.com/elixir-for-rubyists

Erlang is a great programming language after one takes the time to understand the principles underlying it and its design. Everything fits very nicely into place. There are definitely things that could be done better, but then that’s the case with most programming languages and technologies after they have accumulated some dust. Elixir on the other hand, in my personal opinion, is a false prophet simply because it looks like something which it isn’t. It looks like Ruby and gives the programmer the feeling that he’s right at home, except it is in fact a very different beast with very different semantics, Erlang semantics, as opposed to Ruby. Therefore, if you want to program on the BEAM (the Erlang virtual machine) you better make sure you actually understand the system, its design, principles and also some of the semantics of Erlang itself, point at which you might as well just learn Erlang. I’m not saying that you cannot learn those things coming from Elixir, I’m just saying that if you want to build systems of reasonable complexity (like the ones that Erlang is known for) on top of the Erlang virtual machine, as opposed to CRUD web applications, then you must understand a lot more than just Elixir or Phoenix.

Re: What's all this fuss about Erlang? (2007)

#45

Post by lliamander »

jcoffland wrote: post #7
aaron-lebo wrote: post #2

I think the "more cores == faster" benefit is overstated. Without jit Erlang is so slow that languages without concurrency support will kill it. It's even more overstated when something like Go can mostly scale as well over multiple cores but be x times faster while doing so. Not to mention it's 10 years later and we haven't seen massively parallel architectures take off. I suspect other languages are going to fold t…

Agreed. I don't think there is a big fuss about Erlang anymore. Still it's an interesting language from an acidemic perspective if not from a practical one.

Erlang is certainly inaccessible, but I don't think academic is really the right word for it. It was born out of very practical business needs, and the reason it is still around is mainly because it has done an excellent job of serving those use cases.

What they haven't done (or to the extent that other languages have) is make the language and runtime accessible to the broader programming community. The result is that the people who (start to) use Erlang are the kind of people for whom no other tool will help them solve their problems.

Although I have not used Elixir, it seems to me that it was designed as a language that is easy enough to adopt for the wider programming community, while still leveraging the concurrency, fault-tolerance, etc. provided by BEAM and OTP. On top of that, the Elixir community has worked hard to provide the tooling and support developers typically expect these days[0].

This is not to say that Erlang should be radically altered or abandoned. I like the Erlang aesthetic and ethos, and I think the community knows the way it needs to evolve. It is just that I expect more people to come to BEAM and OTP through Elixir than Erlang, and I think it is that platform that should really be the focus.

[0] to their credit, the Erlang community has definitely improved in this area.

Re: What's all this fuss about Erlang? (2007)

#46

Post by stcredzero »

zazibar wrote: post #18
stcredzero wrote: post #14

Earlier quoted context omitted.

I think the "more cores == faster" benefit is overstated. I've tried to create servers for massively multiplayer games in Clojure and Go. What I've found is that it "takes some doing" to be able to efficiently use many processors in parallel. You can't just slap on a pmap call in Clojure or do the equivalent cheesy channel trick in Golang and have good utilization of all your cores in parallel. It's even more oversta…

Can you elaborate on how you implemented those servers? Would you still use Clojure or Go for them now? If not, what alternative do you suggest?

My first attempt was a server for a dungeon crawler that superficially looked like a rogue-like, but was actually 12 frames/sec realtime instead of turn based. It started out on Clojure, but I afterwards ported it to Go. In this server, the world was divided into 80x24 subgrids that did most of their processing in parallel. Processing would happen in two stages: 1) local data processing, where each entity got updated in a loop, sending out updates to clients and 2) collision resolution/movement. If I had to do it over again, I would relax the grid's invariant properties, and make each 80x24 subgrid completely independent, which would eliminate the collision resolution step.

In my current server, I'm basically sharding my space-game into star systems, with free travel between star systems though "Hyperspace." There is a farm of "worker processes" that is coordinated by a master server. Any instance of a star system can be idempotently spawned when a client is attached to it. https://www.emergencevector.com >

I think Go is a good option for writing a game server. You'd have to be pretty profligate to make the GC pause overrun one 16.66 ms tick, and if you miss a tick here and there, who cares?

Re: What's all this fuss about Erlang? (2007)

#47

Post by gamache »

nilved wrote: post #30
gamache wrote: post #21

Earlier quoted context omitted.

Do you realize how silly this sounds? You are disregarding not only Erlang, but decades of research and development on concurrent programming best practices. Immutability has been promoted for parallel programming since the 1970s. For the past fifteen years, even languages like C++ have moved to promote this style of programming. (Also, Erlang has a compile-time static type checker, if type safety is something you're…

Are you referring to Dialyzer? I've always wanted to learn Erlang but can't give up on types.

Yup, Dialyzer. Works with Elixir too (there's even a Dialyxir mix task) and gives me all the type checking I want -- which admittedly isn't much.

Re: What's all this fuss about Erlang? (2007)

#48

Post by zzzcpan »

chrisseaton wrote: post #9

> Your Erlang program should just run N times faster on an N core processor But only if your program is embarrassingly parallel with at least N times available parallelism in the first place! If you have one of those it's already trivial to write a version that runs N times faster on N cores in C, Java, multi-process Python, whatever. If your program has sequential or less parallel phases or needs to communicate then…

> If you have one of those

And how would you have one of those? Erlang encourages you to design and think about programs in a certain way, that typical C, Java or Python does not. I've seen Armstrong in one of his talks to actually emphasize the importance of learning distributed systems if you wanted Erlang to be useful for you. That's way beyond "embarrassingly parallel" point of view, Amdahl's law has no use here.

Re: What's all this fuss about Erlang? (2007)

#49

Post by davidw »

lobster_johnson wrote: post #41
derefr wrote: post #12

Earlier quoted context omitted.

I've always thought that Erlang would be more successful if it had a better deployment story, along the lines of Go or Rust: e.g. if you had the option of baking an Erlang runtime into a static binary. As it stands, software like ejabberd and rabbitmq are pretty ugly in OS package form (because distro maintainers think such packages need to rely on a common, usually very old, Erlang runtime, instead of allowing them…

I think that would help, but in my opinion, Erlang's syntax and overall projected surface has always been its biggest hurdle to wide adoption. You can have the most amazing, powerful language ever, but it still won't receive popular adoption if you're too strange and you can only attract a certain type of highly-skilled senior devs. I'm not a fan of Elixir's quasi-Ruby syntax — I think something closer to Go or Nim w…

As a long-time Erlang user, I think the above is a lot closer to why people always seemed to have some trouble with it. Lots of little weird things.

Part of this is that Erlang kind of wants to be its own little world - something that it shares to some degree with Lisp and Smalltalk (images!).

Re: What's all this fuss about Erlang? (2007)

#50

Post by Vaelatern »

stcredzero wrote: post #46
zazibar wrote: post #18

Earlier quoted context omitted.

Can you elaborate on how you implemented those servers? Would you still use Clojure or Go for them now? If not, what alternative do you suggest?

My first attempt was a server for a dungeon crawler that superficially looked like a rogue-like, but was actually 12 frames/sec realtime instead of turn based. It started out on Clojure, but I afterwards ported it to Go. In this server, the world was divided into 80x24 subgrids that did most of their processing in parallel. Processing would happen in two stages: 1) local data processing, where each entity got updated…

Why did you leave Clojure?
Post reply on HN