I’ve always hated object oriented multi threading. Goroutines (green threads) are just the best way 90% of the time. If I need to control where threads go I’ll write it in rust.
If I have to put a thread object in a variable and call a method on it to start it then it’s OO multi threading. I don’t want to know when the thread spawns, I don’t want to know what code it’s running, and I don’t want to know when it’s done. I just want shit to happen at the same time (90% of the time)
I’ve always hated object oriented multi threading. Goroutines (green threads) are just the best way 90% of the time. If I need to control where threads go I’ll write it in rust.
nothing about any of those libraries dictates an OO approach.
Unless it’s java.
Meh, even Java has decent FP paradigm support these days. Just because you can do everything in an OO way in Java doesn’t mean you need to.
If I have to put a thread object in a variable and call a method on it to start it then it’s OO multi threading. I don’t want to know when the thread spawns, I don’t want to know what code it’s running, and I don’t want to know when it’s done. I just want shit to happen at the same time (90% of the time)
the thread library is aping the posix thread interface with python semantics.