> Multi-threading for imperative code is a big mistake, which breaks isolation and results in lock-hell, context-switching nightmare and layers of unnecessary complexity which is impossible to reason about.
Go is multithreaded and imperative. Sure, it has some nice concurrency features to help you untangle it, but all of the dangers of shared memory multithreading is right there.
…as is Swift with NSOperation/GCD. Apple's process isolation tech (XPC) is built upon their multithreading tech (GCD). The two are complementary, not antagonistic.
Doing multithreading on a runtime with automatic reference counting gc and expecting performance is nuts. Every reference assignment is a potential write contention.
It is possible to do it, even sensible when you need it for GUIs for example. Just don't expect it to use the hardware in a sensible manner.
Go is multithreaded and imperative. Sure, it has some nice concurrency features to help you untangle it, but all of the dangers of shared memory multithreading is right there.