Joe Armstrong: Solving the wrong problem
joearms.github.com
Joe Armstrong: Solving the wrong problem
1–10 of 169 posts
Re: Joe Armstrong: Solving the wrong problem
#2If zlib could be rewritten in Erlang to be lock-free, why not just rewrite it in C to be lock-free instead of porting it? AFAIK Erlang isn't some magical language that allows traditionally-locked data structures to become lock-free.
Re: Joe Armstrong: Solving the wrong problem
#3If zlib could be rewritten in Erlang to be lock-free, why not just rewrite it in C to be lock-free instead of porting it? AFAIK Erlang isn't some magical language that allows traditionally-locked data structures to become lock-free.
No, it just makes lock-free and parallel programming much easier.
Re: Joe Armstrong: Solving the wrong problem
#4If zlib could be rewritten in Erlang to be lock-free, why not just rewrite it in C to be lock-free instead of porting it? AFAIK Erlang isn't some magical language that allows traditionally-locked data structures to become lock-free.
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.
Re: Joe Armstrong: Solving the wrong problem
#5In conventional blocking languages, you can get a start on parallelizing your programs this way:
- break program into function calls that match the steps that can happen in parallel
- wrap the function calls in messages passed over the network
+ i.e. process(thing) -> post(thing)/poll_for_things()
- split the sender and receiver into different processes
Re: Joe Armstrong: Solving the wrong problem
#6If zlib could be rewritten in Erlang to be lock-free, why not just rewrite it in C to be lock-free instead of porting it? AFAIK Erlang isn't some magical language that allows traditionally-locked data structures to become lock-free.
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 little to nothing to do with what's being said in the article.
Re: Joe Armstrong: Solving the wrong problem
#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 is that not a contradiction? because an erlang program isn't "sequential" to start with?
Re: Joe Armstrong: Solving the wrong problem
#8If zlib could be rewritten in Erlang to be lock-free, why not just rewrite it in C to be lock-free instead of porting it? AFAIK Erlang isn't some magical language that allows traditionally-locked data structures to become lock-free.
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.
Re: Joe Armstrong: Solving the wrong problem
#9> 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.
Re: Joe Armstrong: Solving the wrong problem
#10> 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…
They're different statements. Taking a sequential program and automatically parallelizing it is a very hard problem. What this tool does, as I read it, is simply find sequential parts of code, and it's up to the devs to figure out how to parallelize said code.