Also working on a flat-file blogging system with an online editor, because flat-file is the middle ground between a static-site generator and a traditional database-based blogging engine.

I'd like to use it more, but we have so many layers of legacy Perl code, that it's difficult to replace single components because of their dependencies (rewriting anything worthwhile would mean rewriting 4-5 libraries also).

Sounds cool. What kind of server are you running this on?

It runs on a single node of a 4-in-1 supermicro server with dual Opteron 6136 CPUs. Because it uses so little CPU time (about 15% of one core on average), we are now using the server for other things as well ...

Nice technique.

http://jugad2.blogspot.in/2014/01/websocketd-and-python-for-...

websocketd is a good tool.

A friend has also been using Go to create a board game as his side project.

What's used for the GUI of the game?

>Files are JSON documents to which you can attach any binary/text data (docx, txt, pdf, jpeg, etc...).

I'm guessing you store the filename(s) of the attached data (docx, txt, pdf, ...) in the JSON fragment?

I had blogged about Docker using LXC, as part of this post about Domino, a Python PaaS for data science:

http://jugad2.blogspot.in/2013/12/domino-paas-for-data-scien...

and had seen then that Docker uses Go, though I didn't say so in the post.

Cool.

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.torbit.com/

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).

http://golang.org/cmd/go/

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).