Go Koans(github.com)
github.com
Go Koans
https://github.com/cdarwin/go-koans
26 comments
I think you missed the point of this project. The __int__ is just a placeholder you are expected to replace with the real value.
The assert() is just to make it fail until you have the right value for the variable its testing.
The assert() is just to make it fail until you have the right value for the variable its testing.
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.
That is what I was wondering: http://golang.org/doc/faq#assertions
> Why does Go not have assertions?
> 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.
I was wondering how the "go test" function was working as well, here is a start of an answer: http://golang.org/doc/faq#How_do_I_write_a_unit_test
> Why does Go not have assertions?
> 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.
I was wondering how the "go test" function was working as well, here is a start of an answer: http://golang.org/doc/faq#How_do_I_write_a_unit_test
> programmers use them as a crutch to avoid thinking about proper error handling and reporting
Funny, because asserts in C are used to find bugs but not for "error handling and reporting".
Funny, because asserts in C are used to find bugs but not for "error handling and reporting".
I tend to use Go's panic() in many situations where, in C, I would make assertions.
The point is that they are commonly abused to provide error handling and reporting.
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).
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).
But you're giving an example where you think an explicit panic is justified.
Losing asserts doesn't eliminate either option. It simply requires you to have exicit error handling or a panic. This is the point.
Losing asserts doesn't eliminate either option. It simply requires you to have exicit error handling or a panic. This is the point.
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/
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.
> package go_koans
Why?
'package koans' is simpler and more idiomatic of Go.
The canonical Go style eschews underscores in package names.
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".
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".
Looks like a pull request to fix that has been submitted and it's a naming convention in golang.
https://github.com/cdarwin/go-koans/pull/9
https://github.com/cdarwin/go-koans/pull/9
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.
I feel a lot of people in this thread are not grokking the concept of the post itself.
To add to what you said, the asserts are only there to test your knowledge of the correct value of the variable.
To add to what you said, the asserts are only there to test your knowledge of the correct value of the variable.
Is there an order I'm supposed to be doing these in?
On the github page 'Usage section' the author said you need to clone the repo and run go test and follow what is on your screen.
|~/go-koans - [master] » go test
about_basics.go:4
assert(__bool__ == true) // what is truth?
exit status 1
FAIL _/Users/kev/go-koans 0.040s
Would be nice to have it in the browser like Go tour.
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.)
Good approach to learn Go with simple examples. Thanks!
Edit: to be a little more constructive, do the Go tour instead.