Hacker News Reader

Comment by thallukrish | Hacker News Reader

My experience is, single threaded execution and being able to replicate that with local data for each instance and remote lookup at a fine grained data level when needed, is a more easier way to maintain the code. Cocurrency and all those synchronisation is damn hard to code and debug.

View on HN

In my opinion it's overhyped. I'll probably take point hits for claiming it, but so be it. Let the truth ring.

Why copy techniques meant for Netflix and Facebook when your org or app is most likely 1/1000th their size. Phallic size jealousy at work.

Most concurrent and parallel work can and should be done on a true-and-tried RDMBS for most orgs and apps. Use transactions/rollbacks properly and let the RDBMS manage most the grunt work instead of reinvent the wheel in app code.

K.I.S.S. and use-the-right-tool-for-the-job.

If you want extreme scale, most data in memory, such as a search engine processing millions of documents running data pipelines, then RDBMS isn't the way to go. For other MVC types, for a reasonable scale out, straight forward models with RDBMS should do.

Note that existing RDBMS are gradually adding and improving their text search engines. Of course there will always be specialized situations that need dedicated high-end text search engines.

It has tradeoffs and can easily result in higher complexity, eg if you need a shared cache to minimize latency/memory.

I like the attitude the article takes. To successfully use concurrency, you should understand the tools available to you and their tradeoffs so you can make the right decision for your requirements.

When one has nice tooling like Visual Studio graphical debugging, not so much.

Its it?

https://marketplace.visualstudio.com/items?itemName=AdamWulk...

Reply on news.ycombinator.com