7 ms·
I can’t speak to swift, but in experience with many other langs and runtimes I will say that single-threaded business logic by default is still the only sane ch
by klabb3 1y ago
I can’t speak to swift, but in experience with many other langs and runtimes I will say that single-threaded business logic by default is still the only sane choice even today. There are exceptions both on client and server side, but you get so incredibly far with one thread, while eliminating so many potential bugs, that it’s borderline whether parallelism should even be exposed to application developers at all.
Even in Go which has my favorite parallel concurrency model, there are many footguns and needless walking on eggshells for business logic. You can still offload IO and bespoke compute to other threads when it makes sense. This view isn’t a panacea, but damn close for the 99% of use cases.
Coincidentally I also think the early success of JavaScript an largely be attributed to single-threaded run-loop and callback-oriented concurrency. Even on the server JS is still holding strong with this limitation, and that’s despite all the other limitations and insanity of JS.
- monkeyelite 1y agoAbsolutely - the idea of threads haphazardly interacting, like 2002 Java, is a terrible default assumption for designing languages and libraries. It's not even clear the perf gains are great. Everything locking all the time has killed a lot of performance.