Comments on: Dodging the Concurrency Bullet http://dancres.org/feeder/?FeederAction=clicked&feed=Comments+on+Articles+%28RSS2%29&seed=http%3A%2F%2Fwww.dancres.org%2Fblitzblog%2F2007%2F06%2F20%2Fdodging-the-concurrency-bullet%2F%23comment-&seed_title=Dodging+the+Concurrency+Bullet Mon, 02 Jan 2012 08:22:24 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Dan Creswell http://dancres.org/feeder/?FeederAction=clicked&feed=Comments+on+Articles+%28RSS2%29&seed=http%3A%2F%2Fwww.dancres.org%2Fblitzblog%2F2007%2F06%2F20%2Fdodging-the-concurrency-bullet%2F%23comment-147&seed_title=Dodging+the+Concurrency+Bullet/comment-page-1/#comment-147 Dan Creswell Sun, 24 Jun 2007 17:20:18 +0000 http://www.dancres.org/blitzblog/2007/06/20/dodging-the-concurrency-bullet/#comment-147 Possibly, however I think the very essence of the Erlang language itself is what allows it to perform this magic. It may be that one could turn this essence into a general systems design pattern that could be applied across platforms and languages. However I'd be surprised to see this essence widely adopted in existing languages because I think it would change their nature significantly (this is a similar argument to Java gaining all sorts of features that were never really in it's design envelope leading to various kludges). I think Erlang is cool but there's only so much magic that can be done without the programmer helping through correct design. A remote processor conceptually might look the same as a local one but it's going to exhibit significant differences in terms of I/O etc. For a certain class of application (the likes of MapReduce) this won't matter and naive design will suffice but in many other cases that's not true. It's these other cases where the programmer will need to help out with quality design and that's where we need some progress. Possibly, however I think the very essence of the Erlang language itself is what allows it to perform this magic. It may be that one could turn this essence into a general systems design pattern that could be applied across platforms and languages. However I’d be surprised to see this essence widely adopted in existing languages because I think it would change their nature significantly (this is a similar argument to Java gaining all sorts of features that were never really in it’s design envelope leading to various kludges).

I think Erlang is cool but there’s only so much magic that can be done without the programmer helping through correct design. A remote processor conceptually might look the same as a local one but it’s going to exhibit significant differences in terms of I/O etc. For a certain class of application (the likes of MapReduce) this won’t matter and naive design will suffice but in many other cases that’s not true. It’s these other cases where the programmer will need to help out with quality design and that’s where we need some progress.

]]> By: Kaizyn http://dancres.org/feeder/?FeederAction=clicked&feed=Comments+on+Articles+%28RSS2%29&seed=http%3A%2F%2Fwww.dancres.org%2Fblitzblog%2F2007%2F06%2F20%2Fdodging-the-concurrency-bullet%2F%23comment-146&seed_title=Dodging+the+Concurrency+Bullet/comment-page-1/#comment-146 Kaizyn Sun, 24 Jun 2007 07:04:03 +0000 http://www.dancres.org/blitzblog/2007/06/20/dodging-the-concurrency-bullet/#comment-146 Erlang solved this problem largely by using 'green threads' and letting the language interpreter deal with being multi-threaded and/or load-balancing across however many processors you make available to the system. I suspect it won't be too difficult for other languages to adopt the same sort of architecture. Erlang solved this problem largely by using ‘green threads’ and letting the language interpreter deal with being multi-threaded and/or load-balancing across however many processors you make available to the system. I suspect it won’t be too difficult for other languages to adopt the same sort of architecture.

]]>