Servers

Web development using Go

Go has enjoyed unusually rapid adoption and popularity among developers. Here are some highlights of using this programming language.

The Go programming language is one of the newer languages available, only released for public consumption in November 2009 and christened as production-worthy by Rob "Commander" Pike as of May 2010. Nevertheless, Go has enjoyed unusually rapid adoption and popularity, which might be due in part to the backing of Google, the fame of its authors (yes, that Ken Thompson), or its innate coolness.

Go has concurrency baked into the language in the form of goroutines, which are conceptually similar to threads, but the language manages their mapping to real threads (or not) under the hood. The syntax for creating goroutines is remarkably simple, and Go provides a special data type called channels to facilitate communication between goroutines (and between goroutines and the main thread). A web server provides a natural application for this kind of parallelism: a separate goroutine can handle each web request.

Go is designed to be a system language, like C. Its syntax is similar to C's, but with numerous relaxations and improvements. Its most beneficial similarity to C, though, is its performance. Go is a compiled language, so you can bet that it will scale up to increased traffic better than interpreted alternatives like Ruby, Python, and PHP. On the other hand, that means you have to recompile and link components of your web server whenever you change the code. It's a trade-off.

Like C, Go has pointers -- but in Go a pointer is much less likely to become an anti-foot cannon. Go provides garbage-collection instead of relying on the programmer or a class implementation like smart pointers to free them. Go prohibits casting and pointer arithmetic.

Even though Go provides strong, static type safety, it also allows for more dynamic typing via interfaces. Superficially, Go interfaces are similar to Java interfaces in that both specify a minimum set of methods that an implementer of an interface must provide -- but Go's implementation is much more fluid. For instance, you can declare a parameter as an interface with no methods -- which allows you to pass anything. Any type that implements the methods of an interface implicitly implements the interface, without having to say that it does. Thus, Go interfaces are more like duck-typing laundry lists. Unlike duck-typing in late-binding languages like Python and Ruby, however, the implementation requirements in Go get checked by the compiler.

Go already has an active and helpful community. On the golang-nuts Google group you're likely to get a prompt answer from people deeply involved in the project, like Russ Cox or Commander Pike himself.

When it comes to creating your web server, you have at least three options: (1) the http package that comes with the language, (2) Web.Go (inspired by web.py for python), and (3) Twister (inspired by Tornado, which was itself at least partially inspired by web.py). All three of these promote the approach of registering handlers to match incoming URIs and then calling a Server.Run method to dispatch requests. Web.Go provides explicit support for shared hosting via SCGI or FastCGI.

For templating, Go provides its own template package. There's also a version of the popular mustache logic-less template engine available. Twister includes examples of using the template package with the templates organized as HTML pages much like eRuby or PHP. Web.Go recommends using mustache instead, because it can do recursive templating.

What's a web application without a database? Work is progressing on Go bindings for many popular databases, including MySQL, PostgreSQL, SQLite3, and even ODBC (if you're so inclined). As of this writing, the SQLite3 bindings appear to be the most mature of the bunch, especially Eleanor McHugh's fork.

When would you want to use Go for your site? The Go language and supporting packages sre still in a state of rapid development, so unless you're in an experimental frame of mind you might want to avoid sinking too much effort into work that might become obsolete soon. On the other hand, it looks like Go hits the sweet spots between performant parallelism and ease of programming, dynamic and safe typing, simplicity and a multitude of options. You might find it useful sooner than you think.

About

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

27 comments
Jaqui
Jaqui

a repo checkout? that is the only way to get the source code? tells me not worth touching. if it was worth it, they would make a tarball of the sources available.

ian
ian

Thanks guys, it was probably a bit ambitious :-) Time for a re-think, me-thinks.

ian
ian

but I want to get my teeth into something to expand my knowledgebase. golang.org has a tutorial introduction to the basics but it assumes C or C++ knowledge. I am a complete newbie - but not a nunce. I did write Basic years ago and wriiten some JCL stuff when I was on mainframes but nothing to shout about. The only code I write now is HTML and CSS with a little javascript. Do you have any links where someone such as I can get started? Thanks

Justin James
Justin James

I've been really wanted to check out Go for a while now. I suspect that it's built-in parallelism, combined with its *Nix-friendliness, would make it an excellent language to rewrite the Rat Catcher backend in, while not being as much of a conceptual leap as Haskell, Erlang, etc. J.Ja

lisa_work_aws
lisa_work_aws

Duct tape is used for DUCT work. There are no animals involved.

apotheon
apotheon

> if it was worth it, they would make a tarball of the sources available. Please explain your reasoning. By the way -- you can get a tarball download from the GitHub mirror. Regardless of that, though, I still want to know why you think the lack of a tarball would mean something was "not worth touching". edit: . . . and what do you have against version control, anyway?

apotheon
apotheon

I find myself facing problems with Go -- I want to delve into it, but I keep running into roadblocks because I'm not competent enough with C and C++ to immediately grasp the stuff that the howtos assume everybody knows. . . . so I keep doing other stuff instead. I figure one of these days I'll get back to Go and it'll all be pretty clear. I try to keep an eye on it to see if either my knowledge has expanded sufficiently to have the experiential background necessary to make reasonable progress or someone has finally offered some information for which my experience is sufficient to get it all on the first try. Of course, knowing C is of huge benefit anyway, learning C before Go is not a huge problem, unless you just want to be able to get into Go development before all the interesting ecosystem challenges get addressed by other people. That's my quandary; I'll probably get to the point where I can seriously get into Go development right about when the ecosystem stuff is done, which is something I would have liked to be involved in doing myself. C'est la vie. It'll probably still be an interesting language that I want to learn and use, at least.

Sterling chip Camden
Sterling chip Camden

I don't think it's a particularly friendly language for beginners, although it's a tad friendlier than C/C++. If I were in your shoes, I'd take my Javascript experience and work it up to guruhood. Once you've got a firm grasp of the prototype object model and a good functional style using closures, then other languages will make more sense to you -- including Go. Ruby or Python might also make good stepping stones.

Sterling chip Camden
Sterling chip Camden

... since you're used to the .NET way of doing things. Methods in Go are much more similar to methods in CLOS than in any other OO system that I can think of, with an interface playing the part of the "generic function" in CLOS (or more accurately, a set of generic functions). Go's OOP doesn't provide any implementation inheritance, either -- which even differentiates it from CLOS. As a result, it encourages composition over derived types -- which is a good thing, I think.

Cannabis Seed
Cannabis Seed

Go has taken off for the simple reason that it is easy to use and very expandable, which is just what devs need. There is no longer the time allowance to develop at the pace that was previously acceptable, its now more important than ever to have a reliable and user friendly wide spread application. cannabis seed

WebCzar
WebCzar

'Duck' tape is a very popular BRAND, they also produce padded mailers, duct tape, and other adhesive-based products.

Jaqui
Jaqui

to look at an application, even if you have to build from sources, does NOT require all the versioning information a repo checkout includes. it only requires the source code itself. I have no problem with version control, it's the idiocy of thinking a repo checkout is the same as a tarball of the sources. when you remove the versioning info you reduce the data transfer amount by up to 50%. [ with git, the versioning data is exactly as much data transfer as the source code. sending it compressed still means sending twice as much data as needed. ] The only time versioning information is required is when you are going to be submitting patches or actively working on developing the project. It is useless garbage to look at usability of the product. and anything to do with the worst example of bloated data transfer consumption [ git ] I never go near. never been to github, and never will a project that can't be bothered to make a tarball of source code available for people to check the app out doesn't want people to use it, as far as I'm concerned.

Sterling chip Camden
Sterling chip Camden

... that the Go docs explain things in terms of C. Experienced C programmers find that comforting -- everybody else not so much. Back in my early days of C programming, I had to think of C in terms of assembler. The fact that all these languages deal in pointers creates a conceptual hurdle that you have to get over before they make sense. It's not that big a hurdle, really -- it just seems big when you haven't gotten over it yet.

apotheon
apotheon

There is not much in the way of instructional and howto material that can get a novice programmer up to speed with Go -- especially someone who's a novice without C or C++ experience. Go's advocacy efforts seem entirely to be oriented toward C, C++, and (to a lesser extent) Java and C# programmers. Everybody else has to be much closer to true expertise as a programmer to be able to easily overcome the lack of support for learning the language. As for JavaScript . . . it's pretty difficult to actually pursue a smooth path from novice-level skill to competency in JavaScript. The novices are dealing with the markup-embedded stuff and a few cut-and-paste functions, and the experts are writing entire industrial-strength applications, but there isn't much in between. I think it might be a good idea to pursue something aside from JavaScript -- maybe even something that writes JavaScript for you -- for a while. I mean something that provides a much smoother progression from novice to competent, like (as you mentioned) Ruby or Python. Of course, if your goal is Go, and not JavaScript guru-hood, that would mostly just be switching from JavaScript to Ruby or Python to gain more substantial skill, rather than using Ruby or Python to cover the intermediate space between novice and competent levels of JavaScript development.

Justin James
Justin James

... I find .NET approach to OO unnerving. I use it as little as possible. It is somewhat rare that I write anything involving it beyond the basics (properties and methods). For the code I find myself writing, the OO paradigm doesn't give me anything. J.Ja

Sterling chip Camden
Sterling chip Camden

... I always make a tarball available, but bandwidth isn't the reason: I do it because I figure there are still a lot of potential users out there who haven't used hg and who don't want to have to figure it out (as simple as it is) before they can look at my project. That's also why I provide a zip archive if there's a chance that the project can be useful on Windows. Even though tar versions are available for Windows, why put up that hurdle? As far as bandwidth goes, I have yet to download a project where the difference between the size of source control and source alone is noticeable. But then, I've been on 1.5mbps+ for the last five years, and now I have a 16mbps connection. YMMV.

apotheon
apotheon

You still have at least two options if you don't want a local repository, but want the source: 1. Get the tarball from GitHub. 2. Clone the repository, then delete the .hg subdirectory.

Jaqui
Jaqui

"> We understand that this is important, but because Go is changing so fast, we are trying to keep everyone mostly in sync by using Mercurial. Once Go is a bit more mature, we will certainly have archived downloads for releases." Google never makes source tarballs available for any of their "open source" projects, they promote the repo checkout = tarball idiocy instead.

apotheon
apotheon

There's a bug filed for the lack of project source tarballs, Issue 95: Go archive downloads. A Go language project member had this to say: > We understand that this is important, but because Go is changing so fast, we are trying to keep everyone mostly in sync by using Mercurial. Once Go is a bit more mature, we will certainly have archived downloads for releases. Based on that issue, though, they've started working on a system to automate building nightly snapshots, documented at Issue 810: create new download automatically from trunk. In the meantime, though, it looks like the GitHub mirror is the place to get tarballs of source without repository version data (though I found some hidden tarballs of the entire source tree including version data). > and anything to do with the worst example of bloated data transfer consumption [ git ] I never go near. never been to github, and never will That seems a little unreasonable when all you want is the tarball. Just click on the Downloads button, and select the .tar.gz download. You don't have to use Git to get a tarball from GitHub. > a project that can't be bothered to make a tarball of source code available for people to check the app out doesn't want people to use it, as far as I'm concerned. Well . . . maybe not enterprise end users. The Go language is still under heavy development, and does not officially have a "stable release" yet. Unless you want potentially unstable nightly tarballs, it might not be entirely fair to expect tarballs that do not coincide with a stable release. Rob Pike has said Go is being used for "real stuff" internally at Google, but Google is where Go is being developed, so if there's a problem the developers are right there. We on the outside are sorta working at our own risk if we use Go, and there are bound to be amenities missing (such as precompiled binaries from the core project for your platform of choice, or source tarballs). The people using Go right now are basically early adopters and people interested in hacking on the language itself, for the most part -- not "end user" developers.

apotheon
apotheon

Unfortunately, the Debian world is lagging a bit. I'm not terribly surprised. Then again, Debian uses binary packages, so this is kind of moot where Jaqui's complaint is concerned. It's just a complaint of my own that I've recently encountered.

apotheon
apotheon

. . . but that's hardly conducive to learning to do useful things with the language in a timely manner, and is the opposite of maximizing code reuse.

Sterling chip Camden
Sterling chip Camden

... is to develop your own utility library. Most long-term C developers have their own wrappers for just about everything from memory allocation to command-line processing. It makes insertion of debugging facilities easier, for one thing.

apotheon
apotheon

Pointer arithmetic in particular is not something I've really dealt with enough to be comfortable with it, but pointers as a basic concept are not so terribly difficult for me. The real problems I have with C involve all the fiddly things that C doesn't handle seamlessly (thus requiring a lot of exposed implementation complications), and that its standard libraries don't really cover for me either. This, in fact, is somewhat similar to the one problem I have with Io: it is the first really high-level dynamic language I've seen that essentially exposes its own implementation to the developer using the language rather than offering a consistent syntactic model that renders it a bit friendlier to the user. As a result, Io seems basically useful as an exploration rather than a "real" language. C, unfortunately, cannot simply be toyed with and left behind. Getting past the "yes, you really have to deal with the exposed girders in this unfinished building" stage is a much bigger ordeal in C, and I don't really get to the value C provides until I do so. I've done a little bit of C here and there over the years, but mostly it has involved learning the bare minimum to do what I need/want to do, then forgetting most of what I learned before the next time -- because I have to spend some time doing something else for a while. One of these days, I'll turn all my focus to it long enough to make some sustainable progress. It's a serious undertaking, though, to learn more than the basics and more depth only within the parameters of a specific task; it'll be even more of a serious undertaking to get into more depth in a way that will allow me to actually achieve and retain an overall competence in the language.

Sterling chip Camden
Sterling chip Camden

It provides just enough OO to make sense of data structures and ensure type safety if you want to.

Editor's Picks