Hacker News Reader

Comment by abecedarius | Hacker News Reader

How are goroutines not threads? Do you mean because it's possible for them to communicate without shared mutable state?

Edit: Oh, apparently you all mean OS threads. So say so. (For example, in Haskell they're called threads without any implication that each one is an OS thread. Haskell's not unusual that way.)

View on HN

Go schedules its own 'threads' (goroutines) to run on one or many (OS) threads.

In this case, threads refer to not-a-process units of execution in an operating system. For whatever its worth, Wikipedia defines threads as:

  the smallest sequence of programmed instructions that 
  can be managed independently by an operating system
  scheduler.

I think that's also the commonly accepted definition: that threads are related to the OS scheduler.

The notion that goroutines aren't threads seems to exist primarly because Golang also makes use of OS-native threads in order to schedule goroutines, and so needs to draw a distinction in order to explain how the runtime works.

But that's just a detail. In reality, goroutines are threads; they're just userland, non-preemptive threads. Similar constructions have been available, even to C programmers, for well over a decade (and probably much longer).

> Similar constructions have been available, even to C programmers, for well over a decade (and probably much longer).

Of course they aren't called threads there, either (probably for the same reason as they aren't called threads in Go)

Sure they are. For instance, Gnu Pth.

Programming language support for threading predates direct operating system support (at least in mainstream operating systems) by a lot of years, from what I can tell.

The ones I've used have just been called coroutines, though I suppose I haven't used any that function as drop-in replacements for threads like Pth

It is really common for Go programmers (I've even seen members of the Go core team do it) to say 'thread' when they mean goroutine. It is important to recognize there is a difference, but calling someone out for saying 'thread' when they mean 'goroutine' is pedantic bullshit on the order of calling someone out for calling a class method in an OO language a function.

Oh I'm not (I didn't meant to?) calling parent out, I was just trying an explanation.

Sorry if where I replied made this confusing, I wasn't really talking about you nor even did I mean it as a personal thing against Jabbles who did the actual "calling out" of mixing threads and goroutines.

As I mentioned, knowing the difference is actually a good thing so your post is really helpful. My point is just that the two concepts are so intertwined and overlapping that I think it is silly for someone to correct someone's terminology on this (as Jabbles did, though I admit I share some of his(?) other concerns with the OP), particularly in cases where it is clear the person is pretty familiar with goroutines and how they operate.

Thanks for explaining -- I really couldn't tell what distinction they meant.

http://en.wikipedia.org/wiki/Green_threads

Its not a commonly accepted "definition" - threads are a general concept that encompass several different forms of concurrency. It may be commonly assumed that the term "thread", in absence of any other qualifier, refers to OS-level threads, however even that is context dependent. The Wikipedia page introduction is poorly written.

However the more salient point here is the OP was either being lazy by saying "goroutines are not threads", or actually doesn't understand the concept of lightweight threads. Along the lines of Rob Pike's own explanation on the matter, he maybe should have said "goroutines provide concurrency but not parallelization".

> "goroutines provide concurrency but not parallelization"

If they are multiplexed on several threads, then they also provide parallelization.

> that threads are related to the OS scheduler

It is actually common for people to talk about green threads (http://en.wikipedia.org/wiki/Green_threads) in the same vain as OS threads.

Thread usually means an in-process concurrency construct controlled by calls to the operating system. A goroutine is managed by the Go runtime.

It's an important distinction between using many (read: hundreds) of OS threads in a single process isn't performant, while using hundreds or even tens of thousands of goroutines is just fine.

Goroutines are green threads[1], and thus are threads, just like Ruby 1.8s threads are threads.

Also, you can easily run 10s of thousands of kernel threads (provided you decrease the threads' stack size).

1: http://en.wikipedia.org/wiki/Green_threads

goroutines are not threads because thread means something and goroutine means something else.

Reply on news.ycombinator.com