Why I'm interested in Go

October 24, 2010

These days, my substantial programming takes place in one of two languages. I use Python if I'm dealing with something that doesn't have to run fast or use minimal memory, and I use C on the occasions when Python doesn't fit. I like C, but it is a very sparse and unforgiving language when compared to Python and this translates to slower and more annoying development most of the time; there's a lot of low level details that I have to worry about when I just want to bang out some code that runs fast(er).

(This annoyance leads me to use Python for everything that it can even barely be made to fit.)

There are times when C is the right answer, but there are also a lot of times when what I want is in the middle between C and Python, problems where Python is too heavyweight and bare C is too low level. Part of why I'm interested in Go is because it seems to be the most promising candidate to fit in this niche on Unix. It promises relatively fast runtime and relatively little memory usage while still giving me garbage collection, convenient strings, hashes, and arrays, and a decent set of support modules. For me, this makes Go the attractive choice for writing various system level programs like non-trivial network daemons.

(There will be C libraries for all of the packages that Go comes with, but I'd have to go find them and that leads to the selection problem. And in general, syntax matters and Go has better syntax than C plus libraries.)

Another part of why I'm interested in Go is that it comes from a group of people (call them the Plan 9 crowd) that have created a whole bunch of interesting, good ideas that I've found attractive in the past. Sometimes the results are too purist for my tastes, but they've pretty much always been worth a look. And the way I look at languages is actually using them for real work, so I have gone and dabbled in Go; ideally I would like to use Go to write a relatively substantial program that I'll actually use.

(It has to be a personal program, since I won't write production programs in obscure languages that my co-workers have never heard of and that don't (yet) come packaged on our Unix systems.)

Sidebar: why other candidates are out

Java is, right now, not a particularly great language to write Unix system programs in for at least two reasons. First, Java programs generally start slowly for the same reason that Python programs start slowly; they have to load and start the interpreter before they actually start the program. Second, my impression is that the JVM does not provide good access to Unix systems facilities.

(These drawbacks apply to any number of interesting languages built on top of the JVM, and in general to any interpreter-based language. Slow startup is not an issue for long-running programs, but I don't write that many of them.)

The D language struck me as sort of interesting when I first heard about it but it doesn't seem to have cohered into a useful system (rather the reverse, in fact), and I'm not really interested in languages that aren't open source because there's very little chance that they will become popular on my platform of choice.

C++ has many of C's problems as far as language features go, just somewhat nicer syntax once I find libraries and packages and so on that do what I want. And it doesn't have native garbage collection, which is one of the great programming speed accelerators.


Comments on this page:

From 87.159.137.71 at 2010-10-24 09:11:41:

Have you looked at node.js? It has pretty good unix facilities and is light on abstractions.

--Felix Geisendörfer

By cks at 2010-10-25 00:05:31:

My impression is that node.js is primarily for network stuff, which is part but not all of my interest, and of course it has the interpreter issue. And while it has some very attractive facilities, I'm not enchanted with its documentation.

Still, it's got some interesting aspects, I could stand to learn JavaScript someday, and its explicit support for passing file descriptors over Unix domain sockets fits very well with something I'd like to write.

From 87.159.142.172 at 2010-10-25 16:26:14:

Yeah, Networking is the main focus of node.js. However, spawning and interacting with child processes is also rather well done, so are other parts. If you see particular features or docs missing, just let me know - I'm a regular contributor.

What do you mean by "the interpreter issue"?

PS: I love your blog, it's hard to find high quality unix articles like this elsewhere.

By cks at 2010-10-28 23:39:11:

I've emailed notes on what I noticed about the node.js documentation to what's hopefully the right address.

The interpreter issue deserves a full entry, but the short version is that I think interpreters are inferior to compiled programs in situations where I want relatively small resource usage or very rapidly starting and short-running programs.

From 216.239.45.4 at 2010-11-01 19:24:37:

A couple of month ago I decided to find another language for myself to learn (I use Java at my day job). The were several criteria for the language: execution speed, fast compilation, available libraries, easy-to-learn syntax (read it as similar to java/c). So at the end 2 languages were left Go and Vala.

And I decided to go with Vala. http://live.gnome.org/Vala . Why not Go?

- Vala is faster. Yep, Vala is super-duper fast. In fact it is as good as hand-written c. http://code.google.com/p/vala-benchmarks/wiki/BenchResults
- A lot of features, exceptions, generics, delegates, closures, class properties http://live.gnome.org/Vala/Tutorial
- Works on many platforms, anywhere where gcc works
- Syntax looks more traditional for mainstream developers (very similar to C#)
- Vala is going to be a standard language for Gnome applications. Many people are going to use. While Vala grows from gtk+ community it works fine for console apps. I want to try it for web development also
- I like Vala community better. Rob Pike is known as "architecture astronaut" who does something interesting and cool but not very practical, and once he played with it he just drops it away. Plan9, Limbo language and some internal Google projects. Vala team looks more solid in this case.

- It is very easy to add Bindings for C libraries. Here is an example for memcached. http://github.com/bcg/libmemcached-vala/blob/master/src/libmemcached.vapi

Check this out http://live.gnome.org/Vala/Tutorial

Go is also an interesting language anyway so maybe I look at it later. Now I spend my free time hacking Vala.

Written on 24 October 2010.
« My issues with Go's net package
Why we built our own ZFS spares handling system »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Oct 24 00:58:06 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.