|
|
|
|
|
|
by onion2k
3767 days ago
|
|
|
Personally, I find there's a ton of things that ought to be concurrent but aren't. What sort of things? I've been writing web software for ~20 years, and the vast majority of things that I've made boil down to "request comes in > validate input data > transaction to database > check transaction worked > write a response". Concurrency has never really been a problem, or even something I've wanted. |
|
|
Just this week I met with a friend who wanted an app for community meetings that would let people express their preferences in real time, changing their expressed opinions as discussion happens. That way everybody could see how the consensus was shifting in response to discussion without people having to say it out loud.
I quickly whipped together a prototype, and I intentionally didn't use a database because I wanted this to be dynamic. Whenever one person changed something, everybody else needed to see it immediately. That's very easy in a context where you have all your data hot in RAM in one process with easy concurrent-ish access to it: you have a bunch of observer objects that get notifications each time you change something. In database-land, it's a pain.
And it works for me at size as well. Years ago I led a team where we were building a new web product. We were big on test-driven development, and databases are a notorious pain point. We started out without one, figuring that we'd pull one in when we needed it. We ended up never needing one. Our system had incredibly low rendering times (<5ms, even on 2005 hardware), and its 1800 unit tests ran in a couple of seconds. Starting with concurrency saved us so much development pain.
Another common example of where concurrency is valuable is in notifications. Quora and Facebook both have excellent notification systems: dynamic and instantaneous. Twitter's are much rougher, and it's clear they've put a lot less thought into concurrency.
Games, of course. Imagine trying to build agar.io without concurrency. Or look at Google Docs: concurrency is at the heart of what makes them valuable in an office setting.
There's nothing wrong with CRUD apps. There's nothing wrong with all the mainframe batch-processing apps that preceded them, either. But there's more that we can do.