 |
| Ask HN: On Rob Pike's Concurrency is not Parallelism? | ||
| recommended by 1 user | 2012 | 51 points by lazydon | concurrency | original thread | | ||
This is regarding slides by Rob Pike with above title. Every time I go thru this I feel like a moron. I'm not able to to figure out the gist of it. It's well understood that concurrency is decomposition of a complex problem into smaller components. If you cannot correctly divide something into smaller parts, it's hard to solve it using concurrency. But there isn't much detail in slides on how to get parallelism once you've achieved concurrency. In the Lesson slide (num 52), he says Concurrency - "Maybe Even Parallel". But the question is - When and How can concurrency correctly and efficiently lead to Parallelism? My guess is that, under the hood Rob's pointing out that developers should work at the level of concurrency - and parallelism should be language's/vm's concern (gomaxprocs?). Just care about intelligent decomposition into smaller units, concerned only about correct concurrency - parallelism will be take care by the "system". Please shed some light. Slides: http://concur.rspace.googlecode.com/hg/talk/concur.html#title-slide HN Discussion: http://news.ycombinator.com/item?id=3837147 | ||
| One user recommended this thread. What they said: |
| ignoramous Jul 4, 2015 | on: Ask HN: Why Node.js and for which type of App? | context |
| Also recommended by people who recommended this: | ||
| 1. | “Did you win the Putnam?” (comment) | |
| recommended by 50 users | 2007 | sanj on: The Equity Equation | original thread | | ||
| 2. | “We ended up using eSupport (which is a complete piece of shit)” (comment) | |
| recommended by 1 user | 2010 | megamark16 on: Zendesk raises their prices 60%-300%, users predictably… | aged well | original thread | | ||
| 3. | The LMAX Architecture - 100K TPS at Less than 1ms Latency (martinfowler.com) | |
| recommended by 2 users | 2011 | 210 points by koevet | original thread | | ||
| 4. | How to crawl a quarter billion webpages in 40 hours (michaelnielsen.org) | |
| recommended by 2 users | 2012 | 323 points by cing | original thread | | ||
| 5. | Parallelism and concurrency need different tools (yosefk.com) | |
| recommended by 2 users | 2013 | 166 points by mhd | original thread | | ||
| 6. | So You Want to Write Your Own CSV code (tburette.github.io) | |
| recommended by 2 users | 2014 | 158 points by Monkeyget | original thread | | ||
NodeJs' non-blocking IO makes it a great choice for near real-time communication, like streaming editors, messaging, reacting to high freq events (like metrics). See: http://socket.io, http://en.m.wikipedia.org/wiki/Surespot and https://github.com/etsy/statsd
It is also great when you want to prototype a REST backend, and get it up and running in no time. The simplicity of javascript along with nodejs' module ecosystem make it a breeze (Ruby equivalent would be Sinatra).
What nodejs isn't good at is, parallelism. Concurrency is handled for you for free by the underlying libuv eventing framework. Pseudo-parallelism is achieved using 'clusters' but communication between node processes is costlier than in other languages that support parallelism out of the box.
Read https://news.ycombinator.com/item?id=4305486 for aphyr's excellent commentary on clojure vs nodejs (you can also find Ryan Dahl defending nodejs in a few cases there)