Marcel Lanz (6) [Avatar] Offline

Thank you for this interesting book about Go in practice. I've got the MEAP and noted some points (beside typos) after reading Chapter 1. hope it is helpful.

file: Go_in_Practice_v4_MEAP.pdf
sha1: b06e8f9a13dc63592bf4ddbae651838077b1361c

1.2.3, p9:
"Sometimes dubbed lightweight threads, goroutines are managed by the Go runtime where they are mapped and moved to the appropriate operating system thread and garbage collected when no longer needed."

>> "Goroutines are not garbage-collected. They must return from the top-level function (or panic) to have all their resources recovered."
as someone said that should know it.

1.2.3, p11, listing 1.7:
"#6 Main pauses before ending"

and p11,p12:
"When main is done executing the entire program is done so we pause for a second #6 before existing so printCount can complete before main is done. "

>> not a second but a millisecond as you write in the code.

>> beside that, this is very bad practice in this context I think. if the goroutine isn't finished with fmt.Print here within this millisecond, the expected output would not appear. to demonstrate channels it's especially helpful to understand that such "guessed waiting" is not appropriate for a Go program but instead use clear synchronisation primitives.

>> using "-1" as a termination condition value within the data could perhaps also refactored. so instead close the channel or use another channel to "communicate", this way, the channel is used as transportation of these values and at the same time one of the values is used as an "in-bound" command => not very simple or elegant.

chapter 1: in general this chapter could go a bit more fluent.

1.2.4, p13:
"Package imports can be grouped together and should be in alphabetical order. In this case the "net/http" package is referenced with the http. prefix."

>> in this context, its not obivious what should be prefixed. if one saw the fmt prefixing for Println he could guess, but why not explicitly show code that gets prefixed, or even better explain how imported identifiers are hanled (. import, rename imports)

1.2.4, p13:
"Package names are unique strings and can be anything."

>> not sure if that is understood right. they can't be anything, they have to be identifiers. in this case they might be import declarations and not "package names" ?

1.2.4, p13:

>> google code will go away and soon into Read-Only mode, perhaps better use current URL.

1.2.4, p15:

>> same as above.

1.3, p16:
"Go has a runtime and garbage collection system that don't run well on embedded systems with limited resources."
>> why ?, really?

1.3.1, p17:
"Go initially came to life as an alternative to C for developing applications."

>> alwys had the impression Go should be a replacement for large C++ and JAVA system applications written by Google itself. Also (too) long build times where mentioned all over the place.

1.3.1, p17:
"Go applications compile faster than their C counterparts."

>> perhaps one could mention how Go resolves packages and source code and why circular package depenencies are not allowed with Go.

1.3.2, p18:
"Go isn't a language you can use for mobile device development"

>>not anymore true with Go 1.5. For Mobile see the go mobile project grown out of google.
beside that, Go 1.5 introduced Mobile Architecures and OS support (arm and arm64, iOS and Android)

"GopherCon 2015: Hana Kim - Go For Mobile Devices"

1.4.3, p22:
"The one environment variable that you need to set is the $GOPATH"

>>he environment variable is called GOPATH, not $GOPATH

1.5, p23:
"This is followed by a call to http.ListenAndServe telling the web server to listen to start up and listed on port 4000 of the domain localhost."

>> localhost is a hostname. ".localhost" would be a domain(name).

1.6, p25:
"The Go philosophy of simplicity plus extensibility that created a useful language and enables an ecosystem to surround it."

>> how is Go's simplicity explained? and what is meant by that? Without explaining types, initializers, implicit interfaces and Go's ortogonality properties, how is its simplicity explained?
Matt Farina (9) [Avatar] Offline
Thanks for the feedback. When we go back to revise that chapter we'll take this into account.