But should they be writing highly concurrent software, without thinking bloody hard first I mean?
I can see this being the next Big Data or NoSQL 'must have' bandwagon.
I can see this being the next Big Data or NoSQL 'must have' bandwagon.
Yes, by necessity. We're 15 years after the end of the race for frequency, and the end of moore's law is getting ever closer. Concurrency and parallelism are becoming table stakes for both reactivity and performances. This means making them reliably usable and composable is getting more and more important.
>> But should they be writing highly concurrent software, without thinking bloody hard first I mean?
> Yes, by necessity.
So we should not think about it first, just do it?
And not consider whether there are better solutions such as checking we're using the right algos or cache-aligning our accesses or using a probabilistic filter before hitting the DB or..
Edit: no offense intended, the original question was meant as a rhetorical device to warn against dumbness and bandwaggoning. I am sure you too would not plough in unthinkingly but I'm afraid our industry's reaction is too often to do just that and it's such an expensive mistake, repeated over and over. It's a thoughtless jumping ahead that will lead to slower software, not faster. And buggier.
It's mostly for io-intensive workloads. And for nicer debugging experience compared to callback hell. Nothing to do with NoSQL, or right algos, or cache-aligning when you just need to do 10M http requests/db-inserts/rpcs as fast/efficient/nicer-dev-experience as possible.
It is much easier to bake concurrency and parallelism from the start than to retrofit it in an existing sequential project, even more so as it avoids sub-optimal patterns.
> And not consider whether there are better solutions such as checking we're using the right algos or cache-aligning our accesses or using a probabilistic filter before hitting the DB or..
Why are you declaring that those are incompatible with concurrent programs, exactly?
Structured concurrency is about managing concurrent operations with less cognitive overhead. The most common case being handling stuff like cancelation in a reasonable way. These problems are relevant everywhere I/O is relevant which I would wager is most programs people write and interact (see I/O!) with on a daily basis.
Should you be using concurrency without thinking? Well ofcourse not but if you aren't using it there is a very good chance you are "doing it wrong" for which wrong is some approximation of providing a poor user experience or writing software that makes inefficient use of resources and/or wall-clock time.
On the topic of highly parallel software however I do mostly agree, there is a few things that benefit from highly parallel architectures but generally it's going to make whatever you are doing way harder. Some exceptions are forms of limited parallelism like making use of SIMD in tight loops, this is great because it doesn't require you to make your program logic parallel, data operations just execute in parallel on multiple inputs on a single thread.
Anyways. My point is almost all programs need some form of concurrency whilst most don't need parallelism. Concurrency is hard and has a multitude of competing solutions (async/await, threading w/monitors + atomics + friends, CSP) while parallelism is generally even more difficult but has much more limited solution space whist having some overlap in terms of abstraction layers.
Very good point, I hadn't got myself straight on that, thanks
If you're writing C, you're going to have a bad time, but we've built some really great tools with modern type systems that make it far easier to treat concurrency as a thing that you can just rely on being able to safely use.
When you're using a language with misuse-resistant core primitives, like structured concurrency, and like Rust's Ownership, Mutex, and Send/Sync traits, it really is a meaningfully different programming experience. You make small use of concurrency all the time, because you just know by default without investing any time at all to check that you haven't made any kind of dumb mistakes.
When you use concurrency all the time, and get instant feedback from the compiler describing the precise data dependency that would make your idea a dumb choice, you get a ton of real direct feedback to learn about how to use concurrency correctly, and what designs it's a good fit for.
I agree that concurrency isn't a replacement for checking for algorithmic improvements, profiling and tuning your memory access patterns, using probabilistic filters, caching, etc. But just like how you can just unthinkingly drop a probabilistic filter before hitting a DB, I think you can and should be able to just unthinkingly spread a bunch of work out across a bunch of cores. This should be a simple, obvious, normal thing that people do by default whenever they care at all about performance, and it can be with good safe tools.
I imagine folks writing Web software, UIs and heavy desktop applications will also benefit from these developments but those areas are out of my core expertise so I can't speak to exactly how useful structured concurrency will be for them however I can see very clear applications for my domain.
There is a middle ground before highly concurrent, and it's "I don't really care what you do, but please use the cores i can have and don't block the main thread thank you"
Structured concurrency just means that i can both not really care where it goes, be generous on coroutines (I have only screwed up once, and that was by having hundreds of threads deadlocking on database access. Otherwise, you most likely have... 50 running at worst?). Structured concurrency also means that the moment i drop out of a screen, every computation launched in the context of this screen and not a higher level is just dropped immediately, meaning it runs just when I need it to
Actually not just juniors I also do it sometimes but shhh