-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Added go for routines - Correct doc #571
base: master
Are you sure you want to change the base?
Conversation
@@ -24,7 +24,7 @@ func pong(pings <-chan string, pongs chan<- string) { | |||
func main() { | |||
pings := make(chan string, 1) | |||
pongs := make(chan string, 1) | |||
ping(pings, "passed message") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because the channels are buffered, the go
statements aren't necessary here. They won't hurt, but one may wonder if they're needed.
I suppose the channels could be made unbuffered and go
keywords added, this would have a similar effect
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes okay, it's just that I thought without go
the code just becomes synchronous, so we're guaranteed that ping
will happen before pong
before the main exiting. But with adding go
, it's the channels directions, especially receiving from channels that enforces the order of execution (ping
then pong
then the main routine exiting). So, I thought adding go
really made clear that thanks to blocking when trying to receive from channels, we get the correct order of execution.
But I guess here the example was mostly about the fact that we can pass specific channel directions as function parameters. So, the underlying example matters a bit less.
Let me know what you'd prefer, I can remove the go
if you think it's better this way, no worries :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah let's just remove the go
s
@@ -17,9 +17,9 @@ func main() { | |||
var s []string | |||
fmt.Println("uninit:", s, s == nil, len(s) == 0) | |||
|
|||
// To create an empty slice with non-zero length, use | |||
// To create a slice with non-zero length, use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is ok, changing "an empty" to "a", but the ie ""
below is an unnecessary addition
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes okayy sure!
Hi !
I'm reading through gobyexample these days as I'm learning Go, and I came across 2 things:
go
keywords for calling routines.s = make([]string, 3)
, the slice is not empty, it contains 3 elements, the only thing is those elements are zero-valued but still the slice is not empty. I just thought it was a bit confusing when I read that, I had to read several times and then test it to really make sure I understood. So, here is a very little adjustment.Let me know what you think! :)