Live data from Hacker News

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

pragprog.com

121–130 of 193 posts

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

#121

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

I also interpret it this way.

If you recall the famous Wide Finder benchmark for parallel programming by Tim Bray, back in 2007 as well [1], those were essentially the results.

Languages like Erlang or JoCaml (Ocaml plus joint calculus), whose models are inherently parallel yield simple and fast solutions.

Other languages too, but they require a lot of expert optimization and ugly code.

[1] https://www.tbray.org/ongoing/When/200x/2007/09/20/Wide-Find...

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

#122
post #53

Earlier quoted context omitted.

Oh, sure, there are plenty of things getting in the way of developers being excited about using Erlang and thus deciding, in a bottom-up sense, to build more stuff in Erlang. But I think Erlang's use-case isn't really the type of software developers get excited about developing, either way. The type of software Erlang is "best at" (and where it would reduce codebase size the most) is exactly the type of big Enterpris…

But did it have to become niche? I think Erlang could very well have branched out to become a more even general-purpose language, rather than doubling down on distributed computing to the exclusion of more quotidian tasks. Sure, Erlang will never be able to compete with certain languages such as C and C++ for many use cases. But I often grab Go to create small command-line tools, or do some minor parallel data proces…

I don't think it helps that the largest non-Ericsson commercial entity that attempts to curate and bounding-box the community has a kind of identity crisis around whether or not it's a services or products company.

For whatever reason they didn't do much in the way to create and maintain modern tooling to make on-boarding easier, which would have facilitated increased adoption, and lead to more revenue potential. Neither relx, nor rebar, nor erlang.mk, etc. were born out of said commercial entity, despite those kinds of things being perfect candidates for a services company to produce to make their own lives and the lives of potential new users easier.

There have been some huge high-profile Erlang use cases that would normally feed a Silicon Valley/Hacker News style hype-cycle, but somehow those came and went with almost nothing to show for it. It almost feels like if Elixir hadn't shown up on the scene to attract new users and splinter off a chunk of the massive Ruby community that the Erlang side of the world would all but dead already. Sometimes I wonder how it is one goes about blowing a 15+ year technology lead and 10 years of huge and publicly visible wins, but that's sorta what's happened.

In the curation of said community there's also been an overtone of nostalgia for "the good old days" & "yeah, that part is supposed to be painful", and a sort of long-running tone deafness around on-boarding, usability, general-developer-ecosystem-friendliness, etc. complaints that certainly could have had a lot more done to be ameliorated by the commercial entities who stood to gain the most by Erlang having broader adoption.

Frankly, much like Elixir breathing a bit of new life into aura around Erlang, if it weren't for people like Fred, Tristan, Alisdair, Garrett and a few others (who again aren't part of the core supports for Erlang commercially) being really passionate against all odds about making Erlang easier to use, and to explore new use cases, and to meticulously and engagingly document all of it... Erlang would probably be dead already.

All of which might be overly harsh, but I'm having a very acute existential crisis around Erlang at the moment. I love it. I love developing in it. I love introducing it to teams and projects. And as time goes on I feel rapidly and increasingly more guilty about that given the decline it seems to be in and has been in if I'm being honest with myself in retrospect.

Blargh :-(

edit: look at the increasingly dwindling sponsors list of Erlang Factory San Francisco over the last several years as an indicator of the above rant/cry-for-help.

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

#123
post #119

How to make sure I don't read your post: > Our site has been optimized for use with newer browsers. We also require that your browser has JavaScript enabled. > It looks as if your browser has JavaScript disabled. > This site has information about enabling JavaScript, if that's something you want to do. Really? I am just trying read a few paragraphs of text on a fairly static-looking site.

It's even worse than that. It is static. It would work without javascript if they didn't put

      
        
      

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

#124

Earlier quoted context omitted.

But did it have to become niche? I think Erlang could very well have branched out to become a more even general-purpose language, rather than doubling down on distributed computing to the exclusion of more quotidian tasks. Sure, Erlang will never be able to compete with certain languages such as C and C++ for many use cases. But I often grab Go to create small command-line tools, or do some minor parallel data proces…

I don't think it helps that the largest non-Ericsson commercial entity that attempts to curate and bounding-box the community has a kind of identity crisis around whether or not it's a services or products company. For whatever reason they didn't do much in the way to create and maintain modern tooling to make on-boarding easier, which would have facilitated increased adoption, and lead to more revenue potential. Nei…

Thanks for the insight. Out of interest, what company are you referring to in your first paragraph?

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

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

I've always enjoyed writing MUDs (similar to roguelikes), and I found Clojure's killer feature to be immutability, rather than some of the fancier concurrency features like STM. Operations that consume the most resources in a MUD tend to be very amenable to stale, but consistent snapshots, which immutability makes pretty easy to do. My goal was more about responsiveness than throughput though.

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

#126

Earlier quoted context omitted.

I don't think it helps that the largest non-Ericsson commercial entity that attempts to curate and bounding-box the community has a kind of identity crisis around whether or not it's a services or products company. For whatever reason they didn't do much in the way to create and maintain modern tooling to make on-boarding easier, which would have facilitated increased adoption, and lead to more revenue potential. Nei…

Thanks for the insight. Out of interest, what company are you referring to in your first paragraph?

Erlang Solutions

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

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

> In this server, the world was divided into 80x24 subgrids that did most of their processing in parallel.

Is there any reason why you do update() in parallel? There is certainly some interesting challenges to solve there but did you have a reason to make it parallel other than intellectual curiosity (e.g. better performance)?

Afaik a game loop's update() is not the intense part in the game loop (maybe that's different for games with lots of world information update, like roguelikes), but rather render() and IO() are so I am wondering what your design thoughts are.

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

#128
post #93

Earlier quoted context omitted.

>> 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. You've made two claims, one irrelevant and one false: 1. only if your program is…

>only if your program is embarrassingly parallel is irrelevant, because a almost every program is embarrassingly parallel in Erlang. The language is built around concurrency to the point that parts which wouldn't be obviously parallel in another language are in Erlang. Further, slow hashes in crypto have taught us that is actually quite difficult to make something which can't be parallelized. OK. Not an Erlang user,…

The prescheduler caps the execution window for anything that would block. If one piece of the system would take a long time to finish, it doesn't interfere with the other parts of the system completing their work on schedule. That one blocking piece will finish more slowly, but ever other moving part in the system will keep responding as expected.

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

#129

Earlier quoted context omitted.

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 this server, the world was divided into 80x24 subgrids that did most of their processing in parallel. Is there any reason why you do update() in parallel? There is certainly some interesting challenges to solve there but did you have a reason to make it parallel other than intellectual curiosity (e.g. better performance)? Afaik a game loop's update() is not the intense part in the game loop (maybe that's differe…

Is there any reason why you do update() in parallel?

I wanted to come up with an architecture that could support an arbitrarily large world given enough resources. Up to a certain density (from 150 to 250 users per "subgrid") I was close to succeeding.

Afaik a game loop's update() is not the intense part in the game loop but rather render() and IO()

"Render" in the context of a server like this is the IO. One thing you should know, is that this game supported Conway's Life cellular automata at 12 frames/second, completely shared and multiplayer.

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

#130

Earlier quoted context omitted.

I'm not devishard, but I parsed his statement slightly differently. He's not saying that Erlang makes things parallel magically. Rather, he's saying that Erlang forces tasks that /could/ be parallel to be parallel by default. Thus, Erlang will tend to maximize the sections of your program that are run in parallel compared to other languages.

Which would make the original commenter's point valid: >Your Erlang program should just run N times faster on an N core processor No, it won't. It will only be true for tasks that /could/ be (completely/embarrasingly) parallel (as you say). Which is kind of circular.

Not really. Think about every object you'd have in Java that's being passed around your system. Now imagine each of those objects are their own processes and you're passing around references to them.

Just on that one case, you've taken huge chunks of a linear execution pattern and parallelized it. Now make that your norm and amplify it to everything. Now realize that the message passing allows this mode of operation to spread each part of this workload over not only more cores but more machines across the network.

And then realize that you can deploy updates to this codes individual parts while other parts continue running without taking down the whole system.

Then you get Erlang.

Post reply on HN