Can you elaborate? I'm unfamiliar with Go, but most of my Python (and Perl, sigh) coding could be classified as "utilities for work". I would have thought that any language with an explicit compile step would be at a disadvantage in this space.
Sure.
>I would have thought that any language with an explicit compile step would be at a disadvantage in this space.
Not exactly, and not always. In fact it can be the opposite. It depends on a few factors, and there are tradeoffs.
Consider that so many of the command-line utilities that come bundled with Unixen (Unix, Linux, BSD) are written in C - just look in /bin, /usr/bin, etc (some of the default dirs in $PATH). (Do a "file * | less" in those dirs.)
(Though there definitely are utilities that are written purely in *sh, or Perl, or Python, and more so these days than some years ago. Still, some, particularly shell scripts, tend to make calls to compiled utilities such as sed, awk, grep, ls, du, df, ps, and many other commands.)
For utilities used often or heavily, or where performance is important, a compiled binary can often be a good choice: lower startup time (don't have to start the interpreter to run the script, often faster run time (because running compiled machine code vs. interpreted or JIT'ed).
Go has performance closer to C than Python does, and also has some aspects of HLL's (High Level Languages) like Python. The compile only has to be done once per machine or platform, remember; also, Go compilation is quite fast, which was a design goal of the language. And if you compile once on one machine, you can just copy the binary (in an automated way, too) to any number of other machines running the same OS and version. With a self-sufficient binary, you avoid both the issues of missing or incorrect dynamically loaded libraries of languages like C (if the C program uses them), and the issues of missing or wrong versions of required libraries, with languages like Python.
Those are some reasons I could think of, off the top of my head. There may be others, both pro and con.
http://www.onlineaspect.com/about/ (Josh's site)
Uh, well, sure. From the context, I thought little ad hoc utilities were meant. The kind that are changed frequently. We keep many right in our svn repository, so you make a check-out and make use of a little script right in the same directory as your project source code.
The thing is, given Go's compilation speed, little utilities will compile so fast that you'll barely notice it (on any decently powerful machine), and on the other side there's the overhead of starting up the Python or Perl interpreter.
There's also the "go run" command, so you don't even have to give two separate commands (compile and run).
The command "go run filename.go" compiles the specified Go source file and then runs the resulting binary (assuming no compile-time errors, of course).