Comment by dspillett | Hacker News Reader

Comment by dspillett | Hacker News Reader

Parent Full thread

3. Multi-threaded programming will fall out of favor by 2012. Not really. We are already in the multicore age, and it will only get moreticore.

A lot of things server-side are moving back towards multiple processes rather than threading, driven by "cloud" based scaling: if you code is designed to handle being spread over many nodes then why complicate things by having two concurrency models on the go at once (threads at host level, multiple processes spread over the hosts)?

8. Someday I will voluntarily pay Google for one of their services. You don't say? They are one of the biggest players out there, even if they are not primarily known for payware but still.

While most individuals just use the free service level, you can pay for the use and support of Google Docs and some groups do. Same with Google Drive: while many won't need more than the free 5Gb it costs per month for more than that (if you are using it to store music and video 5Gb isn't hard to fill).

10. In five years' time, most programmers will still be average. This makes no sense, but anyway, we are getting better. Slowly though, version control, more languages, testing is infiltrating even some dumber dev companies too.

It makes perfect sense in a pointless way: most of everyone are average at everything. As people get better/worse the average shuffles around too. If he is talking about following best (or at least good) practises I can tell you thre are a lot of average people out there despite the tools avaliable to make it easier to do things right.

> (threads at host level, multiple processes spread over the hosts)

Concurrent programming isn't all "jump off a cliff into the atomic<T> and mutex lock sea and worry about deadlock or run everything in serial".

There is a middle ground where you take apart the easily discretized parts of your task at hand, that have little or no communication between them, and thread those. For example, if you have a system to scrape a user profile, processing the personal information, hobbies, and pictures in separate threads only requires sending work to threads in a thread pool saying scrape X. That X gets scraped, database calls are asynchronous and work up to the thousands of workers, and you don't even need to wait - pass off the profile, let the threads run and wait for a new connection.

Threaded parallelism only becomes dangerous when you start using shared data. That is where you need to ask if its worth the cost. You shouldn't be afraid of threading entirely just because you can back yourself into deadlock hell if you don't plan ahead.

I wasn't meaning to suggest it was (or should be) considered dangerous: just that supporting two concurrency models it that same time is a complication many would prefer not to bother with unless their application really needs the efficiency boost threading may offer within a single process on a single node. Unless you can justify working with both due to some measurable and significant efficiency gain or don't need multi-host scaling you go with the option you have to have (multiple processes).

Supporting both (multiple processes for multi-host scalability, threads for speeding up CPU intensive operations and such) might not be much more hassle, but it is at least some more hassle.

When people complain about threading, they are thinking about shared-mutable-state threading.

Obviously we will never have single-threaded systems, they would be blocking all the time.

Reply on news.ycombinator.com