I think the title is unnecessary click-baity, because there are some relevant truths to it.
Most relevant truth us, that a lot of applications won't need async since they are not large enough, not IO bound etc..
I think one of the misconceptions in this article is, that the author arguments that you need to be an Amazon or google to benefit from async. This is not completely wrong but, as a software developer in the embedded system industry that I am, I must say it is also very relevant for embedded systems.
If someone read the article and is unsure about async, I can recommend these two articles that provide insights "from the other side" these means devs that actually find async relevant and beneficial:
Finally regarding the introduction of async APIs and abstractions into any code base:
Creating an async application or sync application is an architectural decision. And since architecture is the sum of all decisions that are hard to change (I think this is from Martin Fowler) thus decision - async or sync - is hard to change and one must live with it.
Yes, there are languages like Go or Erlang that resolve this async vs. sync problem, they come at a cost (having a runtime, at least Go has one afaik, I no nothing about Erlang). And choosing a particular language is also an architectural decision and hence hard to change.
I think the article is ok, and yes I read it ;)
I think the title is unnecessary click-baity, because there are some relevant truths to it.
Most relevant truth us, that a lot of applications won't need async since they are not large enough, not IO bound etc..
I think one of the misconceptions in this article is, that the author arguments that you need to be an Amazon or google to benefit from async. This is not completely wrong but, as a software developer in the embedded system industry that I am, I must say it is also very relevant for embedded systems.
If someone read the article and is unsure about async, I can recommend these two articles that provide insights "from the other side" these means devs that actually find async relevant and beneficial:
https://notgull.net/why-you-want-async/
https://without.boats/blog/why-async-rust/ The article from boats is absolutely worth it. Even if you are an async sceptic.
Finally regarding the introduction of async APIs and abstractions into any code base:
Creating an async application or sync application is an architectural decision. And since architecture is the sum of all decisions that are hard to change (I think this is from Martin Fowler) thus decision - async or sync - is hard to change and one must live with it.
Yes, there are languages like Go or Erlang that resolve this async vs. sync problem, they come at a cost (having a runtime, at least Go has one afaik, I no nothing about Erlang). And choosing a particular language is also an architectural decision and hence hard to change.