Hacker News Reader

Comment by kisielk | Hacker News Reader

I'm basically in the same situation though I've been programming with Go for under 6 months now.

A few features that have really begun to draw me away from Python:

* A step away from object-oriented programming while still providing a way to associate functions with types via methods. I've been tending towards a more functional style in Python lately with functions and simple types instead of heavy OO code. * Static instead of dynamic typing. I find that I rarely actually benefit much from the dynamic typing features in Python and they can often be a source of bugs.

A couple of things I still find myself missing regularly:

* A full-featured unit testing library like Python's unittest * A simple interface for defining rich command-line argument parsers like Python's argparse

View on HN

> * A full-featured unit testing library like Python's unittest * A simple interface for defining rich command-line argument parsers like Python's argparse

Most people find that the libraries for both unit testng and arg parsing in the Go stdlib are more than enough (IMHO specially the arg parsing lib does way more than I would ever want in a command line program).

But some people have written more "rich" alternatives, see the Unit Testing and Command Line UI sections here:

http://go-lang.cat-v.org/pure-go-libs

Some of the libs there are outdated, but that is mostly because in practice almost everyone find using what the standard Go distribution provides works very well. (If there is some functionality you are really missing you could fill an issue, but you would have to make a convincing case as to why it is needed.)

In the workplace we've written a pretty extensive suite of command-line programs in Python using the argparse module. It has some nice features to easily define subcommands as well as mandatory positional arguments, different argument multiplicities, etc. While most simple command line apps don't need this kind of functionality, the kinds of apps we are writing at my employer often do.

Anyway, neither of those cases are by any means a major downer, just two things that have been niggling me from time to time.

Somebody mentioned recently that the code that is part of the `go` tool that handles sub-commands maybe should be factored out and added to the stdlib, it should be relatively straightforward. If you are also interested in that I would recommend filling an issue in the tracker and if a few more people find it useful it probably will happen sooner rather than latter.

if you're talking about someone mentioning it in #go-nuts, that might have been me. I have a reference project to do that here: https://github.com/jordanorelli/multicommand

haven't taken time to turn it into a proper library.

Have you looked into using the built-in testing[1] library for unit tests; it seems very full-featured to me. In Go the flag[2] package contains the command-line argument parsing functionality.

Is it that you didn't know about these libraries, or that they don't meet your requirements? If the latter, what do you require from each of them that they do not already deliver?

[1] http://golang.org/pkg/testing/ [2] http://golang.org/pkg/flag/

I have used (and continue to use) both of these libraries. The testing library works fine but it doesn't include much other than the bare minimum. A more batteries-included library could include some assertion methods to test for value equality/inequality and provide some pre-canned error messages.

As for the flag package, it's fine for simple command-line flags but doesn't have anything to deal with specifying positional arguments. Sure you can get them from the Args() method but you have to basically write another layer of argument handling to deal with them. I like Python's argparse module's approach and flexibility there.

> A more batteries-included library could include some assertion methods to test for value equality/inequality and provide some pre-canned error messages.

For value equality, just use reflect.DeepEqual[1]. The wiki also has a page on table driven tests, which is worth a read[2].

[1]: http://golang.org/pkg/reflect/#DeepEqual [2]: http://code.google.com/p/go-wiki/wiki/TableDrivenTests

Just the other day I stumbled upon that wiki page, it looks like a pretty reasonable technique and I've started adopting it.

Thanks for the pointer to the reflect package, I shall check it out.

Reply on news.ycombinator.com