Skip to content
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.

Sign up for GitHub

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

fix: Added go for routines - Correct doc #571

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions examples/channel-directions/channel-directions.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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")
Copy link
Collaborator

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

Copy link
Author

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

Copy link
Collaborator

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 gos

pong(pings, pongs)
go ping(pings, "passed message")
go pong(pings, pongs)
fmt.Println(<-pongs)
}
4 changes: 2 additions & 2 deletions examples/slices/slices.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Copy link
Collaborator

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

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes okayy sure!

// the builtin `make`. Here we make a slice of
// `string`s of length `3` (initially zero-valued).
// `string`s of length `3` (initially zero-valued, ie "").
// By default a new slice's capacity is equal to its
// length; if we know the slice is going to grow ahead
// of time, it's possible to pass a capacity explicitly
Expand Down