The Concurrency Myth
fupeg.blogspot.com
fupeg.blogspot.com
http://www.danielmoth.com/Blog/threadingconcurrency-vs-paral...
Its a worthy read and may change your mind at least a bit. Though overall, I agree that not all developers benefit from learning functional programming languages as the ones specified, I truly believe that most developers would benefit greatly. Anyway, if I find the article I'm telling you about i'll post it as well.
EDIT: I believe this was it: http://ghcmutterings.wordpress.com/2009/10/06/parallelism-co...
EDIT 2: I also believe that most of these languages actually promise more. For example, one of the biggest promises Haskell gives is no side effects. Though this does have a mayor implications for concurrency/parallelism it also (in my opinion) provides safer, cleaner and easier to maintain code. (It does take a memory hit, I'll admit to that, but I personally prefer that safety). Erlang's biggest promise I believe is its fault tolerance. And over all, I honestly believe that functional programming puts you in a different mindset and once you get used to it (I'm still learning, but even then I find it mind opening) you see things clearer. But when it comes down to it, its impossible to be objective about this. However, I will objectively say, everyone should try at least one functional language, just to give you a different view of things :D .
(thread on ghcmutterings post) http://news.ycombinator.com/item?id=2457307
Is it impossible? A "Failed Dream"? http://weblogs.java.net/blog/kgh/archive/2004/10/multithread...
'there is a fundamental conflict here between a thread wanting to go "up" and other threads wanting to go "down"'
Can anybody explain that fundamental conflict?
Is that what you were asking about, or is there something subtler I'm missing?
An event queue just makes the queue the one and only synchronization point.
Though the possibility that some relatively small and clever bit of code could wrap STM around a GUI toolkit is not out of the question.
Really? I think that's a failure of the author's imagination. Nearly every web application that I've worked on since 2003 has had a significant amount of concurrency involved in handling each request.
Just having futures to keep database access would help, although I'm not sure how that would be possible with Rails' lazy querying.
All that said, the core Ruby guys are probably better off spending their time on performance enhancements than removing enough of the GIL to allow that kind of multithreaded shenanigans.
In fact, if so inclined, you can model your distributed architecture on top of language-level (or OS-level) parallelism; message passing can be considerably cheaper when you can rely on simple shared memory mechanisms.
Parallelism in the language environment allows you to make better use of the hardware you have. In a server environment, there's a fixed power utilization cost for each machine, and a per-CPU core power cost. It's cheaper and more efficient to scale up cores than it is to scale horizontally across machines. In fact, the more efficient you are, the longer you can put off the complexity of large-scale horizontal scaling.
In a mobile environment, the equation is different -- you can't just add more mobile devices to scale horizontally. The device has X amount of cores, period. If you don't use them, your application's performance will not be up to par with other applications.
And if you have to endure the pain of writing a distributed app, why would you layer another level of concurrent complexity underneath it?
I disagree. At my last job I exclusively made internal web apps that could always live on a single server. They never needed to scale beyond the cores on 1 box, but most benefited from using all cores on that box.
It's not THE easy way. It's actually the harder way, but in some cases, like giant public web apps, you have to do the hardway anyway.
Managing a work queue using java.util.concurrent in process is far easier than managing many processes and coordinating across something like redis.
The ability to stretch an application across more than one machine is obviously essential to the modern world. The internet is by definition a kind of distributed computing system.
Some languages have features that promote a particular kind of parallel programming. But they are not suited to every task and thats ok!
Let's take the example of a web application, be it in PHP, Java, etc.: What happens if your user has multiple browser tabs open to your application and submits concurrent requests that modify the user's session? With multiple cores, it is much more likely that the concurrency bugs in your application will be exposed. Languages like Clojure help you explicitly reason about shared mutable state.
Isn't map/reduce kind of drawn from the functional paradigm?
"The problem is simple: while the storage capacities of hard drives have increased massively over the years, access speeds—the rate at which data can be read from drives— have not kept up. One typical drive from 1990 could store 1370 MB of data and had a transfer speed of 4.4 MB/s,§ so you could read all the data from a full drive in around five minutes. Almost 20 years later one terabyte drives are the norm, but the transfer speed is around 100 MB/s, so it takes more than two and a half hours to read all the data off the disk.
This is a long time to read all data on a single drive—and writing is even slower. The obvious way to reduce the time is to read from multiple disks at once. Imagine if we had 100 drives, each holding one hundredth of the data. Working in parallel, we could read the data in under two minutes. Only using one hundredth of a disk may seem wasteful. But we can store one hundred datasets, each of which is one terabyte, and provide shared access to them. We can imagine that the users of such a system would be happy to share access in return for shorter analysis times, and, statistically, that their analysis jobs would be likely to be spread over time, so they wouldn’t interfere with each other too much."