Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Beauty of Concurrency in Go

pragprog.com

Post reply on HN
Print view View original

71–80 of 95 posts

Re: The Beauty of Concurrency in Go

#71

Post by justinhj »

lobster_johnson wrote: post #53
Jabbles wrote: post #8

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 o…

> 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 precl…

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

Re: The Beauty of Concurrency in Go

#72

Post by michaelfairley »

lbarrow wrote: post #35
abecedarius wrote: post #30

Earlier quoted context omitted.

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

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

Re: The Beauty of Concurrency in Go

#73

Post by mseepgood »

smegel wrote: post #64
AYBABTME wrote: post #41

Earlier quoted context omitted.

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…

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 "goroutin…

> "goroutines provide concurrency but not parallelization"

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

Re: The Beauty of Concurrency in Go

#74

Post by kragen »

laureny wrote: post #24

> > Notably, if a package is included but not used, Go treats this as an error and enforces removing unused declarations A good illustration that the Go designers didn't think their ideas through. This is a real pain in the butt when you are writing code and regularly commenting in and out sections of code while you are testing things. And every time you do this, you need to remove or restore the imports. And since G…

Jesus Jumping Blue Christ, why is it that every time Golang comes up in any type of discussion, there's always someone out there who complains that Go is horrible because it doesn't implement their favorite pet non-mainstream language features, which is obviously because the Go designers were inexperienced newbies with only 50 years of experience designing groundbreaking software, and therefore lacked your deep insights into how things should really be organized?

Re: The Beauty of Concurrency in Go

#75

Post by microtonal »

justinhj wrote: post #71
lobster_johnson wrote: post #53

Earlier quoted context omitted.

> 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 precl…

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.

Re: The Beauty of Concurrency in Go

#76

Post by furyofantares »

tptacek wrote: post #60
furyofantares wrote: post #59

Earlier quoted context omitted.

> 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

Re: The Beauty of Concurrency in Go

#77

Post by pjmlp »

jbarham wrote: post #68
WayneDB wrote: post #67

Earlier quoted context omitted.

Maybe they did think it through, but their conclusion reveals some inexperience. It's impractical on many levels. Thus the need for kludgy solutions like blank identifiers. I'd rather see a strict mode or some other type of compiler flag.

Maybe you don't realize that "they" includes Ken Thompson himself... You may disagree with the Go design team's decisions, but it's amusingly absurd to accuse them of inexperience.

Just because he created UNIX, does not make him right in every technology decision he takes.

Re: The Beauty of Concurrency in Go

#78

Post by redbad »

lobster_johnson wrote: post #51
dlsspy wrote: post #45

Earlier quoted context omitted.

> but I think " And what looks even better: defer close(doneChannel) (it's also syntactically correct -- you ca't just have a defer block without a function invocation)

Closing the channel is fine, I suppose, although the supervising goroutine now looks a bit odd: select { case _, _ := It's so implicit that you pretty much have to add a comment to the effect of "this will trigger when the channel is closed", whereas the "case Also, I rather prefer the supervising goroutine to "own" the channel, so it should be the one to close it. > you ca't just have a defer block without a functio…

    > the supervising goroutine now looks a bit odd:
This is totally valid:

    select {
    case

Re: The Beauty of Concurrency in Go

#79

Post by pjmlp »

laureny wrote: post #69
jbarham wrote: post #68

Earlier quoted context omitted.

Maybe you don't realize that "they" includes Ken Thompson himself... You may disagree with the Go design team's decisions, but it's amusingly absurd to accuse them of inexperience.

> Maybe you don't realize that "they" includes Ken Thompson himself... You may disagree with the Go design team's decisions, but it's amusingly absurd to accuse them of inexperience. Not really, if anything, Go shows that its designers have a lot of inexperience when it comes to modern language design. Go would have been a kille language in the late 90's but it seems to ignore everything that we've learned about lang…

Quite true, every single feature can be traced back to 80's and 90's languages that for whatever reason did not manage to become mainstream.

Maybe one could make a table stating the language feature and which language provided it for the first time.

Re: The Beauty of Concurrency in Go

#80

Post by redbad »

lobster_johnson wrote: post #55
jussij wrote: post #44

Earlier quoted context omitted.

> good illustration that the Go designers didn't think their ideas through. This is a real pain in the butt when you are writing code and regularly commenting in and out sections of code while you are testing things. How could it be that bad? It's as simple as a compile, a click on the error message and adding a one line comment. No worse than the standard practice of making sure your c/c++ code compiles without warn…

People develop at different speeds. For me, anything like this that slows me down and interrupts my flow with 3-4 seconds of "click on the error message and add a one-line comment" is incredibly annoying. Development has several modes. One mode is "hacking", just hashing out what you want until it works and is elegant enough as a solution, perhaps changing your mind frequently when you see how it works in practice. A…

    > Development has several modes. One mode is "hacking",
    > just hashing out what you want until it works and is 
    > elegant enough as a solution, perhaps changing your mind 
    > frequently when you see how it works in practice. 
    > Another is "polishing", carefully annotating, cleaning 
    > up, documenting, burning off loose threads, making sure 
    > the test coverage is top notch, etc.
    > 
    > The problem is that Go's compile-time strictness lends 
    > itself to the "polishing" phase, but not to the 
    > "hacking" phase.
When I write Go, or indeed in any programming language, I generally start with, and stay in, what you call the "polishing" phase. Experimentation occurs in my head, and what makes it through to my fingers is the polished form of that experiment.

That Go is not conducive to writing sloppy (or "hacking" phase) code is I think only a good thing.

Post reply on HN