Yes, and blocking is usually faster. It's entirely correct for code to be blocking by default because it shouldn't be assuming that there is any interactivity going. If I want to make a console utility that scans some files then I don't need to worry about whether a UI is being repainted. So I completely agree with treating asynchronous as the odd case, and blocking as default which is not what JS does but it's what e.g. .NET IO does, and if you want to have a responsive UI together with IO you can often just combine a processing thread that blocks, and a UI thread that doesn't. The case where you'd want proper async IO is when you want to wait for 100 IO tasks each with unknown duration, where each is really async at the OS level anyway but your IO API doesn't expose that. Doing 100 threads isn't really a good option.
