Go's lightweight threads do not require cooperative multitasking in the traditional sense. In Go, lightweight threads are preempted by the runtime whenever an o

Go's lightweight threads do not require cooperative multitasking in the traditional sense. In Go, lightweight threads are preempted by the runtime whenever an operation that can block is made (IO, channel send/receive, system calls, etc.). However, lightweight threads can hog the CPU, and in that sense, they must be cooperative. But this rarely shows up outside of pathological cases in practice. More importantly, I wasn't talking about scheduling. I was talking about lightweight threads. They are also commonly known as: goroutines, green threads, fibers, user space threads, etc. This has a dramatic effect on the style of concurrent programming, as spawning a light weight thread is cheap relative to spawning an OS thread. Joe Armstrong explains [1] things better than I can: Processes in Java or C# are pretty much like the objects in the flawed object system which we described earlier - you can’t have many of them, and if you have more than a few hundred processes the system will start misbehaving and to do any real work with them you have to write your own scheduler and start combining multiple threads of control into single processes. All of this gives concurrent programming a bad name - and would probably make any sane person think that concurrent programming was a difficult and should be avoided whenever possible. The opposite is true. And: In Erlang processes are *light weight*. This means that very little computational effort is required to create or destroy a processes. Light-weight processes in Erlang are one to two order of magnitude lighter than operating system threads. Not only are Erlang processes light-weight, but also we can create many hundreds of thousands of such processes without noticeably degrading the performance of the system (unless of course they are all doing something at the same time). In Go, "goroutines" are analogous to "processes" in Erlang in the above excerpt. My point here was that Go solves the concurrency problem much differently than Java does, to a point where Go is much better suited to write concurrent programs than Java is. Joe Armstrong's argument in his paper applies pretty well here. I'm not really sure what is to be gained by debating over whether Go was "intended" to be in the same domain as Java. I've used Go to solve problems that I might have otherwise solved in a variety of other languages (C, Haskell, Python). Had I ever been a Java programmer, I'm sure that would have been in the list too. Experience in speaking with other Go programmers leads me to believe that I am not unique in this regard. [1] - "Concurrency oriented programming in Erlang", 2003. https://guug.de/veranstaltungen/ffg2003/papers/ffg2003-armstrong.pdf https://guug.de/veranstaltungen/ffg2003/papers/ffg2003-armst...