I agree and think this is a nice and novel way to play around with go. The use of the double-underscores to highlight terms to replace is clear and easy to read. And the included assert() is perfectly valid as well as the docs about assert are strictly talking about a builtin... not about using the idea of asserting something in tests.
> Go doesn't provide assertions. They are undeniably convenient, but our experience has been that programmers use them as a crutch to avoid thinking about proper error handling and reporting. Proper error handling means that servers continue operation after non-fatal errors instead of crashing. Proper error reporting means that errors are direct and to the point, saving the programmer from interpreting a large crash trace. Precise errors are particularly important when the programmer seeing the errors is not familiar with the code.
> We understand that this is a point of contention. There are many things in the Go language and libraries that differ from modern practices, simply because we feel it's sometimes worth trying a different approach.
That is what the Go developers claim. I don't see this abuse very often in C, either.
If a speed sensitive function in C is documented to work
for integers in the range 0 < x < 256, then it makes sense to put in an assert() as a courtesy to the users of the function.
It does not make sense in every situation to do a range check and return an error, or worse, "panic" (the latter didn't work for the Ariane 5).
While I appreciate the energy put into this, I'm not a fan. I'm generally wary of tutorials that use examples that don't look like real programs. To me, this looks like a great idea from Ruby that has been shoe-horned into Go, and it feels weird.
However, there is the very good "Learn Go in Y Minutes" by Sonia Keys, which takes a similar approach but is more idiomatic, thorough, and concise: http://learnxinyminutes.com/docs/go/
Just ran through this and quite enjoyed it. It's very different from "A Tour of Go". I really like how he creates a narrative out of test failures. It's by no means effective as a sole source for learning Go, but I'd recommend it to those who have completed the Tour as a way of getting more practice working with Go's various data types.
It's not just the package name. It's the definition and use of assert, the strange __typenames__, the overall approach. In my opinion, learning the language this way would imbue the student with awkward and incorrect intuitions about the language and its idioms.
My interpretation is that the __typenames__ are merely there as placeholders so the program will compile, but fail at runtime during the tests. It's a tad odd, but the user is meant to replace the __typenames__ with their own values to make the tests pass. While doing so the user would be reading all of the code, and hopefully wind up grokking it.
It seems like a superficial tabs-versus-spaces kind of point, but when you see how the standard library is organized and how package names interact with actual programs, you grok why underscores make people wince; "foo_bar" should either be "foo/bar", or just plain "bar".
The import statement at the top of the file can clarify what the origin of a package is, but in the program body itself, the package name should make the library feel as natural as "fmt" or "io" or "math".
Yea, if there were a Go teaching site beyond Go tour http://tour.golang.org/, that would be something. Regardless of language, https://rubymonk.com is one of the nicest interactive teaching with "try out this snippet" and "solve this problem" sites out there. The issue for Go is that it probably needs a little bit more on the video explanation-side for new users (distilled from Google I/O, Gophercon) to explain features. People would probably pay to be taught backend languages (Erlang, Go, ...) and infrastructure in a https://www.codeschool.com format (irrespective of spoon-fed teaching resulting in SRE-calibre practical experience.)
Edit: to be a little more constructive, do the Go tour instead.