Errata

in:

func main() {
l := LoggerAdapter(LogOutput)
ds := NewSimpleDataStore()
logic := NewSimpleLogic(l, ds)
c := NewController(l, logic)
http.HandleFunc("/hello", c.SayHello)
http.ListenAndServe(":8080", nil)
}


http.HandleFunc("/hello", c.SayHello)

should be

http.HandleFunc("/hello", c.logic.SayHello)

Note from the Author or Editor:
There is a mistake, but this isn't the fix.

On page 158, the line:

func (c Controller) HandleGreeting(w http.ResponseWriter, r *http.Request) {

should read:

func (c Controller) SayHello(w http.ResponseWriter, r *http.Request) {

In:

func (me MyErr) Is(target error) bool {
if me2, ok := target.(MyErr); ok {
return reflect.DeepEqual(me,m2)
}
return false
}

The line:

return reflect.DeepEqual(me,m2)

should be:

return reflect.DeepEqual(me,me2)

Note from the Author or Editor:
This is correct.

On page 171, the line:

return reflect.DeepEqual(me,m2)

should be:

return reflect.DeepEqual(me, me2)

In:
func countTo(max int) (<-chan int, func()) {
ch := make(chan int)
done := make(chan struct{})
cancel := func() {
close(done)
}
go func() {
for i := 0; i < max; i++ {
select {
case <-done:
return
default:
ch <- i
}
}
close(ch)
}()
return ch, cancel
}

Lines:
default:
ch <- i

Should be:
case ch <- i:

Rationale:
In using default, if writing to the ch channel blocks indefinitely, then the anonymous function blocks indefinitely too, even if the done channel is closed while the ch channel is blocked.

Note from the Author or Editor:
This is a mistake.

On page 216 the lines:
default:
ch <- i

Should be replaced with the single line:
case ch<-i:

The indentation for the replacement line should match up with the case <- done: above it.

In:
func processChannel(ch chan int) []int {
const conc = 10
results := make(chan int, conc)
for i := 0; i < conc; i++ {
go func() {
results <- process(v)
}()
}
var out []int
for i := 0; i < conc; i++ {
out = append(out, <-results)
}
return out
}

Line:
results <- process(v)

Should be:
results <- process(i)

Also, function parameter ch is unused.

Note from the Author or Editor:
There is a line missing from the example.

On page 217, there should be a line:

v := <- ch

before the line:

results <- process(v)

The new line should be indented to match the existing line.

In:

server := httptest.NewServer(
http.HandlerFunc(func(rw http.ResponseWriter, req *http.Request) {
expression := req.URL.Query().Get("expression")
if expression != io.expression {
rw.WriteHeader(http.StatusBadRequest)
rw.Write([]byte("invalid expression: " + io.expression))
return
}
rw.WriteHeader(io.code)
rw.Write([]byte(io.body))
}))

Lines:
rw.WriteHeader(http.StatusBadRequest)
rw.Write([]byte("invalid expression: " + io.expression))
return

Should be:
t.Errorf("io `%s`, got `%s`", io.expression, expression)

Rationale:
"io.expression" is the expression the server expects to receive. "expression" is the actual expression received by the server. If the expected expression does not match the actual expression, then this is a test error, which should be reported. This is because it shows that RemoteSolver.Resolve() is unable to send the correct expression to the server.

Note from the Author or Editor:
This isn't really an error, but it's not clear. The code sample is showing how to use a mock http server, and the error text returned by the mock server isn't important, as long as it doesn't match the expected error message (or no error at all).

However, it would be better if the mock server returned an error that made clear exactly what went wrong. The best fix is to replace the line:

rw.Write([]byte("invalid expression: " + io.expression))

with:

fmt.Fprintf(rw, "expected expression '%s', got '%s'",
io.expression, expression)

The change is on page 291.

In the note section of chapter 3, section Using maps as sets there's a small error where an empty struct value is written as struct{} instead of struct{}{}:

for _, v := range vals {
intSet[v] = struct{} // this should be struct{}{}
}

Note from the Author or Editor:
Good catch!

On page 56, the line:

intSet[v] = struct{}

should be changed to:

intSet[v] = struct{}{}

When I run the first example on cgo, I get the following error:

[yukurt@c7 example1]$ go run main.go
# command-line-arguments
/tmp/go-build3204744771/b001/_x002.o: In function `_cgo_b1754505e405_Cfunc_multiply':
/tmp/go-build/cgo-gcc-prolog:74: undefined reference to `multiply'
/tmp/go-build3204744771/b001/_x002.o: In function `_cgo_b1754505e405_Cfunc_sqrt':
/tmp/go-build/cgo-gcc-prolog:92: undefined reference to `sqrt'
collect2: error: ld returned 1 exit status

Would you know what step I am missing? I am using a CentOS7 machine.

Note from the Author or Editor:
I'm not sure why this built correctly on my Mac, but it does not build correctly on Linux without the following addition to the magic comment:

#cgo LDFLAGS: -lm

On page 321, this line should be inserted right before:

#include <stdio.h>

After making this change, it builds correctly on both Mac and Linux. I have updated the sample on GitHub.

For example1, using GitHub commit 7e840f1 and go 1.16, I still get an error whether using CentOS7 or Ubuntu 20:

kurt@ub20:~/GitHub/learning_go/cgo_examples/example1$ go run main.go
# command-line-arguments
/usr/bin/ld: $WORK/b001/_x002.o: in function `_cgo_faccc96a4219_Cfunc_multiply':
/tmp/go-build/cgo-gcc-prolog:74: undefined reference to `multiply'
collect2: error: ld returned 1 exit status

To fix the error, I used the following workaround. In main.go:
#cgo LDFLAGS: -lm -lmylib -L.

Then I executed the following:
urt@ub20:~/GitHub/learning_go/cgo_examples/example1$ gcc -c -o mylib.o mylib.c
kurt@ub20:~/GitHub/learning_go/cgo_examples/example1$ ls
main.go mylib.c mylib.h mylib.o
kurt@ub20:~/GitHub/learning_go/cgo_examples/example1$ ar rcs libmylib.a mylib.o
kurt@ub20:~/GitHub/learning_go/cgo_examples/example1$ ls
libmylib.a main.go mylib.c mylib.h mylib.o
kurt@ub20:~/GitHub/learning_go/cgo_examples/example1$ go run main.go
a: 3, b: 2, sum 5
5
10
200
kurt@ub20:~/GitHub/learning_go/cgo_examples/example1$

Note from the Author or Editor:
I just verified. It should be go build, not go run.

The text should make this clear for example1 and example 2.

On page 322, the line

$ go run main.go

should be replaced with

$ go build
$ ./example1

Example2 fails when using Ubuntu20 or CentOS7:

urt@ub20:~/GitHub/learning_go/cgo_examples/example2$ go run main.go
# command-line-arguments
/usr/bin/ld: $WORK/b001/_x002.o: in function `_cgo_c2aa1e2acbbc_Cfunc_add':
/tmp/go-build/cgo-gcc-prolog:54: undefined reference to `add'
collect2: error: ld returned 1 exit status

I don't know any workaround to fix this because example.h has a dependency on _cgo_export.h which is nowhere to be found.

Note from the Author or Editor:
I just verified. It should be go build, not go run.

The text should make this clear for example1 and example 2.

After IEEE 754

“While Go lets you use == and != to compare floats, don’t do it. Due to the inexact nature of floats, two floating point values might not be equal when you think they should be. Instead, define a minimum allowed variance and see if the difference between two floats is less than that. “

Shouldn’t it be maximum allowed variance and see if the difference between two floats is less than that.

Note from the Author or Editor:
This is an error.

On page 24, the sentences:

Instead, define a minimum allowed variance and see if the difference between two floats is less than that. This minimum value (sometimes called epsilon) depends on what your accuracy needs are; I can’t give you a simple rule.

Should read:

Instead, define a maximum allowed variance and see if the difference between two floats is less than that. This value (sometimes called epsilon) depends on what your accuracy needs are; I can’t give you a simple rule.

In the following:

The type of a function is built out of the keyword func and the types of the parameters and return values. This combination is called the signature of the function. Any function that has the exact same number and type of parameters meets the type signature

The last line doesn't include the return values in the signature. So it should actually read as " Any function that has the exact same number and type of parameters and also exact same number and type of return values meets the type signature"

Note from the Author or Editor:
Yes, the sentence could be clearer and indicate that the return values are part of the function signature.

On page 94, the sentence:

Any function that has the exact same number and type of parameters meets the type signature.

should be:

Any function that has the exact same number and types of parameters and return values meets the type signature.

The following code snippet

func getFile(name string) (*os.File, func(), error) {
file, err := os.Open(name)
if err != nil {
return nil, nil, err
}
return file, func() {
file.Close()
}, err
}
Shouldn't the last return have nil instead of err, like below:

return file, func() {
file.Close()
}, nil

Note from the Author or Editor:
While the printed code would work, you are right that it is not a best practice.

On page 103, the code sample that ends with:

}, err
}

should end with:
}, nil
}

"uint16 0 to 65536" ->
"uint16 0 to 65535"

Note from the Author or Editor:
You are absolutely correct! Sorry about that mistake.

On page 20 in the print edition, the line in the chart that says:

uint16 0 to 65536

should read

uint16 0 to 65535

Chapter 7 -> "Interfaces Are Type-Safe Duck Typing" section -> Java example

The example has a minor error where program should actually call the process method on the logic field and not call the field as a method:

public void program() {
this.logic(data);
}

this.logic(data) should be this.logic.process(data)

Note from the Author or Editor:
Thanks for catching this! You are correct, the method call is wrong in the Java example.

On page 143 in the print edition, the line of code:

this.logic(data);

should read:

this.logic.process(data);

Indentation should remain the same.

The function buildGZipReader is listed as an example of how to properly wrap instances of io.Reader. I believe this code has a bug.

There are three paths out of this function:

1. The call to os.Open could return an error, which will cause us to return early
2. The call to gzip.NewReader could return an error, which will cause us to return early
3. Both calls could succeed, which will cause us to return with a successful result

The bug is in the second case. At the point of the early return, the *File returned by os.Open is still, well, open. When we return here, that *File will become garbage, but it won't get cleaned up until the garbage collector runs. So the file will remain open for an indefinite amount of time, possibly not getting closed until the process ends.

In the case of an early return from case #2, there should be a call to `r.Close()` before returning. 

Note from the Author or Editor:
That's a good point. There should be an r.Close() inside the second if err != nil line. Good catch!

Unwrap method declaration has a receiver of type "StatusError". It should be "StatusErr"

Note from the Author or Editor:
This has been fixed in the second edition.

"ch := make(wrapper, 1)"

should be

"ch := make(chan wrapper, 1)"

Note from the Author or Editor:
Found and fixed in latest revision

On Windows, the commands listed are as follows:
setx GOPATH %USERPROFILE%\go
setx path "%path%;%USERPROFILE%\bin"

Should the second command not be the following ? :

setx path "%path%;%GOPATH%\bin"

Note from the Author or Editor:
Absolutely right, the second setx should use GOPATH and not USERPROFILE.

On page 3, the line:

setx path "%path%;%USERPROFILE%\bin"

should read:

setx path "%path%;%GOPATH%\bin"

(The .PHONY line keeps make from getting confused if you ever create a directory in your project with the same name as a target.) is what is written on the book.

No.
It will work just fine if you create a directory with the same name, it won't work if you create a file with the same name. Try it out.

Corrected version should be -
The .PHONY line is created to prevent 'make' from getting confused if you create a file with the same name as the target not directory.

Note from the Author or Editor:
Thanks for reaching out! I just double checked and with the version of make on my Mac, either a file or a directory will cause make to do the wrong thing if .PHONY isn't specified. I tested with a project that contains a target called 'fmt' that runs 'go fmt':

% make fmt
go fmt ./...
% touch fmt
% make fmt
make: `fmt' is up to date.
% rm fmt
% make fmt
go fmt ./...
% mkdir fmt
% make fmt
make: `fmt' is up to date.
% rmdir fmt
% make fmt
go fmt ./...

There won't be any more updates to the 1st edition of Learning Go, but in the 2nd edition (due out January 2024), it says:

The .PHONY line keeps make from getting confused if there is a directory or file in your project with same name as one of the listed targets.

“Go provides both signed and unsigned integers in a variety of sizes, from one to four bytes.”

It should be “from one to eight bytes”

Note from the Author or Editor:
Thanks for finding this!

You are absolutely correct.

On page 20 in the print edition, the sentence:

Go provides both signed and unsigned integers in a variety of sizes, from one to four bytes.

should read:

Go provides both signed and unsigned integers in a variety of sizes, from one to eight bytes.

The code sample provided only sets variables x, y, z, and d, and does not print anything. However, the following paragraph says "When you run this code, it prints out...". It looks like there was a missing print statement.

Note from the Author or Editor:
You are correct. There should be an additional print statement after the type conversion declarations.

On page 27, at the end of Example 2-2, there should be an additional line in the example:

fmt.Println(z, d)

In the last paragraph on the page, you say "The first call to `copy` copies the last two values in array `d` into slice `y`", but I think you mean "copies the **first** two values in array `d` into slice `y`. (That seems confirmed by the Go playground and the output you show on page 47: 5 and 6 are copied, not 7 and 8.

Note from the Author or Editor:
This is an error. On page 47, the sentence that starts:

The first call to copy copies the last two values

should read:

The first call to copy copies the first two values

The line of code at the top of page 78, under section heading "Choosing the Right for Statement"

if i == len(evenVals)-2 {

Should in fact read:

if i == len(evenVals)-1 {

for the code to behave as described (otherwise it breaks the loop before printing penultimate entry in slice).

Note from the Author or Editor:
Thanks for catching this!

You are correct.

On page 78, the line:

if i == len(evenVals)-2 {

should read:

if i == len(evenVals)-1 {

When describing the feature of the `switch` statement where you can declare a scoped variable, the text reads "Also like an `if` statement, you can declare a variable that's scoped to all of the branches of the `switch` statement. In our case, we are scoping the variable `word` to all of the cases in the `switch` statement."

In Example 4-19, the `word` variable is scoped by the `for` loop. The variable that is scoped in the `switch` statement is `size`.

Note from the Author or Editor:
This has been fixed in the 2nd edition.

While explaining how to ignore some returned values from functions that return multiple values, you have the wrong number of assignments for a function from the previous page. You write "For example, if we weren't going to read `remainder`, would write the assignment as `result, _ := divAndRemainder(5,2)`.

But divAndRemainder returns three values: the result of division, the remainder, and a possible error. So you need either `result, _, err := divAndRemainder(5,2)` or `result, _, _:= divAndRemainder(5,2)`.

This is relatively minor, but initially I wondered if `_` could be used as a soak to pick up a variadic number of ignored return values. (I.e., if `_` could automatically handle both the remainder and the possible error.) But the Go playground suggests that `_` cannot handle more than one item.

https://play.golang.org/p/78_txMBRRW_d

Note from the Author or Editor:
Thanks for catching this.

In the second to last paragraph on page 91, the last sentence should read:

For example, if we weren't going to read remainder, we would write the assignment as result, _, err := divAndRemainder(5, 2).

The last code sample:

f := struct {
Name string `json:"name"`
Age int `json:"age"`
}

should be (missing last {})

f := struct {
Name string `json:"name"`
Age int `json:"age"`
}{}

Note from the Author or Editor:
Thanks for catching this!

You are correct

On page 117, in the last code sample, the line:

}

should be:

}{}

The code sample ends with "return process(r)", then "return nil". Surely the second return statement cannot be reached?

Note from the Author or Editor:
You are correct.

On page 145, in the second code block, the line:

return nil

Should be removed.

Chapter 4: switch

"Also like an if statement, you can declare a variable that’s scoped to all of the branches of the switch statement. In our case, we are scoping the variable word to all of the cases in the switch statement."

I think "the variable word" here should be "the variable size".

Note from the Author or Editor:
Thanks for finding this! Yes, that's the wrong variable name.

On page 79 in the print edition, the sentence:

"In our case, we are scoping the variable word to all of the cases in the switch statement."

should read:

"In our case, we are scoping the variable size to all of the cases in the switch statement."

StatusErr struct fields named "err" is inconsistent in the example.

type StatusErr struct {
Status Status
Message string
err error <--------
In some cases, expecting}

func (se StatusErr) Error() string {
return se.Message
}

func (se StatusError) Unwrap() error {
return se.err
}
func LoginAndGetData(uid, pwd, file string) ([]byte, error) {
err := login(uid,pwd)
if err != nil {
return nil, StatusErr {
Status: InvalidLogin,
Message: fmt.Sprintf("invalid credentials for user %s",uid),
Err: err, <-------
}
}
data, err := getData(file)
if err != nil {
return nil, StatusErr {
Status: NotFound,
Message: fmt.Sprintf("file %s not found",file),
Err: err, <------------
}
}
return data, nil
}

Note from the Author or Editor:
Hello,

Yes, this is a mistake. There's some extraneous text in the example as well.

On page 169, the lines of code that say:

type StatusErr struct {
Status Status
Message string
err error
In some cases, expecting}

Should be replaced with:

type StatusErr struct {
Status Status
Message string
Err error
}

Also, the code:

func (se StatusError) Unwrap() error {
return se.err
}

should be replaced with:

func (se StatusError) Unwrap() error {
return se.Err
}

in:

func MakeBar() Bar {
bar := Bar {
a: 20,
B: "Hello",
}
var f Foo = bar
fmt.Println(f.Hello())
return bar
}

Lines:

bar := Bar {
a: 20,
B: "Hello",
}

Should be:

bar := Bar {
x: 20,
S: "Hello",
}

Note from the Author or Editor:
Yep, I had renamed the fields in Foo from a to x and from B to S and didn't fix all of the code examples. Good catch!

On page 189, The block of code should read:

func MakeBar() Bar {
bar := Bar {
x: 20,
S: "Hello",
}
var f Foo = bar
fmt.Println(f.Hello())
return bar
}

The indentation should remain unchanged, just the field names a and B should become x and S, respectively.

The first paragraph on page 195 describes 'minimum version selection', which is explained as meaning "you always get the lowest version of a dependency that is declared to work in all of the go.mod files across all your dependencies.". In the example which follows however, it is explained that "it will choose version v1.2.3, as that is the most recent specified version". For me, "the most recent package" does not match the explanation that the minimum version will be chosen, as the minimum version declared by the package dependencies is v1.1.0.

In looking online for clarification, I discovered that I believe Go uses *minimal* version selection, as opposed to *minimum*. (https://go.dev/ref/mod#minimal-version-selection). From reading these docs, it appears that the example is correct, but the explanation that proceeds it is at least partially incorrect.

Note from the Author or Editor:
Thanks for catching this.

It is a typo that Minimal Version Selection was called Minimal Version Selection on page 194 and page 195.

I agree that the phrase "most recent specified version" is not great.

On pages 194 and 195, replace

Minimum Version Selection

with

Minimal Version Selection

On page 195, replace:

as that is the most recent specified version.

with:

as that, in the words of the https://go.dev/ref/mod#minimal-version-selection[Go Modules Reference], is the minimum version that satisfies all requirements.

The text reads:
"We're going to store this data into our t variable, one JSON object at a time."

The set up and hence type of the t variable has been missed out in the immediate vicinity of the text or in the book's preceding pages. The example code on the Go playground has set up the variable (as an anonymous version of the Person struct on page 244). The text would benefit from either initialising t explicitly, or saying what variable it is.

Note from the Author or Editor:
You are correct. The definition of t was removed from the book to save a few lines (the book was a bit longer than was originally intended), but the removal of the definition of t makes the example far less clear. It should be restored.

On page 245, the code sample that starts with:

dec := json.NewDecoder(strings.NewReader(data))

should have the following lines prepended:

var t struct {
Name string `json:"name"`
Age int `json:"age"`
}

The line is:

t.Errorf("incorrect result: expected %d, got %s", 5, result)

The addNumbers function takes two ints and returns an int. In the t.Errorf line, the "%s" should be a "%d", shouldn't it?

Note from the Author or Editor:
Hello,

You are absolutely correct. Thanks for catching my mistake!

On page 273 in the print edition, change the line:

t.Errorf("incorrect result: expected %d, got %s", 5, result)

to

t.Errorf("incorrect result: expected %d, got %d", 5, result)

There are two problems with this code sample. First, there are 4 values in data, and only three expressions being evaluated. Second, we expect an error from the third expression, but the test fails when it happens.

Replace the lines:

data := []float64{22, 40, 0, 0}
for _, d := range data {
result, err := p.ProcessExpression(context.Background(), in)
if err != nil {

with:

data := []float64{22, 40, 0}
hasErr := []bool{false, false, true}
for i, d := range data {
result, err := p.ProcessExpression(context.Background(), in)
if err != nil && !hasErr[i] {

This is a possible resolution of the error in the program 'context_cancel' in Chapter 12: Context, that I had reported earlier.

The function 'slowServer' in servers.go can be written as follows to avoid the error reported earlier:

func slowServer() *httptest.Server {
s := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
ctx := r.Context()
select {
case <-ctx.Done():
case <-time.After(6 * time.Second):
}
//time.Sleep(6 * time.Second)
w.Write([]byte("Slow response"))
}))
return s
}

Note from the Author or Editor:
Hi Krishna,

I do like this fix, because it shows the context being used in a server. I don't think I can include it in a revision of the current edition, but what I'd like to do is use this in an example box between the end of the section on cancellation and the section on timers, with the text:

You probably noticed that the program didn't exit immediately when the error is triggered. That's because it is waiting for the `slowServer` to close. If you lengthen the timeout from 2 seconds to 6 seconds or more, you'll see an error message that starts with `httptest.Server blocked in Close after 5 seconds, waiting for connections`

If we rewrite `slowServer()` to properly handle context cancelation, we can shut it down immediately:

func slowServer() *httptest.Server {
s := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
ctx := r.Context()
select {
case <-ctx.Done():
fmt.Println("server shut down")
return
case <-time.After(6 * time.Second):
w.Write([]byte("Slow response"))
}
}))
return s
}