Comment by Jabbles | Hacker News Reader

Comment by Jabbles | Hacker News Reader

Parent Full thread

This article isn't bad... but it misses several important points of Go. I also note the article is 9 months old. In the hope that my criticism will be taken as constructive, with apologies for not writing detailed explanations:

1. Goroutines are not threads

2. type inference allows you to elide types in var declarations: var host = flag.String(...

3. Go's convention is to use camel case, not underscores.

4. Calling os.Exit all over the place is unusual imo - it may be better to panic().

5. fmt.Fprintf exists os.Stderr.WriteString(fmt.Sprintf...

6. An explanation of why the standard log package isn't suitable would be nice, although I see the format used is slightly different.

7. Ignored errors when writing. Why do you wish to sync at every packet?

8. Massive race condition by re-using b. Line 62 overwrites b. b is then passed to c.logger (68) and c.binary_logger (70) for them to process asynchronously. c.logger is then passed another byte slice (72), which forces it to finish using b. c.binary_logger is not passed anything else, allowing it to delay until the next time something is sent on that channel, which would be after b is overwritten by the next packet. I think that simply moving line 58 to between 61,62 would fix this.

The author has not quite grokked the concept of "don't share memory". b is shared, and undefined behaviour results :(

Your critique (which seems valid; I'm not a Go expert) does not exactly instill confidence in the Pragmatic Programmer (PP) brand.

When I read material from them, I would have assumed I'd be seeing "idiomatic code from an expert"...not "hey, I'm a newbie hacking my way around in a new language, here's what I typed out in 2 days of playing with it".

I mean, I understand they're big on the "learning a new language on a regular basis thing", but when I see code published like this, specifically from their brand, I go into it thinking "okay, this should be high quality, idiomatic code."

...guess I'll be more careful with that assumption.

(EDIT: If this is just some personal blog, I guess I'd understand; I saw "magazine" in the URL and got the impression this was published as part of their magazine/PDF series.)

Yes, it is part of their magazine: http://pragprog.com/magazines/2012-06 (also available in PDF, epub and mobi from http://pragprog.com/magazines)

> 1. Goroutines are not threads

They are not kernel-level threads, but they are threads in every other meaningful sense; they have their own stack and execution pointer, and data operations in goroutines are not guaranteed to be atomic with respect to other goroutines.

While the current official Go implementation never preemptively schedules goroutines except on I/O and on runtime.Gosched(), nothing in the spec precludes a different, more kernel-thread-like scheduling system.

Using the term thread interchangeably with goroutine causes confusion, otherwise why bother having a different name for them in the first place?

Because there already exists a perfectly fine name for them: green threads (as opposed to operating system threads), using M:N threading.

http://en.wikipedia.org/wiki/Green_threads http://en.wikipedia.org/wiki/Thread_(computing)#M:N_.28Hybri...

They are just a subclass of threads.

> I think that simply moving line 58 to between 61,62 would fix this.

Doing that would erase the whole benefit of allocating a static array in the first place (you really don't want to be allocating memory for every packet that comes through). The funny thing is the author correctly handles this type of synchronization problem elsewhere, see lines 97-100. The right thing to do is to wait for acknowledgement from both loggers before reusing shared memory, but that sort of defeats his broader argument: if you are explicitly guarding every shared memory access with a barrier, then you might as well have been using any shared memory language besides Go. Buffered channels in both directions used to implement barriers are every bit as error-prone and complex as using a reader-writer lock explicitly.

> Doing that would erase the whole benefit of allocating a static array in the first place (you really don't want to be allocating memory for every packet that comes through).

The benefit is dubious. Performance is unlikely to be important in a single-connection logger. My advice is to lean on the garbage collector. Allocate away.

Buffered channels are certainly more complex, but if you're never sharing memory, shouldn't hurt you.

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.)

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