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).
The assert() is just to make it fail until you have the right value for the variable its testing.