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

Joe Armstrong: Solving the wrong problem

joearms.github.com

Post reply on HN
Print view View original

11–20 of 169 posts

Re: Joe Armstrong: Solving the wrong problem

#11

Post by daleharvey »

I cant help but read a lot of irony in this.

Erlang solved a problem really well over 20 years ago, its the sanest language by far that I have used when dealing with concurrent programming. (I havent tried go or dart yet) and I owe a lot of what I know to the very smart people building erlang.

However it has barely evolved in the last 10 years, will 2013 be the year of the structs? (I doubt it), every new release comes with some nice sounding benchmark about how much faster your programs will run in parallel and there is never a mention of whats actually important to programmers, a vibrant ecosystem and community, language improvements that doesnt make it feel like you are programming in the 80's. Better constructs for reusing and packaging code in a sane way.

Its fairly trivial in most languages to get the concurrency you need, I think erlang is solving the wrong problem in 2013.

Re: Joe Armstrong: Solving the wrong problem

#13

Post by transitorykris »

eridius wrote: post #4
klibertp wrote: post #3

Earlier quoted context omitted.

No, it just makes lock-free and parallel programming much easier.

I can see it making concurrency easier, but lock-free-ness is an attribute of the data structure and the algorithms that interact with it, regardless of how easy it is to write concurrent code.

Lock-free-ness is a consequence of data being immutable in Erlang

Re: Joe Armstrong: Solving the wrong problem

#14

Post by zzzeek »

dustismo wrote: post #9
zzzeek wrote: post #7

> The road to automatic parallelisation of sequential programs is littered with corpses. It can’t be done. (not quite true, in some specific circumstances it can, but this is by no means easy). vs three paragraphs later > Alexander’s talk gave us a glimpse of the future. His company concurix is showing us where the future leads. They have tools to automate the detection of sequential bottlenecks in Erlang code. why i…

I think you missed the "automatic" part. Completely rewriting a program in a new language is certainly not automatic.

both phrases feature the term "automate"...but yes, one is detection, one is resolution

Re: Joe Armstrong: Solving the wrong problem

#15

Post by tieTYT »

daleharvey wrote: post #11

I cant help but read a lot of irony in this. Erlang solved a problem really well over 20 years ago, its the sanest language by far that I have used when dealing with concurrent programming. (I havent tried go or dart yet) and I owe a lot of what I know to the very smart people building erlang. However it has barely evolved in the last 10 years, will 2013 be the year of the structs? (I doubt it), every new release com…

I was following you until your last sentence. I've never done concurrency in a FP language before, but I do know that writing it in Java makes it hard to get right.

Re: Joe Armstrong: Solving the wrong problem

#16

Post by masklinn »

daleharvey wrote: post #11

I cant help but read a lot of irony in this. Erlang solved a problem really well over 20 years ago, its the sanest language by far that I have used when dealing with concurrent programming. (I havent tried go or dart yet) and I owe a lot of what I know to the very smart people building erlang. However it has barely evolved in the last 10 years, will 2013 be the year of the structs? (I doubt it), every new release com…

> I havent tried go or dart yet

Well Go uses shared-memory concurrency and no other so...

Rust still looks more interesting there, though they still have to deliver the language (it's still heavily in flux)

Re: Joe Armstrong: Solving the wrong problem

#17

Post by masklinn »

zzzeek wrote: post #7

> The road to automatic parallelisation of sequential programs is littered with corpses. It can’t be done. (not quite true, in some specific circumstances it can, but this is by no means easy). vs three paragraphs later > Alexander’s talk gave us a glimpse of the future. His company concurix is showing us where the future leads. They have tools to automate the detection of sequential bottlenecks in Erlang code. why i…

> why is that not a contradiction? because an erlang program isn't "sequential" to start with?

Yes. The point is that in a well-coded erlang program only bottlenecks should be sequential (and the bulk should be concurrent), the goal's tool would be (I haven't seen the presentation so I'm throwing ideas to the wall) to see what dependencies lead to sequences in the system reducing overall concurrency and leaving the developer to handle fixing this part if possible.

It doesn't try to automatically parallelize a sequential program, and it does not start from fully sequential programs in the first place.

(not saying I agree with Joe's assertions, they're quite inflammatory and at a very fundamental level lack solid evidence. I have to say I prefer his milder tone to this new "rha rha" one, though this one may yield more visibility for the language I fear the drama)

Re: Joe Armstrong: Solving the wrong problem

#18

Post by mncolinlee »

I worked in Cray's compiler department for seven years. If we couldn't dramatically parallelize someone's code, we couldn't sell a vector supercomputer. Period.

Automatic parallelization is very possible. The problem is tends to be less efficient. A decent developer can often do a better job than the compiler by performing manual code restructuring. The compiler cannot always determine which changes are safe without pragmas to guide it. With that said, our top compiler devs did some amazing work adding automatic parallelization to some awful code.

We inevitably sold our supercomputers because we had application experts who would manually restructure the most mission-critical code to fit cache lines and fill the vectors. Most other problems would perform quite adequately with the automatically-generated code.

What this article lacks is a description of why Erlang is more uniquely suited to writing parallel code than all the other natively parallel languages like Unified Parallel C, Fortran2008, Chapel, Golang, etc. There are so many choices and many have been around for a long, long time.

Re: Joe Armstrong: Solving the wrong problem

#19

Post by PixelPusher »

eridius wrote: post #8
PixelPusher wrote: post #6

Earlier quoted context omitted.

Well, zlib is fairly trivial and probably not a good example due to overheads. However, an example such as a torrent server this would make much more sense. That being said, Erlang is basically a scripting language for building fault-tolerant and parallel applications. Using C, you might be able to get parallel, but it'll be a lot of work to make it distributed and fault tolerant. The underlying data structures have…

I've looked at Erlang before, and I would certainly agree that it's far simpler to write a concurrent application in Erlang than it would be in C. I'm just taking issue with the bit at the end, where they're bragging about removing a serial bottleneck by rewriting zlib in Erlang in order to remove a lock. Rewriting it in Erlang really doesn't have anything at all to do with switching to a lock-free data structure.

Ah yeah, I had to read it a second time to realize what you meant. That's true, that it's a bad example and doesn't make much sense.

I think what they meant to say was that they parallelized the image processing mechanism of the application as a whole.

Re: Joe Armstrong: Solving the wrong problem

#20

Post by masklinn »

meshko wrote: post #12

The lack of understanding is amazingly widespread. I often have to explain to people that when they look at their CPU utilization and it is at 10% it means "you are throwing money way", not "you are efficient".

That's not really true though, or at least not on all workloads: much as you are not "throwing money away" by not pegging your car engine in the red zone 100% of the time, you're not throwing money away by not being at 100% CPU all the time, there are other metrics, values and issues to take in account e.g. a pegged CPU but an unresponsive computer is useless for a desktop, a pegged CPU which can't serve requests because the CPU is pegged because it's swapping like mad is useless for a server, so is a server at 100% CPU when there's no load on it which will just keel over when people start trying to actually interact with it.
Post reply on HN