\nGoing Loopy

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\nAdventures in Iteration

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

",{"_421":422,"_44":45,"_48":49,"_46":47,"_66":67,"_423":424,"_522":419},"previewContent","

\n Introducing Go\n
- \n \n
  - \n Getting Started\n
  - \n So what is Go?\n
    - \n Open source\n
    - \n Efficient compilation\n
    - \n Efficient execution\n
    - \n Ease of programming\n
    \n
  - \n And where did it come from?\n
  - \n Into the wild\n
  - \n Where next?\n
  \n
- \n Hello World\n
  - \n Packages\n
  - \n Constants\n
  - \n Variables\n
  - \n Functions\n
  - \n Encapsulation\n
  - \n Generalisation\n
  - \n Startup\n
  - \n HTTP\n
  - \n The Environment\n
  - \n Handling Signals\n
  - \n TCP/IP\n
  - \n UDP\n
  - \n RSA obfuscated UDP\n
  - \n Error Handling\n
  - \n Exceptions\n
  \n
- \n Echo\n
  - \n Arguments\n
  - \n Flags\n
  - \n Command-line Boilerplate and Standard I/O\n
    - \n Conditional Flags\n
    \n
  - \n Errors\n
  \n
\n
\n Going Loopy\n
- \n \n
  - \n Adventures in Iteration\n
  \n
- \n Linear Sequences\n
  - \n The for {} construct\n
  - \n User Defined Slices\n
  - \n Iterating Through Arrays\n
  - \n Arrays and Slices Exposed\n
  - \n Iteration and structured types\n
  \n
- \n mappings\n
  - \n Iteration and maps\n
  \n
\n
\n Software Machines\n
- \n Software Machines\n
  - \n array stacks\n
  - \n cactus stacks\n
  - \n hash maps\n
  - \n heaps\n
  - \n switch dispatchers\n
  - \n direct threaded dispatchers\n
  - \n indirect threaded dispatchers\n
  - \n assembler\n
  - \n tail calls\n
  - \n architectures\n
  - \n fun with types\n
  - \n timers\n
  - \n Instruction Set\n
  - \n processor core\n
  - \n accumulator machine\n
  - \n stack machine\n
  - \n register machine\n
  - \n vector machine\n
  \n
- \n Software Machines\n
  - \n memory\n
  \n
\n
\n Functional Programming\n
- \n \n
  - \n Metaprogramming and First-Class Functions\n
  - \n Pure Functions, Expressions, and Recursion\n
  - \n Partial Application and Currying\n
  - \n Lazy Evaluation and Memoization\n
  \n
- \n Functions\n
  - \n The Machine View\n
    - \n Adding Human Readability\n
    - \n Procedures and Functions in Go\n
    \n
  - \n The Mathematical View\n
  - \n Simple Factorials\n
    - \n First-Class and Higher-Order Functions\n
    - \n Closures\n
    - \n Currying\n
    \n
  - \n Recursion\n
    - \n funcs() Which Call Themselves\n
    - \n Mathematical Functions Which Call Themselves\n
    - \n Error Handling the Go Way\n
    - \n Changing Types\n
    \n
  \n
\n
\n Odds & Sods\n
- \n Maps and Hashes\n
  - \n Go maps\n
  - \n A simple Map implementation\n
  \n
- \n Types\n
  - \n Interfaces\n
    - \n Interfaces, pt 1\n
    - \n package adder\n
    \n
  \n
- \n Pretty Pictures\n
  - \n Basic Mandelbrot\n
  \n
- \n Phong Shading\n
- \n Communication by Sharing\n
- \n Concurrency\n
  - \n synchronous\n
  - \n asynchronous\n
  - \n map/reduce\n
  - \n map/reduce\n
  \n
- \n Errors, Exceptions & Flow Control\n
  - \n Catch & Throw\n
  - \n Stack Traces\n
  - \n Exceptions\n
  \n
- \n Duck Typing, Reflection and Type Manipulation\n
  - \n package generalise\n
  - \n raw\n
  \n
- \n Beyond Go\n
  - \n Interfacing with Dynamic Libraries\n
    - \n SQLite 3\n
    - \n Ruby?\n
    \n
  \n
\n

\nIntroducing Go

\n\n

In this section we’re going to explore Go through a series of increasingly complex programs which we can interact with either through the command line or across a network.

\n\n

\nGetting Started

\n\n

If you’re of an impatient nature (my teenage self certainly was) temper that enthusiasm for a second and read Google’s install docs to get your Go install up-and-running. You might also like to install LiteIDE which is an excellent cross-platform development environment for Go which also happens to be written in Go.

\n\n

This book is laid out as a series of parts focused on different topics I’m interested in and the order you read it in is up to you with one clear exception: Hello World is designed as a quick tutorial introduction to Go so if you don’t know the language that’s the place to start. Even if you do know Go you’ll probably find other stuff in Hello World which will be useful as it covers network communications and cryptography.

\n\n

Now Go have fun messing with my code.

\n\n

\nSo what is Go?

\n\n

Well obviously it’s a programming language, which means an artificial language intended for humans to read and write but which can be usefully translated into the 1s and 0s understood by digital computers.

\n\n

But is it a good programming language?

\n\n

Opinion on the internet has been bitterly divided on this question (which is hardly unusual) since Go was released in November 2009 and the language has many detractors who either see it as deficient in some crucial feature without which efficient programs can’t possibly be productively developed, or else as a wholehearted nostalgia trip back into the 1980s by a team who’ve failed to move with the times.

\n\n

So let’s look at the reality and see if these criticisms are justified.

\n\n

\nOpen source

\n\n

Go’s developed as an open source project so anyone with an interest can read through its source code, make modifications for their own purposes, or get involved in its future development. However it’s also a carefully curated project and unlike many popular languages there’s a tightly defined language specification which is intended to be read and understood by anyone working with Go.

\n\n

These are pragmatic choices. Not only do many eyes make light work of code quality, a clear and readable language specification makes it very clear what Go is and isn’t trying to achieve.

\n\n

\nEfficient compilation

\n\n

Work started on the language at Google in 2007 as a way to address three key problems in systems programming.

\n\n

First there’s efficient compilation, the process of taking the source code for a program and turning it into an executable form with a minimum of fuss. As increasingly complex programs are developed in traditional systems languages like C and C++ they become dependent on equally complex build tools and compilation times can stretch into minutes or hours.

\n\n

This isn’t a particularly new phenomenon. The systems I was working on in the 90s often had compile times in the order of 10 to 30 minutes so builds were a great excuse to make a cup of tea whilst waiting to see if things compiled successfully. Still there’s only so many cups of tea you can make in a day and maintain any semblance of productivity.

\n\n

Sadly one of the main reasons for the popularity of interpreted languages like Ruby and Python (both of which have other much more compelling reasons to explore) is the interactive nature of developing with them. This basically allows devs to embrace the same smugness the Lisp crowd exude without the intellectual snobbery or taste the pioneering spirit of Forth without the serious WTF? factor when rereading old code.

\n\n

In interpreted languages small chunks of code can be developed independently of each other and tested immediately. This fast feedback cycle makes it much easier to explore a problem domain and figure out how to work with it effectively (or if we’re lucky elegantly). However interpreted languages have a reputation for being memory hungry and slow.

\n\n

\nEfficient execution

\n\n

This leads us to the second problem Go addresses: efficient execution. Systems programming is all about programs which other programs are going to rely on for key services so it’s highly desirable that languages addressing these problems produce programs which run in a timely fashion and with predictable memory overhead.

\n\n

Compilation provides a huge boost to runtime performance compared to interpretation and the standard Go compiler features a range of optimisations which make it roughly competitive with C++ or Java. And because Go was developed with multi-core processors in mind it uses their resources effectively.

\n\n

One area which raised concerns when Go was first released is its use of garbage collection rather than traditional programmer-controlled memory allocation. Garbage collection used to be a significant cost with 10ms set aside from every 50ms of program execution but in recent years there have been huge improvements by switching to a concurrent design and tailoring this to other features of Go’s design.

\n\n

\nEase of programming

\n\n

The majority of systems languages were designed at a time when memory was limited and processors could generally only execute one instruction at a time (and that glacially slowly by modern standards). As a result these languages provide programmers with very primitive abstractions which no longer even vaguely resemble what’s really going on in most general purpose computers, and to make matters worse they often entail a lot of careful book-keeping just to track memory allocations and prevent leaks which will otherwise cause systems to become unstable.

\n\n

Go was developed after these changes took place by a team with a long history of working on systems software and embraces programmer-friendly conveniences such as garbage collection and CSP concurrency which ease much of this burden. Its design also includes other features which aid ease of programming such as first-class functions, slices, hash maps and structural typing which can greatly simplify code analysis and reuse.

\n\n

We’re going to have a lot of fun with all these features throughout this book.

\n\n

\nAnd where did it come from?

\n\n

Originally Go was developed in-house at Google, a company which thanks to its position in web search and online advertising is heavily tech driven. Google’s systems operate at ROFLscale - a scale which most of us can only dream of messing with - and its codebases measure multiple BLOC (that’s billion lines of code). The aspirations at the heart of Go’s design are essentially attempts to reign in the complexity of numerous codebases scattered throughout Google’s data-centres and written in C++, Python, and Java.

\n\n

The initial development team comprised three industry veterans with a record of both innovation and successful commercial implementation: Ken Thompson, Rob Pike, and Robert Griesemer.

\n\n

Ken Thompson is a legendary hacker, the original creator of UNIX whose B programming language was a strong influence on the design of hacker favourite C. Rob Pike meanwhile was deeply involved with the development of the UNIX, Plan 9 (along with Ken) and Inferno operating systems as well as the Dis virtual machine and a number of programming languages focused on concurrency. Robert Greisemer cut his teeth working on Java’s HotSpot VM and Google’s V8 JavaScript runtime, so between the three of them there’s a wealth of experience in systems software design and performance engineering.

\n\n

At first glance Go is similar to another of Rob’s languages Limbo which he created for the Inferno operating system and it features the CSP approach to concurrency he and Ken had been playing with since their UNIX days. CSP (or Communicating Sequential Processes) was formally defined by British computer scientist Tony Hoare in the late 70s and was key to the technical success of the multi-processor InMos Transputer machines of the 1980s (though it’s programming language Occam was pretty nasty to work with).

\n\n

However Go is a much smaller language than Limbo thanks to a key decision made at the start of the project: no suggested feature would be included in Go unless all three of the core team agreed it should be included. This makes for a highly conservative language design focused on must have features to achieve its stated design goals rather than nice to have features which might be at odds with them. This is quite a departure from the usual feature creep and special pleading seen in other languages.

\n\n

\nInto the wild

\n\n

When Go was first announced to the world on November 10th 2009 it was already a robust language but with a few rough edges like the use of make files for project builds, a weekly source release cycle which often saw package library APIs changing, and some fairly fiddly configuration via environment variables.

\n\n

However key features like the language specification, structural typing, garbage collection, and goroutines were already fixed and a community of passionate users started to grow up around the language. Some of these came from the bifurcating Python scene in search of stability and static typing, others like me had need for a systems language but wanted to keep many of the free-wheeling conveniences we enjoyed in higher-level languages. Then there were the C/C++ and Java devs initially attracted by the reputations of Go’s designers who then stuck around for the fun they could have.

\n\n

Looking back I think all three groups were pulling not only in different directions to each other, but also in different directions to the core team and it’s a testament to the flexibility of Go that a dedicated Rubyist like me can be as comfortable working with it as the most static-typing obsessed escapee from Python or generics-missing Java head.

\n\n

The early buzz around Go wasn’t nearly as loud as TIOBE ratings suggested and the language would probably have remained a curiosity even with Google’s backing if it hadn’t been for the widespread adoption of Docker by the DevOps community.

\n\n

Docker popularised containers, a standardised way of installing and running one or more lightweight virtual machines on a server. These virtual machines aren’t to be confused with the kind used by languages like Java or Erlang (and which form the meat of the software machines section of this book) but are better understood as an outgrowth of UNIX chroot jails based on the resource isolation features present in the Linux kernel. This allows one server to run multiple independent environments each with well-defined privileges and managed resources without requiring the overhead associated with more traditional virtualisation hypervisors like Xen or VMWare.

\n\n

Google themselves are no strangers to containerisation and in 2015 released Kubernetes, an orchestration system for deploying and managing containers across large-scale clusters inspired by a previous in-house tool named Borg. Kubernetes is written in Go and in combination with Docker has helped simplify the once black art of microservice design. Not only are these powerful tools, their use of Go makes them great advertisements for the language.

\n\n

\nWhere next?

\n\n

At the time of writing Go has been in the public eye for nine years. The release of version 1 in March 2012 came with the promise that there’d be no breaking language changes until a version 2 release and since version 1.1 development has followed a tight release schedule focused primarily on improving runtime performance and the standard library. Good software engineering practices aren’t particularly glamorous but the end results are impressive as the garbage collector and goroutine scheduler demonstrate.

\n\n

It’s still far from clear when version 2 of Go will materialise or the extent of any changes to the language which will accompany it. One much-anticipated addition is some kind of support for generic types, the absence of which has been controversial since Go was first released. Generics are one of a number of different ways to enable compile-time metaprogramming and are popular in a number of languages such as C++ and Java, however they generally make the compilation process more complex and trade compile-time cost for runtime efficiency.

\n\n

Go already allows metaprogramming at runtime via its reflection and unsafe APIs with minimal impact on compilation speeds but there is a runtime performance hit for any significant use of reflection which starts to make higher-level interpreted languages look competitive. And thanks to structural typing via interfaces it’s possible to write reasonably generic code based upon capability, though yet again there are runtime costs associated with this approach.

\n\n

Personally I’d like Go version 2 to introduce runtime optimisations for both reflection and structural typing - maybe with some form of JIT compilation. This might well be possible for type switches by using call-site caching and making changes to the reflection API inspired by virtual machine designs.

\n\n

There are also a number of active projects focused on richer compile-time metaprogramming using everything from code templating (the C++ approach) to Lisp-inspired macros. These all involve code generation and subsequent compilation and it would be interesting to see direct compile-time metaprogramming integrated into the language specification.

\n\n

Then there’s enumeration via range statements which could be opened up to a wider selection of user-defined types. Conceptually this could be simple enough: add an interface to the standard library which yields successive elements and allow the compiler to spot this is implemented for a given type. But it’s hard to see how this approach wouldn’t get pretty ugly pretty fast.

\n\n

A possible first step might be to add nodes and lists to the core types defined in the language specification as a analogous abstraction arrays & slices so that at least singly-linked and doubly-linked lists could be used in range statements.

\n\n

Another area where Go could be improved is for mobile development. There’s quite a bit of work that’s gone on in this area over the past few years but Go still isn’t a first-class language on Android or iOS so it would be good to see something official in this direction.

\n\n

Things are much further along with desktop applications such as LiteIDE which uses Qt5 bindings for its cross-platform GUI whilst TinyGo is bringing a decent subset of the language to minimalist embedded devices like the BBC micro:bit. Likewise GopherJS has pioneered Go in the web browser whilst Go version 1.11 now includes experimental support for WebAssembly. There are even bindings for the Vulkan graphics API.

\n\n

So hopefully the version 2 release will make Go a credible language to use all the way from deep embedded systems right the way through to web browser front-ends. Who knows, perhaps we’ll even see some graphically intensive games being developed in Go.

\n\n\n

\nHello World

\n\n

It’s a tradition in programming books to start with a canonical “Hello World” example and whilst I’ve never felt the usual presentation is particularly enlightening, I know we can spice things up a little to provide useful insights into how we write Go programs.

\n\n

Let’s begin with the simplest Go program that will output text to the console.

\n\n\n

Example 1.1.1

1 package main\n2 \n3 func main() {\n4   println(\"hello world\")\n5 }\n

\n\n\n\n\n

The first thing to note is that every Go source file belongs to a package, with the main package defining an executable program whilst all other packages represent libraries.

\n\n\n

1 package main\n

\n\n\n\n\n

For the main package to be executable it needs to include a main() function, which will be called following program initialisation.

\n\n\n

3 func main() {\n

\n\n\n\n\n

Notice that unlike C/C++ the main() function neither takes parameters nor has a return value. Whenever a program should interact with command-line parameters or return a value on termination these tasks are handled using functions in the standard package library. We’ll examine command-line parameters when developing Echo in the next chapter.

\n\n

Finally let’s look at our payload.

\n\n\n

4 println(\"hello world\")\n

\n\n\n\n\n

The println() function is one of a small set of builtin generic functions defined in the language specification and which in this case is usually used to assist debugging, whilst “hello world” is a value comprising an immutable string of characters in utf-8 format.

\n\n

We can now run our program from the command-line (Terminal on MacOS X or Command Prompt on Windows) with the command

\n\n\n

$ go run 01.go\nhello world\n

\n\n\n\n\n

\nPackages

\n\n

Now we’re going to apply a technique which I plan to use throughout this book by taking this simple task and developing increasingly complex ways of expressing it in Go. This runs counter to how experienced programmers usually develop code but I feel this makes for a very effective way to introduce features of Go in rapid succession and have used it with some success during presentations and workshops.

\n\n

There are a number of ways we can artificially complicate our hello world example and by the time we’ve finished I hope to have demonstrated all the features you can expect to see in the global scope of a Go package. Our first change is to remove the builtin println() function and replace it with something intended for production code.

\n\n\n

Example 1.1.2

1 package main\n2 import \"fmt\"\n3 \n4 func main() {\n5   fmt.Println(\"hello world\")\n6 }\n

\n\n\n\n\n

The structure of our program remains essentially the same, but we’ve introduced two new features.

\n\n\n

2 import \"fmt\"\n

\n\n\n\n\n

The import statement is a reference to the fmt package, one of many packages defined in Go’s standard runtime library. A package is a library which provides a group of related functions and data types we can use in our programs. In this case fmt provides functions and types associated with formatting text for printing and displaying it on a console or in the command shell.

\n\n\n

5 fmt.Println(\"hello world\")\n

\n\n\n\n\n

One of the functions provided by fmt is Println() which takes one or more parameters and prints them to the console with a carriage return appended. Go assumes that any identifier starting with a capital letter is part of the public interface of a package whilst identifiers starting with any other letter or symbol are private to the package.

\n\n

In production code we might choose to simplify matters a little by importing the fmt namespace into the namespace of the current source file, which requires we change our import statement.

\n\n\n

2 import . \"fmt\"\n

\n\n\n\n\n

And this consequently allows the explicit package reference to be removed from the Println() function call.

\n\n\n

5 Println(\"hello world\")\n

\n\n\n\n\n

In this case we notice little gain however in later examples we’ll use this feature extensively to keep our code legible.

\n\n\n

Example 1.1.3

1 package main\n2 import . \"fmt\"\n3 \n4 func main() {\n5   Println(\"hello world\")\n6 }\n

\n\n\n\n\n

One aspect of imports that we’ve not yet looked at is Go’s builtin support for code hosted on a variety of popular social code-sharing sites such as GitHub and Google Code. Don’t worry, we’ll get to this in later chapters.

\n\n

\nConstants

\n\n

A significant proportion of Go codebases feature identifiers whose values will not change during the runtime execution of a program and our hello world example is no different, so we’re going to factor these out.

\n\n\n

Example 1.1.4

1 package main\n2 import . \"fmt\"\n3 \n4 const Hello = \"hello\"\n5 const world = \"world\"\n6 \n7 func main() {\n8   Println(Hello, world)\n9 }\n

\n\n\n\n\n

Here we’ve introduced two constants: Hello and world. Each identifier is assigned its value during compilation, and that value cannot be changed at runtime. As the identifier Hello starts with a capital letter the associated constant is visible to other packages - though this isn’t relevant in the context of a main package - whilst the identifier world starts with a lowercase letter and is only accessible within the main package.

\n\n

We don’t need to specify the type of these constants as the Go compiler identifies them both as strings.

\n\n

Another neat trick in Go’s armoury is multiple assignment so let’s see how this looks.

\n\n\n

Example 1.1.5

1 package main\n2 import . \"fmt\"\n3 \n4 const Hello, world = \"hello\", \"world\"\n5 \n6 func main() {\n7   Println(Hello, world)\n8 }\n

\n\n\n\n\n

This is compact, but I personally find it too cluttered and prefer the more general form.

\n\n\n

Example 1.1.6

 1 package main\n 2 import . \"fmt\"\n 3 \n 4 const (\n 5   Hello = \"hello\"\n 6   world =  \"world\"\n 7 )\n 8 \n 9 func main() {\n10   Println(Hello, world)\n11 }\n

\n\n\n\n\n

Because the Println() function is variadic (i.e. can take a varible number of parameters) we can pass it both constants and it will print them on the same line, separate by whitespace. fmt also provides the Printf() function which gives precise control over how its parameters are displayed using a format specifier which will be familiar to seasoned C/C++ programmers.

\n\n\n

10 Printf(\"%v %v\\n\", Hello, world)\n

\n\n\n\n\n

fmt defines a number of % replacement terms which can be used to determine how a particular parameter will be displayed. Of these %v is the most generally used as it allows the formatting to be specified by the type of the parameter. We’ll discuss this in depth when we look at user-defined types, but in this case it will simply replace a %v with the corresponding string.

\n\n

When parsing strings the Go compiler recognises a number of escape sequences which are available to mark tabs, new lines and specific unicode characters. In this case we use \\n to mark a new line.

\n\n\n

Example 1.1.7

 1 package main\n 2 import . \"fmt\"\n 3 \n 4 const (\n 5   Hello = \"hello\"\n 6   world =  \"world\"\n 7 )\n 8 \n 9 func main() {\n10   Printf(\"%v %v\\n\", Hello, world)\n11 }\n

\n\n\n\n\n

\nVariables

\n\n

Constants are useful for referring to values which shouldn’t change at runtime, however most of the time when we’re referencing values in an imperative language like Go we need the freedom to change these values. We associate values which will change with variables. What follows is a simple variation of our Hello World program which allows the value of world to be changed at runtime by creating a new value and assigning it to the world variable.

\n\n\n

Example 1.1.8

 1 package main\n 2 import . \"fmt\"\n 3 \n 4 const Hello = \"hello\"\n 5 var world = \"world\"\n 6 \n 7 func main() {\n 8   world += \"!\"\n 9   Println(Hello, world)\n10 }\n

\n\n\n\n\n

There are two important changes here. Firstly we’ve introduced syntax for declaring a variable and assigning a value to it. Once more Go’s ability to infer type allows us assign a string value to the variable world without explicitly specifying the type.

\n\n\n

5 var world = \"world\"\n

\n\n\n\n\n

However if we wish to be more explicit we can be.

\n\n\n

5 var world string = \"world\"\n

\n\n\n\n\n

Having defined world as a variable in the global scope we can modify its value in main(), and in this case we choose to append an exclamation mark. Strings in Go are immutable values so following the assignment world will reference a new value.

\n\n\n

8 world += \"!\"\n

\n\n\n\n\n

To add some extra interest I’ve chosen to use an augmented assignment operator. These are a syntactic convenience popular in many languages which allow the value contained in a variable to be modified and the resulting value then assigned to the same variable.

\n\n

I don’t intend to expend much effort discussing scope in Go. The point of this book is to experiment and learn by playing with code, referring to the comprehensive language specification available from Google when you need to know the technicalities of a given point. However to illustrate the difference between global and local scope we’ll modify this program further.

\n\n\n

Example 1.1.9

 1 package main\n 2 import . \"fmt\"\n 3 \n 4 const Hello = \"hello\"\n 5 var world = \"world\"\n 6 \n 7 func main() {\n 8   world := world + \"!\"\n 9   Println(Hello, world)\n10 }\n

\n\n\n\n\n

Here we’ve introduced a new local variable world within main() which takes its value from an operation concatenating the value of the global world variable with an exclamation mark. Within main() any subsequent reference to world will always access the local version of the variable without affecting the global world variable. The is known as shadowing.

\n\n

The := operator marks an assignment declaration in which the type of the expression is inferred from the type of the value being assigned. If we chose to declare the local variable separately from the assignment we’d have to give it a different name to avoid a compilation error.

\n\n\n

Example 1.1.10

 1 package main\n 2 import . \"fmt\"\n 3 \n 4 const Hello = \"hello\"\n 5 var world = \"world\"\n 6 \n 7 func main() {\n 8   var w string\n 9   w = world + \"!\"\n10   Println(Hello, w)\n11 }\n

\n\n\n\n\n

Another thing to note in this example is that when w is declared it’s also initialised to the zero value, which in the case of string happens to be ”“. This is a string containing no characters.

\n\n

In fact all variables in Go are initialised to the zero value for their type when they’re declared and this eliminates an entire category of initialisation bugs which could otherwise be difficult to identify.

\n\n

\nFunctions

\n\n

Having looked at how to reference values in Go and how to use the Println() function to display them, it’s only natural to wonder how we can implement our own functions. Obviously we’ve already implemented main() which hints at what’s involved, but main() is something of a special case as it exist to allow a Go program to execute and it neither requires any parameters nor produces any values to be used elsewhere in the program.

\n\n\n

Example 1.1.11

 1 package main\n 2 import . \"fmt\"\n 3 \n 4 const Hello = \"hello\"\n 5 \n 6 func main() {\n 7   Println(Hello, world())\n 8 }\n 9 \n10 func world() string {\n11   return \"world\"\n12 }\n

\n\n\n\n\n

In this example we’ve introduced world(), a function which to the outside world has the same operational purpose as the variable of the same name that we used in the previous section.

\n\n

The empty brackets () indicate that there are no parameters passed into the function when it’s called, whilst string tells us that a single value is returned and it’s of type string. Anywhere that a valid Go program would expect a string value we can instead place a call to world() and the value returned will satisfy the compiler. The use of return is required by the language specification whenever a function specifies return values, and in this case it tells the compiler that the value of world() is the string “world”.

\n\n

Go is unusual in that its syntax allows a function to return more than one value and as such each function takes two sets of (), the first for parameters and the second for results. We could therefore write our function in long form as

\n\n\n

10 func world() (string) {\n11   return \"world\"\n12 }\n

\n\n\n\n\n

In this next example we use a somewhat richer function signature, passing the parameter name which is a string value into the function message(), and assigning the function’s return value to message which is a variable declared and available throughout the function.

\n\n\n

Example 1.1.12

 1 package main\n 2 import \"fmt\"\n 3 \n 4 func main() {\n 5   fmt.Println(message(\"world\"))\n 6 }\n 7 \n 8 func message(name string) (message string) {\n 9   message = fmt.Sprintf(\"hello %v\", name)\n10   return message\n11 }\n

\n\n\n\n\n

As with world() the message() function can be used anywhere that the Go compiler expects to find a string value. However where world() simply returned a predetermined value, message() performs a calculation using the Sprintf() function and returns its result.

\n\n

Sprintf() is similar to Printf() which we met when discussing constants, only rather than create a string according to a format and displaying it in the terminal it instead returns this string as a value which we can assign to a variable or use as a parameter in another function call such as Println().

\n\n

Because we’ve explicitly named the return value we don’t need to reference it in the return statement as each of the named return values is implied.

\n\n\n

Example 1.1.13

 1 package main\n 2 import . \"fmt\"\n 3 \n 4 func main() {\n 5   Println(message(\"world\"))\n 6 }\n 7 \n 8 func message(name string) (message string) {\n 9   message = Sprintf(\"hello %v\", name)\n10   return\n11 }\n

\n\n\n\n\n

If we compare the main() and message() functions, we notice that main() doesn’t have a return statement. Likewise if we define our own functions without return values we can omit the return statement though later we’ll meet examples where we’d still use a return statement to prematurely exit a function.

\n\n\n

Example 1.1.14

 1 package main\n 2 import . \"fmt\"\n 3 \n 4 func main() {\n 5   greet(\"world\")\n 6 }\n 7 \n 8 func greet(name string) {\n 9   Println(\"hello\", name)\n10 }\n

\n\n\n\n\n

In the next example we’ll see what a function which uses multiple return values looks like.

\n\n\n

Example 1.1.15

 1 package main\n 2 import . \"fmt\"\n 3 \n 4 func main() {\n 5   Println(message())\n 6 }\n 7 \n 8 func message() (string, string) {\n 9   return \"hello\", \"world\"\n10 }\n

\n\n\n\n\n

Because message() returns two values we can use it in any context where at least two parameters can be consumed. Println() happens to be a variadic function, which we’ll explain in a moment, and takes zero or more parameters so it happily consumes both of the values message() returns.

\n\n

For our final example we’re going to implement our own variadic function.

\n\n\n

Example 1.1.16

 1 package main\n 2 import . \"fmt\"\n 3 \n 4 func main() {\n 5   print(\"Hello\", \"world\")\n 6 }\n 7 \n 8 func print(v ...interface{}) {\n 9   Println(v...)\n10 }\n

\n\n\n\n\n

We have three interesting things going on here which need explaining. Firstly I’ve introduced a new type, interface{}, which acts as a proxy for any other type in a Go program. We’ll discuss the details of this shortly but for now it’s enough to know that anywhere an interface{} is accepted we can provide a string.

\n\n

In the function signature we use v …interface{} to declare a parameter v which takes any number of values. These are received by print() as a sequence of values and the subsequent call to Println(v…) uses this same sequence as this is the sequence expected by Println().

\n\n

So why did we use …interface{} in defining our parameters instead of the more obvious …string? The Println() function is itself defined as Println(…interface{}) so to provide a sequence of values en masse we likewise need to use …interface{} in the type signature of our function. Otherwise we’d have to create a []interface{} (a slice of interface{} values, a concept we’ll cover in detail in a later chanpter) and copy each individual element into it before passing it into Println().

\n\n

\nEncapsulation

\n\n

In this chapter we’ll for the most part be using Go’s primitive types and types defined in various standard packages without any comment on their structure, however a key aspect of modern programming languages is the encapsulation of related data into structured types and Go supports this via the struct type. A struct describes an area of allocated memory which is subdivided into slots for holding named values, where each named value has its own type. A typical example of a struct in action would be

\n\n\n

Example 1.1.17

 1 package main\n 2 \n 3 import \"fmt\"\n 4 \n 5 type Message struct {\n 6   X string\n 7   y *string\n 8 }\n 9 \n10 func (v Message) Print() {\n11   if v.y != nil {\n12     fmt.Println(v.X, *v.y)\n13   } else {\n14     fmt.Println(v.X)\n15   }\n16 }\n17 \n18 func (v *Message) Store(x, y string) {\n19   v.X = x\n20   v.y = &y\n21 }\n22 \n23 func main() {\n24   m := &Message{}\n25   m.Print()\n26   m.Store(\"Hello\", \"world\")\n27   m.Print()\n28 }\n

\n\n\n\n\n\n

$ go run 17.go\n\nHello world\n

\n\n\n\n\n

Here we’ve defined a struct Message which contains two values: X and y. Go uses a very simple rule for deciding if an identifier is visible outside of the package in which it’s defined which applies to both package-level constants and variables, and type names, methods and fields. If the identifier starts with a capital letter it’s visible outside the package otherwise its private to the package.

\n\n

The Go language spec guarantees that all variables will be initialised to the zero value for their type. For a struct type this means that every field will be initialised to an appropriate zero value. Therefore when we declare a value of type Message the Go runtime will initialise all of its elements to their zero value (in this case a zero-length string and a nil pointer respectively), and likewise if we create a Message value using a literal

\n\n\n

24   m := &Message{}\n

\n\n\n\n\n

Having declared a struct type we can declare any number of method functions which will operate on this type. In this case we’ve introduced Print() which is called on a Message value to display it in the terminal, and Store() which is called on a pointer to a Message value to change its contents. The reason Store() applies to a pointer is that we want to be able to change the contents of the Message and have these changes persist. If we define the method to work directly on the value these changes won’t be propagated outside the method’s scope. To test this for yourself, make the following change to the program

\n\n\n

Example 1.1.18

18 func (v Message) Store(x, y string) {\n

\n\n\n\n\n

If you’re familiar with functional programming then the ability to use values immutably this way will doubtless spark all kinds of interesting ideas.

\n\n

There’s another struct trick I want to show off before we move on and that’s type embedding using an anonymous field. Go’s design has upset quite a few people with an inheritance-based view of object orientation because it lacks inheritance, however thanks to type embedding we’re able to compose types which act as proxies to the methods provided by anonymous fields. As with most things, an example will make this much clearer

\n\n\n

Example 1.1.19 Type Embedding

 1 package main\n 2 \n 3 import \"fmt\"\n 4 \n 5 type HelloWorld struct {}\n 6 \n 7 func (h HelloWorld) String() string {\n 8   return \"Hello world\"\n 9 }\n10 \n11 type Message struct {\n12   HelloWorld\n13 }\n14 \n15 func main() {\n16   m := &Message{}\n17   fmt.Println(m.HelloWorld.String())\n18   fmt.Println(m.String())\n19   fmt.Println(m)\n20 }\n

\n\n\n\n\n\n

$ go run 19.go\nHello world\nHello world\nHello world\n

\n\n\n\n\n

Here we’re declaring a type HelloWorld which in this case is just an empty struct, but which in reality could be any declared type. HelloWorld defines a String() method which can be called on any HelloWorld value. We then declare a type Message which embeds the HelloWorld type by defining an anonymous field of the HelloWorld type. Wherever we encounter a value of type Message and wish to call String() on its embedded HelloWorld value we can do so by calling String() directly on the value, calling String() on the Message value, or in this case by allowing fmt.Println() to match it with the fmt.Stringer interface.

\n\n

Any declared type can be embedded, so in our next example we’re going to base HelloWorld on the primitive bool boolean type to prove the point

\n\n\n

Example 1.1.20 Type Embedding

 1 package main\n 2 import \"fmt\"\n 3 \n 4 type HelloWorld bool\n 5 \n 6 func (h HelloWorld) String() (r string) {\n 7   if h {\n 8     r = \"Hello world\"\n 9   }\n10   return\n11 }\n12 \n13 type Message struct {\n14   HelloWorld\n15 }\n16 \n17 func main() {\n18   m := &Message{ HelloWorld: true }\n19   fmt.Println(m)\n20   m.HelloWorld = false\n21   fmt.Println(m)\n22   m.HelloWorld = true\n23   fmt.Println(m)\n24 }\n

\n\n\n\n\n

In our final example we’ve declared the Hello type and embedded it in Message, then we’ve implemented a new String() method which allows a Message value more control over how it’s printed

\n\n\n

Example 1.1.21 Type Embedding

 1 package main\n 2 import \"fmt\"\n 3 \n 4 type Hello struct {}\n 5 \n 6 func (h Hello) String() string {\n 7   return \"Hello\"\n 8 }\n 9 \n10 type Message struct {\n11   *Hello\n12   World string\n13 }\n14 \n15 func (v Message) String() (r string) {\n16   if v.Hello == nil {\n17     r = v.World\n18   } else {\n19     r = fmt.Sprintf(\"%v %v\", v.Hello, v.World)\n20   }\n21   return\n22 }\n23 \n24 func main() {\n25   m := &Message{}\n26   fmt.Println(m)\n27   m.Hello = new(Hello)\n28   fmt.Println(m)\n29   m.World = \"world\"\n30   fmt.Println(m)\n31 }\n

\n\n\n\n\n\n

$ go run 21.go\n\nHello \nHello world\n

\n\n\n\n\n

\n \n

In all these examples we’ve made liberal use of the * and & operators. An explanation is in order.

\n\n

Go is a systems programming language, and this means that a Go program has direct access to the memory of the platform it’s running on. This requires that Go has a means of refering to specific addresses in memory and of accessing their contents indirectly.

\n\n

The & operator is prepended to the name of a variable or to a value literal when we wish to discover its address in memory, which we refer to as a pointer. To do anything with the pointer returned by the & operator we need to be able to declare a pointer variable which we do by prepending a type name with the * operator. An example will probably make this description somewhat clearer

\n\n\n

Pointers and Addresses

 1 package main\n 2 import . \"fmt\"\n 3 \n 4 type Text string\n 5 \n 6 func main() {\n 7   var name Text = \"Ellie\"\n 8   var pointer_to_name *Text\n 9 \n10   pointer_to_name = &name\n11   Printf(\"name = %v stored at %v\\n\", name, pointer_to_name)\n12   Printf(\"pointer_to_name references %v\\n\", *pointer_to_name)\n13 }\n

\n\n\n\n\n\n

$ go run aside_01.go\nname = Ellie stored at 0x208178170\npointer_to_name references Ellie\n

\n\n\n\n\n

Go allows user-defined types to declare methods on either a value type or a pointer to a value type. When methods operate on a value type the value manipulated remains immutable to the rest of the program (essentially the method operates on a copy of the value) whilst with a pointer to a value type any changes to the value are apparent throughout the program.

\n\n

This has far-reaching implications which we’ll explore in later chapters.

\n\n

\nGeneralisation

\n\n

Encapsulation is of huge benefit when writing complex programs and it also enables one of the more powerful features of Go’s type system, the interface. An interface is similar to a struct in that it combines one or more elements but rather than defining a type in terms of the data items it contains, an interface defines it in terms of a set of method signatures which it must implement.

\n\n\n\n

Once declared an interface can be used just like any other declared type, allowing functions and variables to operate with unknown types based solely on their required behaviour. Go’s type inference system will then recognise compliant values as instances of the interface, allowing us to write generalised code with little fuss.

\n\n

In the next example we’re going to introduce a simple interface (by far the most common kind) which matches any type with a func String() string method signature.

\n\n\n

Example 1.1.22

 1 package main\n 2 import \"fmt\"\n 3 \n 4 type Stringer interface {\n 5   String() string\n 6 }\n 7 \n 8 type Hello struct {}\n 9 \n10 func (h Hello) String() string {\n11   return \"Hello\"\n12 }\n13 \n14 type World struct {}\n15 \n16 func (w *World) String() string {\n17   return \"world\"\n18 }\n19 \n20 type Message struct {\n21   X Stringer\n22   Y Stringer\n23 }\n24 \n25 func (v Message) String() (r string) {\n26   switch {\n27   case v.X == nil && v.Y == nil:\n28   case v.X == nil:\n29     r = v.Y.String()\n30   case v.Y == nil:\n31     r = v.X.String()\n32   default:\n33     r = fmt.Sprintf(\"%v %v\", v.X, v.Y)\n34   }\n35   return\n36 }\n37 \n38 func main() {\n39   m := &Message{}\n40   fmt.Println(m)\n41   m.X = new(Hello)\n42   fmt.Println(m)\n43   m.Y = new(World)\n44   fmt.Println(m)\n45   m.Y = m.X\n46   fmt.Println(m)\n47   m = &Message{ X: new(World), Y: new(Hello) }\n48   fmt.Println(m)\n49   m.X, m.Y = m.Y, m.X\n50   fmt.Println(m)\n51 }\n

\n\n\n\n\n\n

$ go run 22.go\n\nHello\nHello world\nHello Hello\nworld Hello\nHello world\n

\n\n\n\n\n

This interface is copied directly from fmt.Stringer, so we can simplify our code a little by using that interface instead

\n\n\n

Example 1.1.23

17 type Message struct {\n18   X fmt.Stringer\n19   Y fmt.Stringer\n20 }\n

\n\n\n\n\n

As Go is strongly typed interface values contain both a pointer to the value contained in the interface, and the concrete type of the stored value. This allows us to perform type assertions to confirm that the value inside an interface matches a particular concrete type

\n\n\n

Example 1.1.24

 1 package main\n 2 import \"fmt\"\n 3 \n 4 type Hello struct {}\n 5 \n 6 func (h Hello) String() string {\n 7   return \"Hello\"\n 8 }\n 9 \n10 type World struct {}\n11 \n12 func (w *World) String() string {\n13   return \"world\"\n14 }\n15 \n16 type Message struct {\n17   X fmt.Stringer\n18   Y fmt.Stringer\n19 }\n20 \n21 func (v Message) IsGreeting() (ok bool) {\n22   if _, ok = v.X.(*Hello); !ok {\n23     _, ok = v.Y.(*Hello)\n24   }\n25   return\n26 }\n27 \n28 func main() {\n29   m := &Message{}\n30   fmt.Println(m.IsGreeting())\n31   m.X = new(Hello)\n32   fmt.Println(m.IsGreeting())\n33   m.Y = new(World)\n34   fmt.Println(m.IsGreeting())\n35   m.Y = m.X\n36   fmt.Println(m.IsGreeting())\n37   m = &Message{ X: new(World), Y: new(Hello) }\n38   fmt.Println(m.IsGreeting())\n39   m.X, m.Y = m.Y, m.X\n40   fmt.Println(m.IsGreeting())\n41 }\n

\n\n\n\n\n\n

go run 24.go\nfalse\ntrue\ntrue\ntrue\ntrue\ntrue\n

\n\n\n\n\n

Here we’ve replaced Message’s String() method with IsGreeting(), a predicate which uses a pair of type assertions to tell us whether or not one of Message’s data fields contains a value of concrete type Hello.

\n\n

So far in these examples we’ve been using pointers to Hello and World so the interface variables are storing pointers to pointers to these values (i.e. **Hello and **World) rather than pointers to the values themselves (i.e. *Hello and *World). In the case of World we have to do this to comply with the fmt.Stringer interface because String() is defined for *World and if we modify main to assign a World value to either field we’ll get a compile-time error

\n\n\n

Example 1.1.25

29 func main() {\n30   m := &Message{}\n31   fmt.Println(m.IsGreeting())\n32   m.X = Hello{}\n33   fmt.Println(m.IsGreeting())\n34   m.X = new(Hello)\n35   fmt.Println(m.IsGreeting())\n36   m.X = World{}\n37 }\n

\n\n\n\n\n\n

$ go run 25.go\n# command-line-arguments\n./25.go:36: cannot use World literal (type World) as type fmt.Stringer in assignment:\n\tWorld does not implement fmt.Stringer (String method has pointer receiver)\n

\n\n\n\n\n

The final thing to mention about interfaces is that they support embedding of other interfaces. This allows us to compose a new, more restrictive interface based on one or more existing interfaces. Rather than demonstrate this with an example we’re going to look at code lifted directly from the standard io package which does this

\n\n\n

67 type Reader interface {\n68   Read(p []byte) (n int, err error)\n69 }\n

\n\n\n\n\n\n

78 type Writer interface {\n79   Write(p []byte) (n int, err error)\n80 }\n

\n\n\n\n\n\n

106 type ReadWriter interface {\n107   Reader\n108   Writer\n109 }\n

\n\n\n\n\n

Here io is declaring three interfaces, the Reader and Writer which are independent of each other, and the ReadWriter which combines both. Any time we declare a variable, field or function parameter in terms of a ReaderWriter we know we can use both the Read() and Write() methods to manipulate it.

\n\n

\nStartup

\n\n

One of the less-discussed aspects of computer programs is the need to initialise many of them to a pre-determined state before they begin executing. Whilst this is probably the worst place to start discussing what to many people may appear to be advanced topics, one of my goals in this chapter is to cover all of the structural elements that we’ll meet when we examine more complex programs.

\n\n

Every Go package may contain one or more init() functions specifying actions that should be taken during program initialisation. This is the one case I’m aware of where multiple declarations of the same identifier can occur without either resulting in a compilation error or the shadowing of a variable. In the following example we use the init() function to assign a value to our world variable

\n\n\n

Example 1.1.26

 1 package main\n 2 import . \"fmt\"\n 3 \n 4 const Hello = \"hello\"\n 5 var world  string\n 6 \n 7 func init() {\n 8   world = \"world\"\n 9 }\n10 \n11 func main() {\n12   Println(Hello, world)\n13 }\n

\n\n\n\n\n

However the init() function can contain any valid Go code, allowing us to place the whole of our program in init() and leaving main() as a stub to convince the compiler that this is indeed a valid Go program.

\n\n\n

Example 1.1.27

 1 package main\n 2 import . \"fmt\"\n 3 \n 4 const Hello = \"hello\"\n 5 var world  string\n 6 \n 7 func init() {\n 8   world = \"world\"\n 9   Println(Hello, world)\n10 }\n11 \n12 func main() {}\n

\n\n\n\n\n

When there are multiple init() functions the order in which they’re executed is indeterminate so in general it’s best not to do this unless you can be certain the init() functions don’t interact in any way. The following happens to work as expected on my development computer but an implementation of Go could just as easily arrange it to run in reverse order or even leave deciding the order of execution until runtime.

\n\n\n

Example 1.1.28

 1 package main\n 2 import . \"fmt\"\n 3 \n 4 const Hello = \"hello\"\n 5 var world  string\n 6 \n 7 func init() {\n 8   Print(Hello, \" \")\n 9   world = \"world\"\n10 }\n11 \n12 func init() {\n13   Printf(\"%v\\n\", world)\n14 }\n15 \n16 func main() {}\n

\n\n\n\n\n

\nHTTP

\n\n

So far our treatment of Hello World has followed the traditional route of printing a preset message to the console. Anyone would think we were living in the fuddy-duddy mainframe era of the 1970s instead of the shiny 21st Century, when web and mobile applications rule the world.

\n\n

Turning Hello World into a web application is surprisingly simple, as the following example demonstrates.

\n\n\n

Example 1.1.29

 1 package main\n 2 import . \"fmt\"\n 3 import \"net/http\"\n 4 \n 5 const MESSAGE = \"hello world\"\n 6 const ADDRESS = \":1024\"\n 7 \n 8 func main() {\n 9   http.HandleFunc(\"/hello\", Hello)\n10   if e := http.ListenAndServe(ADDRESS, nil); e != nil {\n11     Println(e)\n12   }\n13 }\n14 \n15 func Hello(w http.ResponseWriter, r *http.Request) {\n16   w.Header().Set(\"Content-Type\", \"text/plain\")\n17   Fprintf(w, MESSAGE)\n18 }\n

\n\n\n\n\n\n

$ go run 29.go\n

\n\n\n\n\n

Our web server is now listening on localhost port 1024 (usually the first non-privileged port on most Unix-like operating systems) and if we visit the url http://localhost:1024/hello with a web browser our server will return Hello World in the response body.

\n\n

\"\" — Image 1.29 http://localhost:1024/hello

\n\n\n

The first thing to note is that the net/http package provides a fully-functional web server which requires very little configuration. All we have to do to get our content to the browser is define a handler, which in this case is a function to call whenever an http.Request is received, and then launch a server to listen on the desired address with http.ListenAndServe(). http.ListenAndServe returns an error if it’s unable to launch the server for some reason, which in this case we print to the console.

\n\n

We’re going to import the net/http package into the current namespace and assume our code won’t encounter any runtime errors to make the simplicity even more apparent. If you run into any problems whilst trying the examples which follow, reinserting the if statement will allow you to figure out what’s going on.

\n\n\n

Example 1.1.30

 1 package main\n 2 import . \"fmt\"\n 3 import . \"net/http\"\n 4 \n 5 const MESSAGE = \"hello world\"\n 6 const ADDRESS = \":1024\"\n 7 \n 8 func main() {\n 9   HandleFunc(\"/hello\", Hello)\n10   ListenAndServe(ADDRESS, nil)\n11 }\n12 \n13 func Hello(w ResponseWriter, r *Request) {\n14   w.Header().Set(\"Content-Type\", \"text/plain\")\n15   Fprintf(w, MESSAGE)\n16 }\n

\n\n\n\n\n

HandleFunc() registers a URL in the web server as the trigger for a function, so when a web request targets the URL the associated function will be executed to generate the result. The specified handler function is passed both a ResponseWriter to send output to the web client and the Request which is being replied to. The ResponseWriter is a file handle so we can use the fmt.Fprint() family of file-writing functions to create the response body.

\n\n

Finally we launch the server using ListenAndServe() which will block for as long as the server is active, returning an error if there is one to report.

\n\n

In this example I’ve declared a function Hello and by referring to this in the call to HandleFunc() this becomes the function which is registered. However Go also allows us to define functions anonymously where we wish to use a function value, as demonstrated in the following variation on our theme.

\n\n\n

Example 1.1.31

 1 package main\n 2 import . \"fmt\"\n 3 import . \"net/http\"\n 4 \n 5 const MESSAGE = \"hello world\"\n 6 const ADDRESS = \":1024\"\n 7 \n 8 func main() {\n 9   HandleFunc(\"/hello\", func(w ResponseWriter, r *Request) {\n10     w.Header().Set(\"Content-Type\", \"text/plain\")\n11     Fprintf(w, MESSAGE)\n12   })\n13   ListenAndServe(ADDRESS, nil)\n14 }\n

\n\n\n\n\n

Functions are first-class values in Go and here HandleFunc() is passed an anonymous function value which is created at runtime. This value is a closure so it can also access variables in the lexical scope in which it’s defined. We’ll treat closures in greater depth later in the book, but for now here’s an example which demonstrates their basic premise by defining a variable messages in main() and then accessing it from within the anonymous function.

\n\n\n

Example 1.1.32

 1 package main\n 2 import . \"fmt\"\n 3 import . \"net/http\"\n 4 \n 5 const ADDRESS = \":1024\"\n 6 \n 7 func main() {\n 8   message := \"hello world\"\n 9   HandleFunc(\"/hello\", func(w ResponseWriter, r *Request) {\n10     w.Header().Set(\"Content-Type\", \"text/plain\")\n11     Fprintf(w, message)\n12   })\n13   ListenAndServe(ADDRESS, nil)\n14 }\n

\n\n\n\n\n

This is only a very brief taster of what’s possible using net/http so we’ll conclude by serving our hello world web application over an SSL connection.

\n\n\n

Example 1.1.33

 1 package main\n 2 import . \"fmt\"\n 3 import . \"net/http\"\n 4 \n 5 const SECURE_ADDRESS = \":1025\"\n 6 \n 7 func main() {\n 8   message := \"hello world\"\n 9   HandleFunc(\"/hello\", func(w ResponseWriter, r *Request) {\n10     w.Header().Set(\"Content-Type\", \"text/plain\")\n11     Fprintf(w, message)\n12   })\n13   ListenAndServeTLS(SECURE_ADDRESS, \"cert.pem\", \"key.pem\", nil)\n14 }\n

\n\n\n\n\n

Before we run this program we first need to generate a certificate and a public key, which we can do using crypto/tls/generate_cert.go in the standard package library.

\n\n\n

$ go run $GOROOT/src/pkg/crypto/tls/generate_cert.go -ca=true -host=\"localhost\"\n2014/05/16 20:41:53 written cert.pem\n2014/05/16 20:41:53 written key.pem\n$ go run 33.go\n

\n\n\n\n\n

\"\" — Image 1.33 https://localhost:1025/hello

\n\n\n

\n \n

This is a self-signed certificate, and not all modern web browsers like these. Firefox will refuse to connect on the grounds the certificate is inadequate and not being a Firefox user I’ve not devoted much effort to solving this. Meanwhile both Chrome and Safari will prompt the user to confirm the certificate is trusted. I have no idea how Internet Explorer behaves.

\n\n

For production applications you’ll need a certificate from a recognised Certificate Authority. Traditionally this would be purchased from a company such as Thawte for a fixed period but with the increasing emphasis on securing the web a number of major networking companies have banded together to launch Let’s Encrypt. It’s a free CA issuing short-duration certificates for SSL/TLS with support for automated renewal.

\n\n

If you’re anything like me (and you have my sympathy if you are) then the next thought to idle through your mind will be a fairly obvious question: given that we can serve our content over both HTTP and HTTPS connections, how do we do both from the same program?

\n\n

To answer this we have to know a little - but not a lot - about how to model concurrency in a Go program. The go keyword marks a goroutine which is a lightweight thread scheduled by the Go runtime. How this is implemented under the hood doesn’t matter, all we need to know is that when a goroutine is launched it takes a function call and creates a separate thread of execution for it. Here we’re going to launch a goroutine to run the HTTP server then run the HTTPS server in the main flow of execution.

\n\n\n

Example 1.1.34

 1 package main\n 2 import . \"fmt\"\n 3 import . \"net/http\"\n 4 \n 5 const ADDRESS = \":1024\"\n 6 const SECURE_ADDRESS = \":1025\"\n 7 \n 8 func main() {\n 9   message := \"hello world\"\n10   HandleFunc(\"/hello\", func(w ResponseWriter, r *Request) {\n11     w.Header().Set(\"Content-Type\", \"text/plain\")\n12     Fprintf(w, message)\n13   })\n14 \n15   go func() {\n16     ListenAndServe(ADDRESS, nil)\n17   }()\n18 \n19   ListenAndServeTLS(SECURE_ADDRESS, \"cert.pem\", \"key.pem\", nil)\n20 }\n

\n\n\n\n\n

When I first wrote this code it actually used two goroutines, one for each server. Unfortunately no matter how busy any particular goroutine is, when the main() function returns our program will exit and our web servers will terminate. So I tried the primitive approach we all know and love from C

\n\n\n

10 func main() {\n11   message := \"hello world\"\n12   HandleFunc(\"/hello\", func(w ResponseWriter, r *Request) {\n13     w.Header().Set(\"Content-Type\", \"text/plain\")\n14     Fprintf(w, message)\n15   })\n16 \n17   go func() {\n18     ListenAndServe(ADDRESS, nil)\n19   }()\n20 \n21   go func() {\n22     ListenAndServeTLS(SECURE_ADDRESS, \"cert.pem\", \"key.pem\", nil)\n23   }()\n24 \n25   for {}\n26 }\n

\n\n\n\n\n

Here we’re using an infinite for loop to prevent program termination: it’s inelegant, but this is a small program and dirty hacks have their appeal. Whilst semantically correct this unfortunately doesn’t work either because of the way goroutines are scheduled: the infinite loop can potentially starve the thread scheduler and prevent the other goroutines from running.

\n\n\n

$ go version\ngo version go1.3 darwin/amd64\n

\n\n\n\n\n

In any event an infinite loop is a nasty, unnecessary hack as Go allows concurrent elements of a program to communicate with each other via channels, allowing us to rewrite our code as

\n\n\n

Example 1.1.35

 1 package main\n 2 import . \"fmt\"\n 3 import . \"net/http\"\n 4 \n 5 const ADDRESS = \":1024\"\n 6 const SECURE_ADDRESS = \":1025\"\n 7 \n 8 func main() {\n 9   message := \"hello world\"\n10   HandleFunc(\"/hello\", func(w ResponseWriter, r *Request) {\n11     w.Header().Set(\"Content-Type\", \"text/plain\")\n12     Fprintf(w, message)\n13   })\n14 \n15   done := make(chan bool)\n16   go func() {\n17     ListenAndServe(ADDRESS, nil)\n18     done <- true\n19   }()\n20 \n21   ListenAndServeTLS(SECURE_ADDRESS, \"cert.pem\", \"key.pem\", nil)\n22   <- done\n23 }\n

\n\n\n\n\n

For the next pair of examples we’re going to use two separate goroutines to run our HTTP and HTTPS servers, yet again coordinating program termination with a shared channel. In the first example we’ll launch both of the goroutines from the main() function, which is a fairly typical code pattern

\n\n\n

Example 1.1.36

 1 package main\n 2 import . \"fmt\"\n 3 import . \"net/http\"\n 4 \n 5 const ADDRESS = \":1024\"\n 6 const SECURE_ADDRESS = \":1025\"\n 7 \n 8 func main() {\n 9   message := \"hello world\"\n10   HandleFunc(\"/hello\", func(w ResponseWriter, r *Request) {\n11     w.Header().Set(\"Content-Type\", \"text/plain\")\n12     Fprintf(w, message)\n13   })\n14 \n15   done := make(chan bool)\n16   go func() {\n17     ListenAndServe(ADDRESS, nil)\n18     done <- true\n19   }()\n20 \n21   go func () {\n22     ListenAndServeTLS(SECURE_ADDRESS, \"cert.pem\", \"key.pem\", nil)\n23     done <- true\n24   }()\n25   <- done\n26   <- done\n27 }\n

\n\n\n\n\n

For our second deviation we’re going to launch a goroutine from main() which will run our HTTPS server and this will launch the second goroutine which manages our HTTP server

\n\n\n

Example 1.1.37

 1 package main\n 2 import . \"fmt\"\n 3 import . \"net/http\"\n 4 \n 5 const ADDRESS = \":1024\"\n 6 const SECURE_ADDRESS = \":1025\"\n 7 \n 8 func main() {\n 9   message := \"hello world\"\n10   HandleFunc(\"/hello\", func(w ResponseWriter, r *Request) {\n11     w.Header().Set(\"Content-Type\", \"text/plain\")\n12     Fprintf(w, message)\n13   })\n14 \n15   done := make(chan bool)\n16   go func () {\n17     go func() {\n18       ListenAndServe(ADDRESS, nil)\n19       done <- true\n20     }()\n21 \n22     ListenAndServeTLS(SECURE_ADDRESS, \"cert.pem\", \"key.pem\", nil)\n23     done <- true\n24   }()\n25   <- done\n26   <- done\n27 }\n

\n\n\n\n\n

There’s a certain amount of fragile repetition in this code as we have to remember to explicitly create a channel, and then to send and receive on it multiple times to coordinate execution. As Go provides first-order functions (i.e. allows us to refer to functions the same way we refer to data, assigning instances of them to variables and passing them around as parameters to other functions) we can refactor the server launch code as follows

\n\n\n

Example 1.1.38

 1 package main\n 2 import . \"fmt\"\n 3 import . \"net/http\"\n 4 \n 5 const ADDRESS = \":1024\"\n 6 const SECURE_ADDRESS = \":1025\"\n 7 \n 8 func main() {\n 9   message := \"hello world\"\n10   HandleFunc(\"/hello\", func(w ResponseWriter, r *Request) {\n11     w.Header().Set(\"Content-Type\", \"text/plain\")\n12     Fprintf(w, message)\n13   })\n14 \n15   Spawn(\n16     func() { ListenAndServeTLS(SECURE_ADDRESS, \"cert.pem\", \"key.pem\", nil) },\n17     func() { ListenAndServe(ADDRESS, nil) },\n18   )\n19 }\n20 \n21 func Spawn(f ...func()) {\n22   done := make(chan bool)\n23 \n24   for _, s := range f {\n25     go func() {\n26       s()\n27       done <- true\n28     }()\n29   }\n30 \n31   for l := len(f); l > 0; l-- {\n32     <- done\n33   }\n34 }\n

\n\n\n\n\n

However this doesn’t work as expected, so let’s see if we can get any further insight

\n\n\n

$ go vet 38.go\n38.go:28: range variable s captured by func literal\nexit status 1\n

\n\n\n\n\n

Running go with the vet command runs a set of heuristics against our source code to check for common errors which wouldn’t be caught during compilation. In this case we’re being warned about this code

\n\n\n

26 for _, s := range f {\n27   go func() {\n28     s()\n29     done <- true\n30   }()\n31 }\n

\n\n\n\n\n

Here we’re using a closure so it refers to the variable s in the for..range statement, and as the value of s changes on each successive iteration, so this is reflected in the call s().

\n\n

To demonstrate this we’ll try a variant where we introduce a delay on each loop iteration much greater than the time taken to launch the goroutine.

\n\n\n

Example 1.1.39

 1 package main\n 2 import . \"fmt\"\n 3 import . \"net/http\"\n 4 import \"time\"\n 5 \n 6 const ADDRESS = \":1024\"\n 7 const SECURE_ADDRESS = \":1025\"\n 8 \n 9 func main() {\n10   message := \"hello world\"\n11   HandleFunc(\"/hello\", func(w ResponseWriter, r *Request) {\n12     w.Header().Set(\"Content-Type\", \"text/plain\")\n13     Fprintf(w, message)\n14   })\n15 \n16   Spawn(\n17     func() { ListenAndServeTLS(SECURE_ADDRESS, \"cert.pem\", \"key.pem\", nil) },\n18     func() { ListenAndServe(ADDRESS, nil) },\n19   )\n20 }\n21 \n22 func Spawn(f ...func()) {\n23   done := make(chan bool)\n24 \n25   for _, s := range f {\n26     go func() {\n27       s()\n28       done <- true\n29     }()\n30     time.Sleep(time.Second)\n31   }\n32 \n33   for l := len(f); l > 0; l-- {\n34     <- done\n35   }\n36 }\n

\n\n\n\n\n

When we run this we get the behaviour we expect with both HTTP and HTTPS servers running on their respective ports and responding to browser traffic. However this is hardly an elegant or practical solution and there’s a much better way of achieving the same effect.

\n\n\n

Example 1.1.40format:go

26   for _, s := range f {\n27     go func(server func()) {\n28       server()\n29       done <- true\n30     }(s)\n31   }\n

\n\n\n\n\n

By accepting the parameter server to the goroutine’s closure we can pass in the value of s and capture it so that on successive iterations of the range our goroutines use the correct value.

\n\n

Spawn() is an example of how powerful Go’s support for first-class functions can be, allowing us to run any arbitrary piece of code and wait for it to signal completion. It’s also a variadic function, taking as many or as few functions as desired and setting each of them up correctly.

\n\n

If we now reach for the standard library we discover that another alternative is to use a sync.WaitGroup to keep track of how many active goroutines we have in our program and only terminate the program when they’ve all completed their work. Yet again this allows us to run both servers in separate goroutines and manage termination correctly.

\n\n\n

Example 1.1.41

 1 package main\n 2 import . \"fmt\"\n 3 import . \"net/http\"\n 4 import \"sync\"\n 5 \n 6 const ADDRESS = \":1024\"\n 7 const SECURE_ADDRESS = \":1025\"\n 8 \n 9 func main() {\n10   message := \"hello world\"\n11   HandleFunc(\"/hello\", func(w ResponseWriter, r *Request) {\n12     w.Header().Set(\"Content-Type\", \"text/plain\")\n13     Fprintf(w, message)\n14   })\n15 \n16   var servers sync.WaitGroup\n17   servers.Add(1)\n18   go func() {\n19     defer servers.Done()\n20     ListenAndServe(ADDRESS, nil)\n21   }()\n22 \n23   servers.Add(1)\n24   go func() {\n25     defer servers.Done()\n26     ListenAndServeTLS(SECURE_ADDRESS, \"cert.pem\", \"key.pem\", nil)\n27   }()\n28   servers.Wait()\n29 }\n

\n\n\n\n\n

As there’s a certain amount of redundancy in this, let’s refactor a little by packaging server initiation into a new Launch() function. Launch() takes a parameter-less function and wraps this in a closure which will be launched as a goroutine in a separate thread of execution. Our sync.WaitGroup variable servers has been turned into a global variable to simplify the function signature of Launch(). When we call Launch() we’re freed from the need to manually increment servers prior to goroutine startup, and we use a defer statement to automatically call servers.Done() when the goroutine terminates even in the event that the goroutine crashes.

\n\n\n

Example 1.1.42

 1 package main\n 2 import . \"fmt\"\n 3 import . \"net/http\"\n 4 import \"sync\"\n 5 \n 6 const ADDRESS = \":1024\"\n 7 const SECURE_ADDRESS = \":1025\"\n 8 \n 9 var servers sync.WaitGroup\n10 \n11 func main() {\n12   message := \"hello world\"\n13   HandleFunc(\"/hello\", func(w ResponseWriter, r *Request) {\n14     w.Header().Set(\"Content-Type\", \"text/plain\")\n15     Fprintf(w, message)\n16   })\n17 \n18   Launch(func() {\n19     ListenAndServe(ADDRESS, nil)\n20   })\n21 \n22   Launch(func() {\n23     ListenAndServeTLS(SECURE_ADDRESS, \"cert.pem\", \"key.pem\", nil)\n24   })\n25   servers.Wait()\n26 }\n27 \n28 func Launch(f func()) {\n29   servers.Add(1)\n30   go func() {\n31     defer servers.Done()\n32     f()\n33   }()\n34 }\n

\n\n\n\n\n

\nThe Environment

\n\n

The main shells used with modern operating systems (Linux, OSX, FreeBSD, Windows, etc.) provide a persistent environment which can be queried by running programs, allowing a user to store configuration values in named variables. Go supports reading and writing these variables using the os package functions Getenv() and Setenv().

\n\n

In our next example we’re going to query the environment for the variable SERVE_HTTP which we’ll assume contains the default address on which to serve unencrypted web content.

\n\n\n

Example 1.1.43

 1 package main\n 2 import . \"fmt\"\n 3 import . \"net/http\"\n 4 import \"os\"\n 5 import \"sync\"\n 6 \n 7 const SECURE_ADDRESS = \":1025\"\n 8 \n 9 var address string\n10 var servers sync.WaitGroup\n11 \n12 func init() {\n13   if address = os.Getenv(\"SERVE_HTTP\"); address == \"\" {\n14     address = \":1024\"\n15   }\n16 }\n17 \n18 func main() {\n19   message := \"hello world\"\n20   HandleFunc(\"/hello\", func(w ResponseWriter, r *Request) {\n21     w.Header().Set(\"Content-Type\", \"text/plain\")\n22     Fprintf(w, message)\n23   })\n24 \n25   Launch(func() {\n26     ListenAndServe(address, nil)\n27   })\n28 \n29   Launch(func() {\n30     ListenAndServeTLS(SECURE_ADDRESS, \"cert.pem\", \"key.pem\", nil)\n31   })\n32   servers.Wait()\n33 }\n34 \n35 func Launch(f func()) {\n36   servers.Add(1)\n37   go func() {\n38     defer servers.Done()\n39     f()\n40   }()\n41 }\n

\n\n\n\n\n

Here we’ve defined a global variable address which we set in init() to either the value provided in SERVE_HTTP or a default value “:1024”.

\n\n\n

$ go run 43.go\n

\n\n\n\n\n

\"\" — Image 1.43a http://localhost:1024/hello

\n\n\n\n

$ SERVE_HTTP=\":3030\" go run 43.go\n

\n\n\n\n\n

\"\" — Image 1.43b http://localhost:3030/hello

\n\n\n

If we now extend this further to make the program fully configurable from the environment we arrive at

\n\n\n

Example 1.1.44

 1 package main\n 2 import . \"fmt\"\n 3 import . \"net/http\"\n 4 import \"os\"\n 5 import \"sync\"\n 6 \n 7 var (\n 8   address string\n 9   secure_address string\n10   certificate string\n11   key string\n12 )\n13 var servers sync.WaitGroup\n14 \n15 func init() {\n16   if address = os.Getenv(\"SERVE_HTTP\"); address == \"\" {\n17     address = \":1024\"\n18   }\n19 \n20   if secure_address = os.Getenv(\"SERVE_HTTPS\"); secure_address == \"\" {\n21     secure_address = \":1025\"\n22   }\n23 \n24   if certificate = os.Getenv(\"SERVE_CERT\"); certificate == \"\" {\n25     certificate = \"cert.pem\"\n26   }\n27 \n28   if key = os.Getenv(\"SERVE_KEY\"); key == \"\" {\n29     key = \"key.pem\"\n30   }\n31 }\n32 \n33 func main() {\n34   message := \"hello world\"\n35   HandleFunc(\"/hello\", func(w ResponseWriter, r *Request) {\n36     w.Header().Set(\"Content-Type\", \"text/plain\")\n37     Fprintf(w, message)\n38   })\n39 \n40   Launch(func() {\n41     ListenAndServe(address, nil)\n42   })\n43 \n44   Launch(func() {\n45     ListenAndServeTLS(secure_address, certificate, key, nil)\n46   })\n47   servers.Wait()\n48 }\n49 \n50 func Launch(f func()) {\n51   servers.Add(1)\n52   go func() {\n53     defer servers.Done()\n54     f()\n55   }()\n56 }\n

\n\n\n\n\n\n

$ SERVE_HTTP=\":3030\" SERVE_HTTPS=\":4040\" go run 44.go\n

\n\n\n\n\n

\nHandling Signals

\n\n

If you’ve been running our example in the terminal and wondering how to terminate it without exiting the shell then you probably come from a GUI background and haven’t met control-C and its relatives (or rather you have, but most likely as cut’n’paste shortcuts).

\n\n

Both Windows and Unix-style operating systems have the concept of a signal which can be sent from one process to another, and for historic reasons many of these can be manually entered using a control-key combination. This is a useful convenience but shutting down a production server this way can result in data loss or corruption. However that’s not the case with our Hello World server, so we have an excellent excuse to examine how to catch a termination signal and do something of our own choosing.

\n\n

To listen for signals in Go we use the os/signal package in the standard library, which allows us to register a channel (an atomic queue for transferring messages between goroutines at runtime) on which notifications are to be received using the signal.Notify() function. Which signals will be made available depends largely on which operating system you’re working with and Go provides only two as standard across Windows and Unix: os.Interrupt and os.Kill. Of these os.Interrupt can be sent with control-C whilst os.Kill equates to SIGKILL on *nixen and is usually a non-maskable interrupt, meaning that it terminates execution and will never be received by Notify().

\n\n

In the following example we’re initialising a signal handler at program startup. This consists of a goroutine containing an infinite loop and blocking on a channel of fixed size (in this case able to hold only one element at a time). The signal handler should be trapping the Interrupt and Kill signals. In both cases if we catch the signal we print a message to the console before exiting, however as previously mentioned the Kill signal (which can be sent from another shell session using the kill command) will never be received by our Go code.

\n\n\n

Example 1.1.45

 1 package main\n 2 import . \"fmt\"\n 3 import . \"net/http\"\n 4 import \"os\"\n 5 import \"os/signal\"\n 6 import . \"sync\"\n 7 \n 8 const ADDRESS = \":1024\"\n 9 const SECURE_ADDRESS = \":1025\"\n10 \n11 var servers WaitGroup\n12 \n13 func init() {\n14   go SignalHandler(make(chan os.Signal, 1))\n15 }\n16 \n17 func main() {\n18   message := \"hello world\"\n19   HandleFunc(\"/hello\", func(w ResponseWriter, r *Request) {\n20     w.Header().Set(\"Content-Type\", \"text/plain\")\n21     Fprintf(w, message)\n22   })\n23 \n24   Launch(func() {\n25     ListenAndServe(ADDRESS, nil)\n26   })\n27 \n28   Launch(func() {\n29     ListenAndServeTLS(SECURE_ADDRESS, \"cert.pem\", \"key.pem\", nil)\n30   })\n31   servers.Wait()\n32 }\n33 \n34 func Launch(f func()) {\n35   servers.Add(1)\n36   go func() {\n37     defer servers.Done()\n38     f()\n39   }()\n40 }\n41 \n42 func SignalHandler(c chan os.Signal) {\n43   signal.Notify(c, os.Interrupt)\n44   for s := <- c; ; s = <- c {\n45     switch s {\n46     case os.Interrupt:\n47       Println(\"^C received\")\n48       os.Exit(0)\n49     case os.Kill:\n50       Println(\"SIGKILL received\")\n51       os.Exit(1)\n52     }\n53   }\n54 }\n

\n\n\n\n\n

When we run this in the terminal on a Mac and press control-C we’ll see something like

\n\n\n

$ go run 45.go\n^C^C received\n

\n\n\n\n\n

The key point of signals is that they allow our program to apply its own logic to events. In the following example we’re going to override the Interrupt signal sent by control-C so that the program continues execution. We’re then going to scan for other signals and use these to terminate the program. The syscall package defines a number of os.Signal values which can be detected by Notify() and of these I’ve chosen SIGABRT, SIGTERM and SIGQUIT as plausible termination signals. We’ll treat SIGABRT as an error condition and the other two as clean terminations.

\n\n

Something else to note is that our signal handler is using a standard for loop statement to poll for input from the signal channel and then compare it to the cases of a switch statement. As the signal handler is designed to run for as long as Notify() is receiving signals we can simplify this a little

\n\n\n

Example 1.1.46

45 func SignalHandler(c chan os.Signal) {\n46   signal.Notify(c, os.Interrupt, syscall.SIGABRT, syscall.SIGTERM, syscall.SIGQUIT)\n47   for s := <- c; ; s = <- c {\n48     switch s {\n49     case os.Interrupt:\n50       Println(\"interrupt - continue running\")\n51     case syscall.SIGABRT:\n52       Println(\"abnormal exit\")\n53       os.Exit(1)\n54     case syscall.SIGTERM, syscall.SIGQUIT:\n55       Println(\"clean shutdown\")\n56       os.Exit(0)\n57     }\n58   }\n59 }\n

\n\n\n\n\n\n

$ go build 46.go\n$ ./46\n^Cinterrupt - continue running\n^Cinterrupt - continue running\n^\\clean shutdown\n

\n\n\n\n\n

We can send a SIGABRT signal using the kill command in a subshell and force our program to terminate abnormally

\n\n\n

$ go build 46.go\n$ ./46\n^Z\n[1]+  Stopped                 go run 46.go\n$ ps\n  PID TTY           TIME CMD\n41097 ttys016    0:00.48 -bash\n58713 ttys016    0:00.10 go run 46.go\n58716 ttys016    0:00.01 /var/folders/25/ybgksr451vxf78xk1svymm5c0000gn/T/go-build543807549/command-li\\\nne-arguments/_obj/exe/46\n57608 ttys017    0:00.08 -bash\n$ kill -SIGABRT 58716\n$ fg\ngo run 46.go\nabnormal exit\nexit status 1\n

\n\n\n\n\n

So far we’ve looked at how our program receives signals, however it’s also possible to send signals. For now we’re going to focus on sending a SIGABRT signal from our program to itself when there’s an error launching one of the servers, in this case by setting ADDRESS and SECURE_ADDRESS to the same value.

\n\n\n

Example 1.1.47

 1 package main\n 2 import . \"fmt\"\n 3 import . \"net/http\"\n 4 import \"os\"\n 5 import \"os/signal\"\n 6 import . \"sync\"\n 7 import \"syscall\"\n 8 \n 9 const ADDRESS = \":1024\"\n10 const SECURE_ADDRESS = \":1024\"\n11 \n12 var servers WaitGroup\n13 \n14 func init() {\n15   go SignalHandler(make(chan os.Signal, 1))\n16 }\n17 \n18 func main() {\n19   message := \"hello world\"\n20   HandleFunc(\"/hello\", func(w ResponseWriter, r *Request) {\n21     w.Header().Set(\"Content-Type\", \"text/plain\")\n22     Fprintf(w, message)\n23   })\n24 \n25   Launch(\"HTTP\", func() error {\n26     return ListenAndServe(ADDRESS, nil)\n27   })\n28 \n29   Launch(\"HTTPS\", func() error {\n30     return ListenAndServeTLS(SECURE_ADDRESS, \"cert.pem\", \"key.pem\", nil)\n31   })\n32   servers.Wait()\n33 }\n34 \n35 func Launch(name string, f func() error) {\n36   servers.Add(1)\n37   go func() {\n38     defer servers.Done()\n39     if e := f(); e != nil {\n40       Println(name, \"->\", e)\n41       syscall.Kill(syscall.Getpid(), syscall.SIGABRT)\n42     }\n43   }()\n44 }\n45 \n46 func SignalHandler(c chan os.Signal) {\n47   signal.Notify(c, os.Interrupt, syscall.SIGABRT, syscall.SIGTERM, syscall.SIGQUIT)\n48   for s := <- c; ; s = <- c {\n49     switch s {\n50     case syscall.SIGABRT:\n51       Println(\"abnormal exit\")\n52       os.Exit(1)\n53     case os.Interrupt, syscall.SIGTERM, syscall.SIGQUIT:\n54       Println(\"clean shutdown\")\n55       os.Exit(0)\n56     }\n57   }\n58 }\n

\n\n\n\n\n

We’ve modified our Launch() function to take a name which can be displayed as part of an error message, and its function parameter now has the signature func() error which specifies that it must return an error value, which is what’s returned by both ListenAndServe() and ListenAndServeTLS(). In the event the error (which is a predeclared interface) contains a value then we know an error condition’s occurred and can send a SIGABRT signal with syscall.Kill(). As Kill() is able to send signals to any running process we need to specify the ID of the current process, which we find using syscall.Getpid().

\n\n\n

$ go run 47.go\n2014/06/25 14:42:25 HTTPS -> listen tcp :1024: bind: address already in use\nabnormal exit\nexit status 1\n

\n\n\n\n\n

\nTCP/IP

\n\n

Printing text in a web browser is a cool trick, but what of real network programming? You know, the kind that bearded sandle-wearing *nix hackers go in for? It turns out this is surprisingly simple

\n\n\n

Example 1.1.48 TCP/IP server

 1 package main\n 2 import . \"fmt\"\n 3 import \"net\"\n 4 \n 5 func main() {\n 6   if listener, e := net.Listen(\"tcp\", \":1024\"); e == nil {\n 7     for {\n 8       if connection, e := listener.Accept(); e == nil {\n 9         go func(c net.Conn) {\n10           defer c.Close()\n11           Fprintln(c, \"hello world\")\n12         }(connection)\n13       }\n14     }\n15   }\n16 }\n

\n\n\n\n\n

The net package revolves around server the Listener and client Connection types. A Listener is an interface which allows any type implementing its specified methods - Accept(), Close() and Addr() - to be used interchangeably and is a key tool in Go for generalising program design. Writing a server then becomes a simple process of

\n\n

- Listen() on a specified protocol and port number
- Accept() incoming connections
- for each net.Conn, run a handler in a separate goroutine
- read from and write to the connection whilst performing work
- close each connection when it finishes its work

\n\n

Here we start to see some of the power of interfaces as a net.Conn implements the Writer interface defined in the io package, and fmt.Fprintf() takes any type which integrates io.Writer as its target.

\n\n

Moving away from HTTP means abandoning the browser for testing but both *nix and Windows have a handy command-line utility called telnet which allows us to connect directly to a TCP/IP server and interact with it. We’ll get into the interaction side of things later in the book, for now here’s an example run of our program.

\n\n\n

$ go run 48.go &\n[1] 17415\n$ telnet localhost 1024\nTrying 127.0.0.1...\nConnected to localhost.\nEscape character is '^]'.\nhello world\nConnection closed by foreign host.\n

\n\n\n\n\n

Telnet’s a useful tool, but it’d be nice if we could connect our own client to the server as this could then be built for any platform supported by Go. For stream-oriented protocols like TCP/IP we do this using the net.Dial() function to open a net.Conn connection to a server and we can then interact with this using the io.Reader and io.Writer interfaces. These interfaces are supported throughout the Go standard package library, allowing files and streaming connections to be used interchangeably.

\n\n\n

Example 1.1.49 TCP/IP client

 1 package main\n 2 import \"bufio\"\n 3 import . \"fmt\"\n 4 import \"net\"\n 5 \n 6 func main() {\n 7   if connection, e := net.Dial(\"tcp\", \":1024\"); e == nil {\n 8     defer connection.Close()\n 9     if text, e := bufio.NewReader(connection).ReadString('\\n'); e == nil {\n10       Printf(text)\n11     }\n12   }\n13 }\n

\n\n\n\n\n

Because a net.Conn represents streams of data flowing between client and server we’ve introduced the bufio package to our client so that the data it’s receiving is buffered. This avoids our having to write our own code for buffering incoming data and is another example of the flexibility Go’s interfaces provide.

\n\n\n

$ go run 48.go &\n[1] 6102\n$ go run 49.go\nhello world\n$ go run 49.go\nhello world\n

\n\n\n\n\n

Most books on network programming tend to stop at vanilla TCP/IP and leave figuring out how to establish a secure connection between client and server as an exercise for the reader. However we’re not likely to get another chance to look at this problem with the same lack of clutter that Hello World provides, and anyway we know how to generate a key and a certificate from our HTTPS adventure so we might as well reuse the knowledge. This time we’re going to need two sets of keys so let’s take care of that first

\n\n\n

$ cp cert.pem server.cert.pem\n$ cp key.pem server.key.pem\n$ go run $GOROOT/src/pkg/crypto/tls/generate_cert.go -ca=true -host=\"localhost\"\n2014/05/16 20:41:53 written cert.pem\n2014/05/16 20:41:53 written key.pem\n$ cp cert.pem client.cert.pem\n$ cp key.pem client.key.pem\n

\n\n\n\n\n

Now we have our keys sorted, let’s take a look at what a TCP/IP server looks like in Go

\n\n\n

Example 1.1.50 TCP/IP server with tls

 1 package main\n 2 import \"crypto/rand\"\n 3 import \"crypto/tls\"\n 4 import . \"fmt\"\n 5 \n 6 func main() {\n 7   if certificate, e := tls.LoadX509KeyPair(\"server.cert.pem\", \"server.key.pem\"); e == nil {\n 8     config := tls.Config{\n 9       Certificates: []tls.Certificate{ certificate },\n10       Rand: rand.Reader,\n11     }\n12 \n13     if listener, e := tls.Listen(\"tcp\", \":1025\", &config); e == nil {\n14       for {\n15         if connection, e := listener.Accept(); e == nil {\n16           go func(c *tls.Conn) {\n17             defer c.Close()\n18             Fprintln(c, \"hello world\")\n19           }(connection.(*tls.Conn))\n20         }\n21       }\n22     }\n23   }\n24 }\n

\n\n\n\n\n

Importing crypto/tls provides us with an equivalent API to that defined in net and this means that as tls.Listen() fulfils the net.Listener interface our connections will be of type net.Conn. As a result if we want to pass the connection around inside our code we either have to import net so we can use net.Conn or perform a type assertion to use the connection as a *tls.Conn. We’ve made the latter choice here.

\n\n\n

18   if connection, e := listener.Accept(); e == nil {\n19     go func(c *tls.Conn) {\n20       defer c.Close()\n21       Fprintln(c, \"hello world\")\n22     }(connection.(*tls.Conn))\n23   }\n

\n\n\n\n\n

For a server we import crypto/rand to access rand.Reader, a cryptographically secure pseudo-random number generator which we’ll be using as a source of randomness in the TLS connection. We then create a certificate using tls.LoadX509KeyPair() to load the server key pair and if this is successful then we set up a listener to accept incoming connections and write “Hello World” to a client.

\n\n

As we’re using TLS we can’t test this version of Hello World using telnet so instead we need to write a client. Yet again this requires a keypair and where in our previous client we called net.Dial() we now use tls.Dial(), resulting in a very similar program.

\n\n\n

Example 1.1.51 TCP/IP client with tls

 1 package main\n 2 import \"bufio\"\n 3 import \"crypto/tls\"\n 4 import . \"fmt\"\n 5 \n 6 func main() {\n 7   if certificate, e := tls.LoadX509KeyPair(\"client.cert.pem\", \"client.key.pem\"); e == nil {\n 8     config := tls.Config{\n 9       Certificates: []tls.Certificate{ certificate },\n10       InsecureSkipVerify: true,\n11     }\n12 \n13     if connection, e := tls.Dial(\"tcp\", \":1025\", &config); e == nil {\n14       defer connection.Close()\n15       if text, e := bufio.NewReader(connection).ReadString('\\n'); e == nil {\n16         Printf(text)\n17       }\n18     }\n19   }\n20 }\n

\n\n\n\n\n\n

$ go run 50.go &\n[1] 6107\n$ go run 51.go\nhello world\n$ go run 51.go\nhello world\n

\n\n\n\n\n

Looking back at our HTTP experiments, we were able to write a program which served over both HTTP and HTTPS connections. It’d be nice to do something similar with TCP/IP, if only to compare the two code-paths.

\n\n\n

Example 1.1.52 TCP/IP dual-mode server

 1 package main\n 2 import \"crypto/rand\"\n 3 import \"crypto/tls\"\n 4 import . \"fmt\"\n 5 import \"net\"\n 6 import \"sync\"\n 7 \n 8 var servers sync.WaitGroup\n 9 \n10 func main() {\n11   if listener, e := net.Listen(\"tcp\", \":1024\"); e == nil {\n12     Serve(listener)\n13   }\n14 \n15   Serve(TLSListener(\"server.cert.pem\", \"server.key.pem\", \":1025\"))\n16   servers.Wait()\n17 }\n18 \n19 func TLSListener(cert, key, address string) (r net.Listener) {\n20   if certificate, e := tls.LoadX509KeyPair(cert, key); e == nil {\n21     config := tls.Config{\n22       Certificates: []tls.Certificate{ certificate },\n23       Rand: rand.Reader,\n24     }\n25     if listener, e := tls.Listen(\"tcp\", address, &config); e == nil {\n26       r = listener\n27     }\n28   }\n29   return\n30 }\n31 \n32 func Serve(listener net.Listener) {\n33   if listener != nil {\n34     Launch(func() {\n35       for {\n36         if connection, e := listener.Accept(); e == nil {\n37           go func(c net.Conn) {\n38             defer c.Close()\n39             Fprintln(c, \"hello world\")\n40           }(connection)\n41         }\n42       }\n43     })\n44   }\n45 }\n46 \n47 func Launch(f func()) {\n48   servers.Add(1)\n49   go func() {\n50     defer servers.Done()\n51     f()\n52   }()\n53 }\n

\n\n\n\n\n

We’ve reused Launch() from Example 1.33 to manage the lifecycle of our two server goroutines and introduced Serve() to phrase the server behaviour in terms of the net.Listener interface. We then move all the setup code for creating a tls.Listener into a separate function TLSListener() which returns a net.Listener value as tls.Listener complies with its interface, or a nil value if tls.Listen() returns an error.

\n\n

If we now run this server we can connect to it with both of our client programs.

\n\n\n

$ go run 52.go &\n[1] 6278\n$ go run 49.go\nhello world\n$ go run 51.go\nhello world\n$ go run 51.go\nhello world\n$ go run 49.go\nhello world\n

\n\n\n\n\n

\nUDP

\n\n

Both TCP/IP and HTTP communications are connection-oriented and this involves a reasonable amount of handshaking and error-correction to assemble data packets in the correct order. For most applications this is exactly how we want to organise our network communications but sometimes the size of our messages is sufficiently small that we can fit them into individual packets, and when this is the case the UDP protocol is an ideal candidate.

\n\n

As with our previous examples we still need both server and client applications.

\n\n\n

Example 1.1.53 UDP server

 1 package main\n 2 import . \"fmt\"\n 3 import \"net\"\n 4 \n 5 var HELLO_WORLD = ([]byte)(\"Hello World\\n\")\n 6 \n 7 func main() {\n 8   if address, e := net.ResolveUDPAddr(\"udp\", \":1024\"); e == nil {\n 9     if server, e := net.ListenUDP(\"udp\", address); e == nil {\n10       for buffer := MakeBuffer(); ; buffer = MakeBuffer() {\n11         if n, client, e := server.ReadFromUDP(buffer); e == nil {\n12           go func(c *net.UDPAddr, packet []byte) {\n13             if n, e := server.WriteToUDP(HELLO_WORLD, c); e == nil {\n14               Printf(\"%v bytes written to: %v\\n\", n, c)\n15             }\n16           }(client, buffer[:n])\n17         }\n18       }\n19     }\n20   }\n21 }\n22 \n23 func MakeBuffer() (r []byte) {\n24   return make([]byte, 1024)\n25 }\n

\n\n\n\n\n

We have a somewhat more complex code pattern here than with TCP/IP to take account of the difference in underlying semantics: UDP is an unreliable transport dealing in individual packets (datagrams) which are independent of each other, therefore a server doesn’t maintain streams to any of its clients and these are responsible for any error-correction or packet ordering which may be necessary to coordinate successive signals. Because of these differences from TCP/IP we end up with the following generic workflow

\n\n

- net.ResolveUDPAddr() to resolve the address
- net.ListenUDP() opens a UDP port and listens for traffic
- net.ReadFromUDP() copies incoming data into a buffer and provides the remote client’s address
- net.WriteToUDP() writes data back to the remote client’s address

\n\n

For trivial uses of UDP we could probably forego the use of a separate goroutine to process each received packet, and indeed we may also have an application architecture where instead of processing the packet we’d hand it off to a message queue elsewhere. However many real-world examples such as serving DNS requests may introduce appreciable delays for processing and by using goroutines we ensure the server itself isn’t stalled.

\n\n

Here our main overhead is the cost of buffer allocation as we use a different data buffer for each request. In a real-world example we’d very likely introduce a buffer pool which would expand and contract with demand, and reuse individual buffers once their associated request has completed. This is surprisingly simple to implement in Go and we’ll look at this in detail in a later chapter.

\n\n

Our client has the same basic boilerplate as the server, only we use net.DialUDP() to set up a connection. We could use net.ReadFromUDP() and net.WriteToUDP() however as a net.UDPConn connection implements the io.ReadWriter interface we can use bufio.Reader to manage reading, and for writes the connection already knows the server address. As the server only knows about clients by receiving data from them we start our interaction with a UDPConn.Write() and then perform the buffered ReadString() to get a response.

\n\n\n

Example 1.1.54 UDP client

 1 package main\n 2 import \"bufio\"\n 3 import . \"fmt\"\n 4 import \"net\"\n 5 \n 6 var CRLF = ([]byte)(\"\\n\")\n 7 \n 8 func main() {\n 9   if address, e := net.ResolveUDPAddr(\"udp\", \":1024\"); e == nil {\n10     if server, e := net.DialUDP(\"udp\", nil, address); e == nil {\n11       defer server.Close()\n12       if _, e = server.Write(CRLF); e == nil {\n13         if text, e := bufio.NewReader(server).ReadString('\\n'); e == nil {\n14           Printf(\"%v\", text)\n15         }\n16       }\n17     }\n18   }\n19 }\n

\n\n\n\n\n

Let’s give this a test run in the shell.

\n\n\n

$ go run 53.go &\n[2] 12777\n$ go run 54.go\n12 bytes written to: 127.0.0.1:58015\nHello World\n$ go run 54.go\n12 bytes written to: 127.0.0.1:50159\nHello World\n$ go run 54.go\n12 bytes written to: 127.0.0.1:51813\nHello World\n

\n\n\n\n\n

Note how each time we run the client program it’s assigned a different network port by the operating system each time net.DialUDP is called.

\n\n\n\n

We can make this apparent by performing multiple sequences of Write() and Read() operations

\n\n\n

Example 1.1.55 UDP client

 1 package main\n 2 import \"bufio\"\n 3 import . \"fmt\"\n 4 import \"net\"\n 5 \n 6 var CRLF = ([]byte)(\"\\n\")\n 7 \n 8 func main() {\n 9   if address, e := net.ResolveUDPAddr(\"udp\", \":1024\"); e == nil {\n10     if server, e := net.DialUDP(\"udp\", nil, address); e == nil {\n11       defer server.Close()\n12       for i := 0; i < 3; i++ {\n13         if _, e = server.Write(CRLF); e == nil {\n14           if text, e := bufio.NewReader(server).ReadString('\\n'); e == nil {\n15             Printf(\"%v: %v\", i, text)\n16           }\n17         }\n18       }\n19     }\n20   }\n21 }\n

\n\n\n\n\n\n

$ go run 53.go &\n[1] 12883\n$ go run 55.go\n12 bytes written to: 127.0.0.1:51732\n0: Hello World\n12 bytes written to: 127.0.0.1:51732\n1: Hello World\n12 bytes written to: 127.0.0.1:51732\n2: Hello World\n$ go run 55.go\n12 bytes written to: 127.0.0.1:55504\n0: Hello World\n12 bytes written to: 127.0.0.1:55504\n1: Hello World\n12 bytes written to: 127.0.0.1:55504\n2: Hello World\n

\n\n\n\n\n

\nRSA obfuscated UDP

\n\n

With all of our network examples to date we’ve included a secure transport option, but UDP doesn’t have a secured mode so we appear stuck with sending our message unencrypted for all the world to see. This is fine for a message such as Hello World which we’re happy for intervening network nodes to observe, but what if we want to send confidential data in our UDP packet?

\n\n

In the following example we’re going to use our existing client RSA key-pair by sending the public key to our server which will then encrypt the message with this key and send it back to the client. The client already possesses the RSA private key so it’s a simple task to decrypt the message and display it. When we send the public key we could do so in a number of different formats: as an RSA pem file; as a raw binary buffer; or, serialised in some form. As both client and server are written in Go we’ll opt for the serialisation format provided in package gob. This is a pragmatic choice as if we were to send a pem file then that’d make it obvious that we’re using an encrypted format, and if we use a raw binary buffer we’d have to include a discussion of Go’s unsafe and reflection packages which are covered later in this book.

\n\n\n

Example 1.1.56 RSA-enabled UDP server

 1 package main\n 2 import \"bytes\"\n 3 import \"crypto/rand\"\n 4 import \"crypto/rsa\"\n 5 import \"crypto/sha1\"\n 6 import \"encoding/gob\"\n 7 import . \"fmt\"\n 8 import . \"net\"\n 9 \n10 var HELLO_WORLD = []byte(\"Hello World\")\n11 var RSA_LABEL = []byte(\"served\")\n12 \n13 func main() {\n14   Serve(\":1025\", func(connection *UDPConn, c *UDPAddr, packet *bytes.Buffer) (n int) {\n15     var key rsa.PublicKey\n16     if e := gob.NewDecoder(packet).Decode(&key); e == nil {\n17       if response, e := rsa.EncryptOAEP(sha1.New(), rand.Reader, &key, HELLO_WORLD, RSA_LABEL); e == n\\\n18 il {\n19         n, _ = connection.WriteToUDP(response, c)\n20       }\n21     }\n22     return\n23   })\n24 }\n25 \n26 func Serve(address string, f func(*UDPConn, *UDPAddr, *bytes.Buffer) int) {\n27   Launch(address, func(connection *UDPConn) {\n28     for {\n29       buffer := make([]byte, 1024)\n30       if n, client, e := connection.ReadFromUDP(buffer); e == nil {\n31         go func(c *UDPAddr, b []byte) {\n32           if n := f(connection, c, bytes.NewBuffer(b)); n != 0 {\n33             Println(n, \"bytes written to\", c)\n34           }\n35         }(client, buffer[:n])\n36       }\n37     }\n38   })\n39 }\n40 \n41 func Launch(address string, f func(*UDPConn)) {\n42   if a, e := ResolveUDPAddr(\"udp\", address); e == nil {\n43     if server, e := ListenUDP(\"udp\", a); e == nil {\n44       f(server)\n45     }\n46   }\n47 }\n

\n\n\n\n\n

So, the first thing of note is that we’ve refactored connection management into Serve() to make the server code easier to follow, and then we’re passing a function literal into this with the tasks to be performed each time a client connects. For now this is a quick hack so we’re not launching Serve() in its own goroutine with all the extra boilerplate for sync.WaitGroup which we’ve seen in previous examples. However we are spawning a separate goroutine for each packet received so that the server doesn’t block, and as an added bonus each time data is written to a client the number of bytes transferred is logged.

\n\n

For each connection we read the client’s message which we know should be a valid public key in gob format. To decode this we create a gob.Decoder with the message as its base, then Decode() this to get a valid rsa.PublicKey which we then use to encrypt our message with rsa.EncryptOAEP(). The main thing to note here is that RSA_LABEL is a parameter which must be set the same for both rsa.EncryptOAEP() and rsa.DecryptOAEP() for the message to be correctly read by the latter. There’s no reason why this couldn’t be configured on a per-connection basis.

\n\n

Now, let’s take a look at our client application

\n\n\n

Example 1.1.57 RSA-enabled UDP client

 1 package main\n 2 import \"bytes\"\n 3 import \"crypto/rand\"\n 4 import \"crypto/rsa\"\n 5 import \"crypto/sha1\"\n 6 import \"crypto/x509\"\n 7 import \"encoding/gob\"\n 8 import \"encoding/pem\"\n 9 import \"io/ioutil\"\n10 import . \"fmt\"\n11 import . \"net\"\n12 \n13 var RSA_LABEL = []byte(\"served\")\n14 \n15 func main() {\n16   Connect(\":1025\", func(server *UDPConn, private_key *rsa.PrivateKey) {\n17     cipher_text := MakeBuffer()\n18     if n, e := server.Read(cipher_text); e == nil {\n19       if plain_text, e := rsa.DecryptOAEP(sha1.New(), rand.Reader, private_key, cipher_text[:n], RSA_L\\\n20 ABEL); e == nil {\n21         Println((string)(plain_text))\n22       }\n23     }\n24   })\n25 }\n26 \n27 func Connect(address string, f func(*UDPConn, *rsa.PrivateKey)) {\n28   LoadPrivateKey(\"client.key.pem\", func(private_key *rsa.PrivateKey) {\n29     if address, e := ResolveUDPAddr(\"udp\", \":1025\"); e == nil {\n30       if server, e := DialUDP(\"udp\", nil, address); e == nil {\n31         defer server.Close()\n32         SendKey(server, private_key.PublicKey, func() {\n33           f(server, private_key)\n34         })\n35       }\n36     }\n37   })\n38 }\n39 \n40 func LoadPrivateKey(file string, f func(*rsa.PrivateKey)) {\n41   if file, e := ioutil.ReadFile(file); e == nil {\n42     if block, _ := pem.Decode(file); block != nil {\n43       if block.Type == \"RSA PRIVATE KEY\" {\n44         if key, _ := x509.ParsePKCS1PrivateKey(block.Bytes); key != nil {\n45           f(key)\n46         }\n47       }\n48     }\n49   }\n50   return\n51 }\n52 \n53 func SendKey(server *UDPConn, public_key rsa.PublicKey, f func()) {\n54   var encoded_key bytes.Buffer\n55   if e := gob.NewEncoder(&encoded_key).Encode(public_key); e == nil {\n56     if _, e = server.Write(encoded_key.Bytes()); e == nil {\n57       f()\n58     }\n59   }\n60 }\n61 \n62 func MakeBuffer() (r []byte) {\n63   return make([]byte, 1024)\n64 }\n

\n\n\n\n\n\n

$ go run 56.go &\n[1] 66945\n$ go run 57.go\n256 bytes written to 127.0.0.1:51328\nHello World\n$ go run 57.go\n256 bytes written to 127.0.0.1:64834\nHello World\n$ go run 57.go\n256 bytes written to 127.0.0.1:50982\nHello World\n

\n\n\n\n\n

The most obvious thing about this code is the heavy use of function literals, giving it a clean compositional feel. This is an aesthetic I picked up working with Ruby and which I always missed when dipping back into C or other low-level languages, so expect to variations on this style in later chapters.

\n\n

Connect() is the client version of Serve(), abstracting away the details of contacting a UDP server, and the meat of our program’s interaction is a simple Read() of an encrypted message from the server which is then decrypted using rsa.DecryptOAEP() and displayed. Before our code initiates the connection though we need it to load an RSA key-pair so we can transmit our public key to the server. We do this in LoadPrivateKey() which uses ioutil.ReadFile() to load a PEM-encoded file into memory and ensure it contains a private key before invoking a function passed to it as a parameter. In this case the passed function sets up the connection, sends the public key to the server and then invokes the function passed to Connect() in SendKey().

\n\n

To keep SendKey() as generic as possible it takes a parameterless function which is basically just a closure into the caller’s environment. In the case of Connect() the closure we pass to SendKey() binds to the server and private_key variables.

\n\n

\nError Handling

\n\n

The examples in this chapter are for the most part designed to follow the happy path as our interest is in seeing some simple Go code that we can later build upon. The one obvious exception was when we explored signal handling and used the presence of an error as an excuse to send a SIGABRT to terminate the server. However error-handling is a large part of most real-world programming - especially in a system level language.

\n\n

Go takes a typically pragmatic approach to error handling, the language specification defining the error type as a predeclared interface

\n\n\n

type error interface {\n\tError() string\n}\n

\n\n\n\n\n

In the following example we’re going to rewrite our encrypted UDP server from example 1.56 so that start-up errors cause the server to terminate and signal an error to the shell whilst client errors will log an appropriate message for later analysis using the log package. The default behaviour of the log package is to write its output to stderr so it integrates well with traditional *nix tools and infrastructure.

\n\n

Whilst our program is still trivial in purpose, we now have all the basic conveniences for running a scalable server and integrating it with third-party monitoring and logging tools at deployment.

\n\n\n

Example 1.1.58

 1 package main\n 2 import \"bytes\"\n 3 import \"crypto/rand\"\n 4 import \"crypto/rsa\"\n 5 import \"crypto/sha1\"\n 6 import \"encoding/gob\"\n 7 import \"log\"\n 8 import . \"net\"\n 9 \n10 var HELLO_WORLD = []byte(\"Hello World\")\n11 var RSA_LABEL = []byte(\"served\")\n12 \n13 func main() {\n14   Serve(\":1025\", func(connection *UDPConn, c *UDPAddr, packet *bytes.Buffer) (n int) {\n15     var e error\n16     var key rsa.PublicKey\n17     var response []byte\n18 \n19     if e = gob.NewDecoder(packet).Decode(&key); e != nil {\n20       log.Println(\"unable to decode wrapper:\", c)\n21     }\n22 \n23     if response, e = rsa.EncryptOAEP(sha1.New(), rand.Reader, &key, HELLO_WORLD, RSA_LABEL); e != nil {\n24       log.Println(\"unable to encrypt server response\")\n25     }\n26 \n27     if n, e = connection.WriteToUDP(response, c); e != nil {\n28       log.Println(\"unable to write response to client:\", c)\n29     }\n30     return\n31   })\n32 }\n33 \n34 func Serve(address string, f func(*UDPConn, *UDPAddr, *bytes.Buffer) int) {\n35   Launch(address, func(connection *UDPConn) {\n36     for {\n37       buffer := make([]byte, 1024)\n38       if n, client, e := connection.ReadFromUDP(buffer); e == nil {\n39         go func(c *UDPAddr, b []byte) {\n40           if n := f(connection, c, bytes.NewBuffer(b)); n != 0 {\n41             log.Println(n, \"bytes written to\", c)\n42           }\n43         }(client, buffer[:n])\n44       } else {\n45         log.Println(address, e.Error())\n46       }\n47     }\n48   })\n49 }\n50 \n51 func Launch(address string, f func(*UDPConn)) {\n52   var e error\n53   var a *UDPAddr\n54   var server *UDPConn\n55 \n56   if a, e = ResolveUDPAddr(\"udp\", address); e != nil {\n57     log.Fatalln(\"unable to resolve UDP address:\", e.Error())\n58   }\n59 \n60   if server, e = ListenUDP(\"udp\", a); e != nil {\n61     log.Fatalln(\"can't open socket for listening:\", e.Error())\n62   }\n63 \n64   f(server)\n65 }\n

\n\n\n\n\n\n

$ go run 58.go &\n[1] 15397\n$ go run 57.go\n2016/07/13 09:13:11 256 bytes written to 127.0.0.1:65099\nHello World\n$ go run 58.go\n2016/07/13 09:13:51 can't open socket for listening: listen udp :1025: bind: address already in use\nexit status 1\n

\n\n\n\n\n

This is the only error condition that’s likely to occur in our shell-based test environment but if we forcibly corrupt the gob encoding of our client’s response key by modifying its SendKey function to drop the first byte we can emulate key corruption in transit

\n\n\n

55 func SendKey(server *UDPConn, public_key rsa.PublicKey, f func()) {\n56   var encoded_key bytes.Buffer\n57   if e := gob.NewEncoder(&encoded_key).Encode(public_key); e == nil {\n58     if _, e = server.Write(encoded_key.Bytes()[1:]); e == nil {\n59       f()\n60     }\n61   }\n62 }\n

\n\n\n\n\n\n

$ go run 58.go &\n[1] 16289\n$ go run 57_corrupt_key.go\n2016/07/13 09:24:44 unable to decode wrapper: 127.0.0.1:55085\n2016/07/13 09:24:44 unable to encrypt server response\n

\n\n\n\n\n

One of the cool things about interfaces is that they’re reference types, something we’ll routinely use to decide whether an error has occurred or not. If it has then the interface will contain an error value, and if not the interface itself will be a nil value. This leads to the common code pattern

\n\n\n

if _, e := SomeCall(); e != nil {\n  log.Println(\"some error\", e)\n  // this is our sad path\n} else {\n  // perform desired actions\n}\n

\n\n\n\n\n

Our sad path will generally either return it’s own error to the calling function or terminate the program with a call to log.Fatalln() or os.Exit(). Because Go functions allow for multiple return values, their use is accompanied by the convention that the last value returned will be of type error. This convention encourages us to handle errors where they occur rather than bubbling exceptions up the call stack, as would be the case in many languages. As there are rare occasions when exceptions might prove a useful idiom we’ll look at how we can achieve a similar outcome in the next section.

\n\n

For now though we’re going to tidy this code up a little by using the if…{}…else if {}… construct which thanks to if’s ability to combine an assignment with a test leads to very succinct code.

\n\n\n

Example 1.1.59

package main\nimport \"bytes\"\nimport \"crypto/rand\"\nimport \"crypto/rsa\"\nimport \"crypto/sha1\"\nimport \"encoding/gob\"\nimport \"log\"\nimport . \"net\"\n\nvar HELLO_WORLD = []byte(\"Hello World\")\nvar RSA_LABEL = []byte(\"served\")\n\nfunc main() {\n  Serve(\":1025\", func(connection *UDPConn, c *UDPAddr, packet *bytes.Buffer) (n int) {\n    var key rsa.PublicKey\n    var response []byte\n\n    if e := gob.NewDecoder(packet).Decode(&key); e != nil {\n      log.Println(\"unable to decode wrapper:\", c)\n    } else if response, e = rsa.EncryptOAEP(sha1.New(), rand.Reader, &key, HELLO_WORLD, RSA_LABEL); e \\\n!= nil {\n      log.Println(\"unable to encrypt server response\")\n    } else if n, e = connection.WriteToUDP(response, c); e != nil {\n      log.Println(\"unable to write response to client:\", c)\n    }\n    return\n  })\n}\n\nfunc Serve(address string, f func(*UDPConn, *UDPAddr, *bytes.Buffer) int) {\n  Launch(address, func(connection *UDPConn) {\n    for {\n      buffer := make([]byte, 1024)\n      if n, client, e := connection.ReadFromUDP(buffer); e == nil {\n        go func(c *UDPAddr, b []byte) {\n          if n := f(connection, c, bytes.NewBuffer(b)); n != 0 {\n            log.Println(n, \"bytes written to\", c)\n          }\n        }(client, buffer[:n])\n      } else {\n        log.Println(address, e.Error())\n      }\n    }\n  })\n}\n\nfunc Launch(address string, f func(*UDPConn)) {\n  var connection *UDPConn\n\n  if a, e := ResolveUDPAddr(\"udp\", address); e != nil {\n    log.Fatalln(\"unable to resolve UDP address:\", e.Error())\n  } else if connection, e = ListenUDP(\"udp\", a); e != nil {\n    log.Fatalln(\"can't open socket for listening:\", e.Error())\n  }\n  f(connection)\n}\n

\n\n\n\n\n

Whilst I personally find this easier on the eye in many cases, it’s a less common idiom than successive if statements. It’s also important to remember Go’s scoping rules when using this construction as these allow each assignment to introduce new variables local to that if statement’s scope. As such some care should be taken in variable naming to avoid accidental shadowing.

\n\n

Because error is defined as an interface rather than a concrete type we can declare our own types for error handling and then check for them to specialise error handling behaviour. In the next example we introduce the LaunchError type which complies with the predeclared error interface by implementing its own Error() method.

\n\n\n

Example 1.1.60

 1 package main\n 2 import \"bytes\"\n 3 import \"crypto/rand\"\n 4 import \"crypto/rsa\"\n 5 import \"crypto/sha1\"\n 6 import \"encoding/gob\"\n 7 import \"fmt\"\n 8 import \"log\"\n 9 import . \"net\"\n10 \n11 var HELLO_WORLD = []byte(\"Hello World\")\n12 var RSA_LABEL = []byte(\"served\")\n13 \n14 type LaunchError []interface{}\n15 \n16 func (l LaunchError) Error() (r string) {\n17   if len(l) > 0 {\n18     r = fmt.Sprintf(l[0].(string), l[1:]...)\n19   }\n20   return\n21 }\n22 \n23 func NewLaunchError(format string, v ...interface{}) (l LaunchError) {\n24   return LaunchError(append([]interface{}{ format }, v))\n25 }\n26 \n27 func main() {\n28   Serve(\":1025\", func(connection *UDPConn, c *UDPAddr, packet *bytes.Buffer) (n int) {\n29     var key rsa.PublicKey\n30     var response []byte\n31 \n32     if e := gob.NewDecoder(packet).Decode(&key); e != nil {\n33       log.Println(\"unable to decode wrapper:\", c)\n34     } else if response, e = rsa.EncryptOAEP(sha1.New(), rand.Reader, &key, HELLO_WORLD, RSA_LABEL); e \\\n35 != nil {\n36       log.Println(\"unable to encrypt server response\")\n37     } else if n, e = connection.WriteToUDP(response, c); e != nil {\n38       log.Println(\"unable to write response to client:\", c)\n39     }\n40     return\n41   })\n42 }\n43 \n44 func Serve(address string, f func(*UDPConn, *UDPAddr, *bytes.Buffer) int) {\n45   e := Launch(address, func(connection *UDPConn) (e error) {\n46     defer func() {\n47       if x := recover(); x != nil {\n48         e = LaunchError{ \"serve failure %v\", x }\n49       }\n50     }()\n51     for {\n52       buffer := make([]byte, 1024)\n53       if n, client, e := connection.ReadFromUDP(buffer); e == nil {\n54         go func(c *UDPAddr, b []byte) {\n55           if n := f(connection, c, bytes.NewBuffer(b)); n != 0 {\n56             log.Println(n, \"bytes written to\", c)\n57           }\n58         }(client, buffer[:n])\n59       } else {\n60         log.Println(address, e.Error())\n61       }\n62     }\n63     return\n64   })\n65 \n66   if e, ok:= e.(LaunchError); ok {\n67     log.Fatalln(e.Error())\n68   }\n69 }\n70 \n71 func Launch(address string, f func(*UDPConn) error) error {\n72   var connection *UDPConn\n73 \n74   if a, e := ResolveUDPAddr(\"udp\", address); e != nil {\n75     return NewLaunchError(\"unable to resolve UDP address:\", e.Error())\n76   } else if connection, e = ListenUDP(\"udp\", a); e != nil {\n77     return LaunchError{ \"can't open socket for listening:\", e.Error() }\n78   }\n79   return f(connection)\n80 }\n

\n\n\n\n\n

This is quite a complicated example, so let’s take a look at the various changes we’ve made in detail.

\n\n\n

17 type LaunchError []interface{}\n18 \n19 func (l LaunchError) Error() (r string) {\n20   if len(l) > 0 {\n21     r = fmt.Sprintf(l[0].(string), l[1:]...)\n22   }\n23   return\n24 }\n25 \n26 func NewLaunchError(format string, v ...interface{}) (l LaunchError) {\n27   return LaunchError(append([]interface{}{ format }, v))\n28 }\n

\n\n\n\n\n

For simplicity we’ve made LaunchError a slice of interface{} values and declared an Error() method which uses the first element in the slice as a format string and successive elements as parameters for fmt.Sprintf(). The NewLaunchError() function is a typical example of a value constructor which we’d export from a package, and later in the code we show both construction this way and using a LaunchError{} literal.

\n\n\n

73 func Launch(address string, f func(*UDPConn) error) error {\n74   var connection *UDPConn\n75 \n76   if a, e := ResolveUDPAddr(\"udp\", address); e != nil {\n77     return NewLaunchError(\"unable to resolve UDP address:\", e.Error())\n78   } else if connection, e = ListenUDP(\"udp\", a); e != nil {\n79     return LaunchError{ \"can't open socket for listening:\", e.Error() }\n80   }\n81   return f(connection)\n82 }\n

\n\n\n\n\n

We’ve made another change to Launch() related to our new approach to error handling, which is to propogate these errors back to the caller via a return value - and just for completeness we’re allowing errors to bubble up from the function parameter f as well. This leads to changes in Serve as well.

\n\n\n

46 func Serve(address string, f func(*UDPConn, *UDPAddr, *bytes.Buffer) int) {\n47   e := Launch(address, func(connection *UDPConn) (e error) {\n48     defer func() {\n49       if x := recover(); x != nil {\n50         e = LaunchError{ \"serve failure %v\", e }\n51       }\n52     }()\n

\n\n\n\n\n

Here we set a value for e from the error returned by Launch() as well as intercepting any panic raised by the associated closure with defer and instead returning a LaunchError rather than crashing the program. As defer takes a closure the e referenced inside it is the same e as that declared by the function literal func(connection *UDPConn) (e error), a pattern encountered in many existing Go codebases. We then use the returned error value before exiting Serve().

\n\n\n

68   if e, ok:= e.(LaunchError); ok {\n69     log.Fatalln(e.Error())\n70   }\n

\n\n\n\n\n

It should come as no surprise that Go provides support for creating error values without our having to define error types, in the form of errors.New and fmt.Errorf. Using these we can remove the LaunchError type and rewrite our program.

\n\n\n

Example 1.1.61

 1 package main\n 2 import \"bytes\"\n 3 import \"crypto/rand\"\n 4 import \"crypto/rsa\"\n 5 import \"crypto/sha1\"\n 6 import \"encoding/gob\"\n 7 import \"errors\"\n 8 import \"fmt\"\n 9 import \"log\"\n10 import . \"net\"\n11 \n12 var HELLO_WORLD = []byte(\"Hello World\")\n13 var RSA_LABEL = []byte(\"served\")\n14 \n15 func main() {\n16   Serve(\":1025\", func(connection *UDPConn, c *UDPAddr, packet *bytes.Buffer) (n int) {\n17     var key rsa.PublicKey\n18     var response []byte\n19 \n20     if e := gob.NewDecoder(packet).Decode(&key); e != nil {\n21       log.Println(\"unable to decode wrapper:\", c)\n22     } else if response, e = rsa.EncryptOAEP(sha1.New(), rand.Reader, &key, HELLO_WORLD, RSA_LABEL); e \\\n23 != nil {\n24       log.Println(\"unable to encrypt server response\")\n25     } else if n, e = connection.WriteToUDP(response, c); e != nil {\n26       log.Println(\"unable to write response to client:\", c)\n27     }\n28     return\n29   })\n30 }\n31 \n32 func Serve(address string, f func(*UDPConn, *UDPAddr, *bytes.Buffer) int) {\n33   e := Launch(address, func(connection *UDPConn) (e error) {\n34     defer func() {\n35       if x := recover(); x != nil {\n36         e = fmt.Errorf(\"serve failure %v\", x)\n37       }\n38     }()\n39     for {\n40       buffer := make([]byte, 1024)\n41       if n, client, e := connection.ReadFromUDP(buffer); e == nil {\n42         go func(c *UDPAddr, b []byte) {\n43           if n := f(connection, c, bytes.NewBuffer(b)); n != 0 {\n44             log.Println(n, \"bytes written to\", c)\n45           }\n46         }(client, buffer[:n])\n47       } else {\n48         log.Println(address, e.Error())\n49       }\n50     }\n51     return\n52   })\n53 \n54   if e != nil {\n55     log.Fatalln(e.Error())\n56   }\n57 }\n58 \n59 func Launch(address string, f func(*UDPConn) error) error {\n60   var connection *UDPConn\n61 \n62   if a, e := ResolveUDPAddr(\"udp\", address); e != nil {\n63     return fmt.Errorf(\"unable to resolve UDP address: %v\", e)\n64   } else if connection, e = ListenUDP(\"udp\", a); e != nil {\n65     return errors.New(fmt.Sprintf(\"can't open socket for listening: %v\", e.Error()))\n66   }\n67   return f(connection)\n68 }\n

\n\n\n\n\n

\nExceptions

\n\n

If we consider these programs for a minute or two it becomes apparent that propagating our errors this way works very well when we wish to deal with an error immediately, which is usually the case. However there are occasions when an error will need to be propagated through several layers of function calls, and when this is the case there’s a lot of boilerplate involved in intermediate functions in the call stack.

\n\n

We can do away with much of this by rolling our own lightweight equivalent of exceptions using defer and the panic() and recover() calls. In the next example we’ll do just this, introducing the Exception type which is an interface with error embedded within it. This means that any error value will also be useable as an Exception value.

\n\n

\n \n

\nWhy doesn’t Go have native exceptions?

\n\n

A common criticism of Go is its use of inline error handling rather than the kind of exception-handling mechanism we’re developing here. The language FAQ has a coherent explanation which is worth quoting in full:

\n\n

\n\n
\nWhy does Go not have exceptions?\n
\n\n
We believe that coupling exceptions to a control structure, as in the try-catch-finally idiom, results in convoluted code. It also tends to encourage programmers to label too many ordinary errors, such as failing to open a file, as exceptional.
\n\n
Go takes a different approach. For plain error handling, Go’s multi-value returns make it easy to report an error without overloading the return value. A canonical error type, coupled with Go’s other features, makes error handling pleasant but quite different from that in other languages.
\n\n
Go also has a couple of built-in functions to signal and recover from truly exceptional conditions. The recovery mechanism is executed only as part of a function’s state being torn down after an error, which is sufficient to handle catastrophe but requires no extra control structures and, when used well, can result in clean error-handling code.
\n\n
See the Defer, Panic, and Recover article for details.
\n

\n\n

Go is a conservative language with a minimal set of features chosen primarily to avoid unnecessary magic in code, with all the maintenance problems that can bring. As you’ll find by the end of this chapter, exception handling is most decidedly magical if it’s to be elegant, potentially introducing several layers of source-code abstraction between the logic for performing an operation and the error recovery code which cleans up when it goes wrong.

\n\n

That’s not to say that exception-style mechanisms aren’t useful for certain tasks, and as I hope the following examples will demonstrate (as well as those in later chapters) it’s perfectly reasonable to implement variants which suit your purpose when the need arises.

\n\n

\n\n\n

Example 1.1.62

 1 package main\n 2 import \"bytes\"\n 3 import \"crypto/rand\"\n 4 import \"crypto/rsa\"\n 5 import \"crypto/sha1\"\n 6 import \"encoding/gob\"\n 7 import \"fmt\"\n 8 import \"log\"\n 9 import . \"net\"\n10 import \"os\"\n11 \n12 var HELLO_WORLD = []byte(\"Hello World\")\n13 var RSA_LABEL = []byte(\"served\")\n14 \n15 type Exception interface {\n16   error\n17 }\n18 \n19 func Raise(message string, parameters ...interface{}) {\n20   panic(fmt.Errorf(message, parameters...))\n21 }\n22 \n23 func Rescue(f func()) {\n24   defer func() {\n25     if e := recover(); e != nil {\n26       if e, ok := e.(Exception); ok {\n27         log.Println(\"Exception:\", e.Error())\n28         os.Exit(1)\n29       } else {\n30         panic(e)\n31       }\n32     }\n33   }()\n34 \n35   f()\n36 }\n37 \n38 func main() {\n39   Serve(\":1025\", func(connection *UDPConn, c *UDPAddr, packet *bytes.Buffer) (n int) {\n40     var key rsa.PublicKey\n41     var response []byte\n42 \n43     Rescue(func() {\n44       if e := gob.NewDecoder(packet).Decode(&key); e != nil {\n45         Raise(\"unable to decode wrapper: %v\", c)\n46       } else if response, e = rsa.EncryptOAEP(sha1.New(), rand.Reader, &key, HELLO_WORLD, RSA_LABEL); \\\n47 e != nil {\n48         Raise(\"unable to encrypt server response\")\n49       } else if n, e = connection.WriteToUDP(response, c); e != nil {\n50         Raise(\"unable to write response to client: %v\", c)\n51       }\n52     })\n53     return\n54   })\n55 }\n56 \n57 func Serve(address string, f func(*UDPConn, *UDPAddr, *bytes.Buffer) int) {\n58   Rescue(func() {\n59     e := Launch(address, func(connection *UDPConn) (e error) {\n60       for {\n61         buffer := make([]byte, 1024)\n62         if n, client, e := connection.ReadFromUDP(buffer); e == nil {\n63           go func(c *UDPAddr, b []byte) {\n64             if n := f(connection, c, bytes.NewBuffer(b)); n != 0 {\n65               log.Println(n, \"bytes written to\", c)\n66             }\n67           }(client, buffer[:n])\n68         } else {\n69           log.Println(address, e.Error())\n70         }\n71       }\n72       return\n73     })\n74 \n75     if e != nil {\n76       log.Fatalln(e.Error())\n77     }\n78   })\n79 }\n80 \n81 func Launch(address string, f func(*UDPConn) error) error {\n82   var connection *UDPConn\n83 \n84   if a, e := ResolveUDPAddr(\"udp\", address); e != nil {\n85     Raise(\"unable to resolve UDP address: %v\", e)\n86   } else if connection, e = ListenUDP(\"udp\", a); e != nil {\n87     Raise(\"can't open socket for listening: %v\", e.Error())\n88   }\n89   return f(connection)\n90 }\n

\n\n\n\n\n

Our updated code looks surprisingly similar to that of Example 1.60 with a set of type declarations replacing LaunchError with Exception and NewLaunchError() with Raise(), which as its name suggests generates a panic to propagate the Exception value back up the calling stack. We’ve also introduced Rescue()

\n\n\n

22 func Raise(message string, parameters ...interface{}) {\n23   panic(fmt.Errorf(message, parameters...))\n24 }\n

\n\n\n\n\n

To intercept this panic we need a defer statement somewhere up the call stack which can handle it, otherwise it will bubble up through main() and the program will terminate with a stack trace. In our implementation of Rescue() we set up a deferred function which will check panic values with a type assertion and where these match the Exception interface the program will be terminated cleanly.

\n\n\n

26 func Rescue(f func()) {\n27   defer func() {\n28     if e := recover(); e != nil {\n29       if e, ok := e.(Exception); ok {\n30         log.Println(\"Exception:\", e.Error())\n31         os.Exit(1)\n32       } else {\n33         panic(e)\n34       }\n35     }\n36   }()\n37 \n38   f()\n39 }\n

\n\n\n\n\n\n

$ go run 62.go &\n[1] 53769\n$ go run 62.go\n2016/07/13 17:39:33 Exception: can't open socket for listening: listen udp :1025: bind: address alread\\\ny in use\nexit status 1\n$ go run 57_corrupt_key.go \n2016/07/13 17:39:37 Exception: unable to decode wrapper: 127.0.0.1:49325\nexit status 1\n^Csignal: interrupt\n[1]+  Exit 1                  go run 62.go\n

\n\n\n\n\n

The semantics here are subtly different to our previous example and any error in the server will cause it to terminate. Instead we want launch errors to terminate the server whilst connection errors from talking with a particular client should log the error and return to listening for another connection. The easiest way to do this is to parameterise Rescue() so that it receives both the function to guard and a function with signature func(Exception) to respond according to the Exception value generated.

\n\n\n

[Example 1.1.63a] Rescue() function definition

26 func Rescue(f func(), r func(Exception)) {\n27   defer func() {\n28     if e := recover(); e != nil {\n29       if e, ok := e.(Exception); ok {\n30         r(e)\n31       } else {\n32         panic(e)\n33       }\n34     }\n35   }()\n36 \n37   f()\n38 }\n

\n\n\n\n\n\n

[Example 1.1.63b] Rescue() function in use

67       Rescue(\n68         func() {\n69           buffer := make([]byte, 1024)\n70           if n, client, e := connection.ReadFromUDP(buffer); e == nil {\n71             go func(c *UDPAddr, b []byte) {\n72               if n := f(connection, c, bytes.NewBuffer(b)); n != 0 {\n73                 log.Println(n, \"bytes written to\", c)\n74               }\n75             }(client, buffer[:n])\n76           } else {\n77             Raise(\"%v: %v\", address, e.Error())\n78           }\n79         },\n80         func(e Exception) {\n81           log.Println(e.Error())\n82         },\n83       )\n

\n\n\n\n\n\n

[Example 1.1.63c] Launch() rewritten to use Rescue()

67 func Launch(address string, f func(*UDPConn) error) {\n68   var connection *UDPConn\n69 \n70   Rescue(\n71     func() {\n72       if a, e := ResolveUDPAddr(\"udp\", address); e != nil {\n73         Raise(\"unable to resolve UDP address: %v\", e)\n74       } else if connection, e = ListenUDP(\"udp\", a); e != nil {\n75         Raise(\"can't open socket for listening: %v\", e)\n76       } else if e = f(connection); e != nil {\n77         Raise(\"connection error: %v\", e)\n78       }\n79     },\n80     func(e Exception) {\n81       log.Println(e.Error())\n82       os.Exit(1)\n83     },\n84   )\n85 }\n

\n\n\n\n\n

This now gives us a primitive domain specific language for exceptions using Rescue() blocks to guard behaviour and Raise() to trigger them. Unfortunately an Exception is essentially untyped in the context where it’s dealt with and this places all the burden for exception handling into a single closure. However generally languages which support exception handling allow exceptions to be differentiated by subtype, so let’s see what we can do to achieve a similar effect.

\n\n

The obvious first step is to introduce a new type which implements the Exception interface and then use a type switch in an exception handler to specialise its behaviour

\n\n\n

[Example 1.1.64a] defining an Exception type

26 type LaunchException error\n27 \n28 func RaiseLaunchException(message string, parameters ...interface{}) {\n29   panic(LaunchException(fmt.Errorf(message, parameters...)))\n30 }\n

\n\n\n\n\n\n

[Example 1.1.64b] checking for a specific exception

 94 func Launch(address string, f func(*UDPConn) error) {\n 95   var connection *UDPConn\n 96 \n 97   Rescue(\n 98     func() {\n 99       if a, e := ResolveUDPAddr(\"udp\", address); e != nil {\n100         RaiseLaunchException(\"unable to resolve UDP address: %v\", e)\n101       } else if connection, e = ListenUDP(\"udp\", a); e != nil {\n102         RaiseLaunchException(\"can't open socket for listening: %v\", e)\n103       } else if e = f(connection); e != nil {\n104         Raise(\"connection error: %v\", e)\n105       }\n106     },\n107     func(e Exception) {\n108       switch e := e.(type) {\n109       case LaunchException:\n110         log.Println(\"Launch Exception:\", e.Error())\n111       default:\n112         log.Println(e.Error())\n113       }\n114       os.Exit(1)\n115     },\n116   )\n117 }\n

\n\n\n\n\n

The type switch allows us to select different courses of action depending on the concrete type of the value contained in the Exception, and we can also specify a default case to handle unknown values.

\n\n\n

$ go run 64.go &\n[1] 90620\n$ go run 64.go\n2016/07/16 00:03:17 Launch Exception can't open socket for listening: listen udp :1025: bind: address \\\nalready in use\nexit status 1\n$ go run 57.go\n2016/07/16 01:00:53 256 bytes written to 127.0.0.1:63574\nHello World\n$ go run 57_corrupt_key.go \n2016/07/16 01:00:58 Exception: unable to decode wrapper: 127.0.0.1:54657\n^Csignal: interrupt\n$ go run 57.go\n2016/07/16 01:02:09 256 bytes written to 127.0.0.1:52033\nHello World\n

\n\n\n\n\n

The use of type switches in this manner is a common idiom in go and I quite like this solution as the only magic at work here is our abuse of the panic()/recover() mechanism. However I’d really prefer to split exception handling into several different functions, each keyed to a particular exception type. This is relatively easy to do but requires that we pop open go’s hood at runtime using type reflection.

\n\n

\n \n

\nDynamism comes at a price

\n\n

Reflection in Go rests on two powerful packages: reflect and unsafe. With reflect you can find out pretty much anything about a value at runtime and write code based on that knowledge, whilst with unsafe you can bypass runtime type guarantees to repurpose memory. The cases when reflect is useful are much more numerous than those for unsafe, but neither is essential to day-to-day programming so many Go programmers will never use either in anger. However it’s still worth knowing a little both.

\n\n

The most common use for reflect is to develop generic functions as Go lacks generic types, however there’s a substantial performance cost associated with this. Performance hits of 10x or even 100x execution cost are not unusual with reflection, especially if dealing generically with containers of generic values. In general if you can frame such problems in terms of interfaces and type switches it pays to do so.

\n\n

The appropriately-named unsafe package should be approached with caution. This mechanism exists because sometimes a programmer really does know better than the compiler how a value can be used, however bypassing type system guarantees at runtime can result in bugs which are very difficult - or impossible - to track down.

\n\n

The insights gained from playing with these packages will make you a better Go coder so don’t be put off experimenting. I can’t guarantee you won’t destroy a computer with these kinds of tricks but I’ve yet to brick any of mine that way.

\n\n

Like many modern languages Go has an extensive reflection system which allows us to introspect any value at runtime - including the closures which our Rescue() function accepts - and then attempt to use that information to control the execution of our program.

\n\n\n

[Example 1.1.65] checking for a specific exception

45 func Rescue(f func(), r ...interface{}) {\n46   defer func() {\n47     if e := recover(); e != nil {\n48       if e, ok := e.(Exception); ok {\n49         et := reflect.TypeOf(e)\n50         for _, handler := range r {\n51           if h := reflect.ValueOf(handler); h.Kind() == reflect.Func && h.Type().NumIn() == 1 {\n52             switch hpt := h.Type().In(0); {\n53             case et == hpt:\n54               fallthrough\n55             case hpt.Kind() == reflect.Interface && et.Implements(hpt):\n56               h.Call([]reflect.Value{ reflect.ValueOf(e) })\n57               return\n58             }\n59           }\n60         }\n61       }\n62       panic(e)\n63     }\n64   }()\n65 \n66   f()\n67 }\n

\n\n\n\n\n

This seems like a pretty gnarly piece of code on first inspection so let’s rephrase it in English to get a better understanding for what’s it’s doing before looking at the details of the reflect API

\n\n\n

47 given that we've recovered from a panic()\n48   if we're handling any value whose type fulfils the Exception interface\n49     determine the concrete type of the Exception value\n50     step through the list of handlers specified in the Rescue() call\n51       if the handler is a function and accepts exactly one parameter\n52         find out what the type of its parameter is\n53         if the parameter is the same type as our exception's concrete type\n54         or the parameter is an interface which the exception implements\n55           call the handler with the exception as its parameter\n56           return from the defered function, continuing execution normally\n57   in all other cases\n58     propagate the value received by recover() up the unwinding call stack\n

\n\n\n\n\n

This essentially boils down to finding out the runtime types of the values our function encounters and then making choices about how to proceed. To achieve this we’ve used two functions central to working with reflection. Firstly there’s reflect.TypeOf() which takes any value and returns a reflect.Type value, then there’s reflect.ValueOf() which also takes any concrete value and returns a reflect.Value.

\n\n

Both Type and Value expose large APIs designed to operate on all runtime types and as a consequence many of these methods are prone to generating runtime panics if used incorrectly. Both types implement a Kind() method which can be used to provide basic safeguards

\n\n\n

51           if h := reflect.ValueOf(handler); h.Kind() == reflect.Func && h.Type().NumIn() == 1 {\n52             switch hpt := h.Type().In(0); {\n53             case et == hpt:\n54               fallthrough\n55             case hpt.Kind() == reflect.Interface && et.Implements(hpt):\n56               h.Call([]reflect.Value{ reflect.ValueOf(e) })\n57               return\n58             }\n59           }\n

\n\n\n\n\n

With type safety guarantees in place we can easily figure out whether or not we’re dealing with a recognisable exception handler (i.e. a function taking a parameter compatible with the Exception interface) and if we are the next question is how do we invoke this function? The reflect.Value type defines a method Call() which executes a function and takes as its parameter a []reflect.Value containing the actual parameters for the function, each wrapped as a reflect.Value

\n\n\n

56               h.Call([]reflect.Value{ reflect.ValueOf(e) })\n

\n\n\n\n\n

For completeness we’re going to refactor Rescue() by separating out the code for attempting an exception handling function call, making this easier to maintain

\n\n\n

[Example 1.1.66] calling an exception handler via reflection

33 func attemptCall(e Exception, handler interface{}) (ok bool) {\n34   if h := reflect.ValueOf(handler); h.Kind() == reflect.Func {\n35     et := reflect.TypeOf(e)\n36     if hpt := h.Type().In(0); et == hpt || et.Implements(hpt) {\n37       h.Call([]reflect.Value{reflect.ValueOf(e)})\n38       return true\n39     }\n40   }\n41   return\n42 }\n43 \n44 func Rescue(f func(), r ...interface{}) {\n45   defer func() {\n46     if e := recover(); e != nil {\n47       if e, ok := e.(Exception); ok {\n48         for _, h := range r {\n49           if attemptCall(e, h) {\n50             return\n51           }\n52         }\n53       }\n54       panic(e)\n55     }\n56   }()\n57 \n58   f()\n59 }\n

\n\n\n\n\n\n

\nEcho

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nArguments

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nFlags

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nCommand-line Boilerplate and Standard I/O

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nConditional Flags

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nErrors

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nGoing Loopy

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nAdventures in Iteration

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nLinear Sequences

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nThe for {} construct

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nUser Defined Slices

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nIterating Through Arrays

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nArrays and Slices Exposed

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nIteration and structured types

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nmappings

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nIteration and maps

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nSoftware Machines

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nSoftware Machines

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\narray stacks

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\ncactus stacks

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nhash maps

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nheaps

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nswitch dispatchers

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\ndirect threaded dispatchers

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nindirect threaded dispatchers

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nassembler

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\ntail calls

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\narchitectures

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nfun with types

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\ntimers

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nInstruction Set

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nprocessor core

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\naccumulator machine

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nstack machine

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nregister machine

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nvector machine

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nSoftware Machines

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nmemory

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nFunctional Programming

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nMetaprogramming and First-Class Functions

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nPure Functions, Expressions, and Recursion

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nPartial Application and Currying

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nLazy Evaluation and Memoization

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nFunctions

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nThe Machine View

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nAdding Human Readability

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nProcedures and Functions in Go

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nThe Mathematical View

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nSimple Factorials

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nFirst-Class and Higher-Order Functions

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nClosures

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nCurrying

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nRecursion

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nfuncs() Which Call Themselves

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nMathematical Functions Which Call Themselves

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nError Handling the Go Way

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nChanging Types

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nOdds & Sods

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nMaps and Hashes

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nGo maps

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nA simple Map implementation

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nTypes

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nInterfaces

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nInterfaces, pt 1

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\npackage adder

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nPretty Pictures

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nBasic Mandelbrot

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nPhong Shading

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nConcurrency

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nsynchronous

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nasynchronous

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nmap/reduce

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nmap/reduce

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nErrors, Exceptions & Flow Control

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nCatch & Throw

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nStack Traces

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nExceptions

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nDuck Typing, Reflection and Type Manipulation

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\npackage generalise

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nraw

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nBeyond Go

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nInterfacing with Dynamic Libraries

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nSQLite 3

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n

\nRuby?

\n\n\n

This content is not available in the sample book. The book can be purchased on Leanpub at http://leanpub.com/GoNotebook.

\n\n\n\n

\n\n","tocStructure",[425,426,427,428,429,430,431,432,433,434,435,436,437,438,439,440,441,442,443,444,445,446,447,448,449,450,451,452,453,454,455,456,457,458,459,460,461,462,463,464,465,466,467,468,469,470,471,472,473,474,475,476,477,478,479,480,481,482,483,484,485,486,487,488,489,490,491,492,493,494,495,496,497,498,499,500,501,502,503,504,505,506,507,508,509,510,511,512,513,514,515,516,517,518,519,520,521],{"_81":75,"_44":71,"_72":-5,"_76":77,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":82,"_44":83,"_72":-5,"_76":84,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":89,"_72":-5,"_76":90,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":95,"_72":-5,"_76":96,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":98,"_72":-5,"_76":99,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":101,"_72":-5,"_76":102,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":104,"_72":-5,"_76":105,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":107,"_72":-5,"_76":108,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":110,"_72":-5,"_76":111,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":113,"_72":-5,"_76":114,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":116,"_72":-5,"_76":117,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":119,"_72":-5,"_76":120,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":122,"_72":-5,"_76":123,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":125,"_72":-5,"_76":126,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":128,"_72":-5,"_76":129,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":131,"_72":-5,"_76":132,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":134,"_72":-5,"_76":135,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":82,"_44":137,"_72":-5,"_76":138,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":141,"_72":-5,"_76":142,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":144,"_72":-5,"_76":145,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":147,"_72":-5,"_76":148,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":150,"_44":151,"_72":-5,"_76":152,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":154,"_72":-5,"_76":155,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":75,"_44":157,"_72":-5,"_76":158,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":82,"_44":161,"_72":-5,"_76":162,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":165,"_72":-5,"_76":166,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":168,"_72":-5,"_76":169,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":171,"_72":-5,"_76":172,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":174,"_72":-5,"_76":175,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":177,"_72":-5,"_76":178,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":82,"_44":180,"_72":-5,"_76":181,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":184,"_72":-5,"_76":185,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":75,"_44":187,"_72":-5,"_76":188,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":82,"_44":187,"_72":-5,"_76":191,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":194,"_72":-5,"_76":195,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":197,"_72":-5,"_76":198,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":200,"_72":-5,"_76":201,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":203,"_72":-5,"_76":204,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":206,"_72":-5,"_76":207,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":209,"_72":-5,"_76":210,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":212,"_72":-5,"_76":213,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":215,"_72":-5,"_76":216,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":218,"_72":-5,"_76":219,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":221,"_72":-5,"_76":222,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":224,"_72":-5,"_76":225,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":227,"_72":-5,"_76":228,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":230,"_72":-5,"_76":231,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":233,"_72":-5,"_76":234,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":236,"_72":-5,"_76":237,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":239,"_72":-5,"_76":240,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":242,"_72":-5,"_76":243,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":245,"_72":-5,"_76":246,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":82,"_44":187,"_72":-5,"_76":248,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":251,"_72":-5,"_76":252,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":75,"_44":254,"_72":-5,"_76":255,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":82,"_44":101,"_72":-5,"_76":258,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":261,"_72":-5,"_76":262,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":150,"_44":264,"_72":-5,"_76":265,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":150,"_44":267,"_72":-5,"_76":268,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":270,"_72":-5,"_76":271,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":273,"_72":-5,"_76":274,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":150,"_44":276,"_72":-5,"_76":277,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":150,"_44":279,"_72":-5,"_76":280,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":150,"_44":282,"_72":-5,"_76":283,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":285,"_72":-5,"_76":286,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":150,"_44":288,"_72":-5,"_76":289,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":150,"_44":291,"_72":-5,"_76":292,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":150,"_44":294,"_72":-5,"_76":295,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":150,"_44":297,"_72":-5,"_76":298,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":75,"_44":300,"_72":-5,"_76":301,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":82,"_44":304,"_72":-5,"_76":305,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":308,"_72":-5,"_76":309,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":311,"_72":-5,"_76":312,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":82,"_44":314,"_72":-5,"_76":315,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":318,"_72":-5,"_76":319,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":150,"_44":321,"_72":-5,"_76":322,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":150,"_44":324,"_72":-5,"_76":325,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":82,"_44":327,"_72":-5,"_76":328,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":331,"_72":-5,"_76":332,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":82,"_44":334,"_72":-5,"_76":335,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":82,"_44":338,"_72":-5,"_76":339,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":82,"_44":342,"_72":-5,"_76":343,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":346,"_72":-5,"_76":347,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":349,"_72":-5,"_76":350,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":352,"_72":-5,"_76":353,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":352,"_72":-5,"_76":355,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":82,"_44":357,"_72":-5,"_76":358,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":361,"_72":-5,"_76":362,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":364,"_72":-5,"_76":365,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":134,"_72":-5,"_76":367,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":82,"_44":369,"_72":-5,"_76":370,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":373,"_72":-5,"_76":374,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":376,"_72":-5,"_76":377,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":82,"_44":379,"_72":-5,"_76":380,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":88,"_44":383,"_72":-5,"_76":384,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":150,"_44":386,"_72":-5,"_76":387,"_74":75,"_91":-5,"_92":-5,"_93":-5},{"_81":150,"_44":389,"_72":-5,"_76":390,"_74":75,"_91":-5,"_92":-5,"_93":-5},"publicChapterContent","nextChapter","sections",[449,450,451,452,453,454,455,456],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]

\nGoing Loopy

\nAdventures in Iteration

Table of Contents

\nIntroducing Go

\nGetting Started

\nSo what is Go?

\nOpen source

\nEfficient compilation

\nEfficient execution

\nEase of programming

\nAnd where did it come from?

\nInto the wild

\nWhere next?

\nHello World

\nPackages

\nConstants

\nVariables

\nFunctions

\nEncapsulation

\nGeneralisation

\nStartup

\nHTTP

\nThe Environment

\nHandling Signals

\nTCP/IP

\nUDP

\nRSA obfuscated UDP

\nError Handling

\nExceptions

\nEcho

\nArguments

\nFlags

\nCommand-line Boilerplate and Standard I/O

\nConditional Flags

\nErrors

\nGoing Loopy

\nAdventures in Iteration

\nLinear Sequences

\nThe for {} construct

\nUser Defined Slices

\nIterating Through Arrays

\nArrays and Slices Exposed

\nIteration and structured types

\nmappings

\nIteration and maps

\nSoftware Machines

\nSoftware Machines

\narray stacks

\ncactus stacks

\nhash maps

\nheaps

\nswitch dispatchers

\ndirect threaded dispatchers

\nindirect threaded dispatchers

\nassembler

\ntail calls

\narchitectures

\nfun with types

\ntimers

\nInstruction Set

\nprocessor core

\naccumulator machine

\nstack machine

\nregister machine

\nvector machine

\nSoftware Machines

\nmemory

\nFunctional Programming

\nMetaprogramming and First-Class Functions

\nPure Functions, Expressions, and Recursion

\nPartial Application and Currying

\nLazy Evaluation and Memoization

\nFunctions

\nThe Machine View

\nAdding Human Readability

\nProcedures and Functions in Go

\nThe Mathematical View

\nSimple Factorials

\nFirst-Class and Higher-Order Functions

\nClosures