Sourcegraph @ dotGo @dotgoliveblog - Tumblr Blog

Brad Fitzpatrick on the future of the Go programming language (1.4, 1.5, & 2.0)

photo credit: Nicolas Ravelli

Brad Fitzpatrick (@bradfitz) is a member of the Go team and the creator of memcached, OpenID and LiveJournal. He also works on Camlistore (“your personal storage system for life”). Thanks to Stephen McQuay (@smcquay) for contributing this liveblog post! - Sourcegraph

Note: The video will be online soon at dotgo.eu and tickets for dotGo 2015 are now available.

Hello Hacker News readers! Check out Sourcegraph, a code search & review tool for Go, Python, Java, Ruby, and JavaScript. Always free for open source and available soon for private/work code (sign up to be the first to get access).

—

State of the Gopher

View slides

Brad spent time marching through the history of Go since the 2009 open-source release with lists of features added for each release.

Original 2009 release:

Brad has worked on the stdlib and Camlistore since 2010. He gave a very brief history of Go's open sourcing. He showed a screenshot of the golang.org page from 2009, including a screenshot of a video by Russ Cox talking about how fast Go is to compile and how fast it runs. Even in 2009 there were two compilers (gc, gcc), but at the time there was very little exotic hardware support (such as ARM). At the time of the OSS release, the site was already being hosted by a Go binary.

Originally, there were weekly releases which inspired (and necessitated) go fix, which translated backwards-incompatible changes. Then came the monthly releases. At this point there was still no go tool, so people used Makefiles.

go1.0:

introduced better delete syntax.

stability promise: new features will not break your programs.

added the go tool we all know and love.

go1.1 (1 year later):

method values

terminating statement

64-bit int, etc.

Previously Go had a naive conservative GC ("if it looks like a pointer, try cleaning it up") then started getting a precise garbage collector, a GC that knows what every address in memory is supposed to be, which allows the GC to only look at pointers.

go1.2

3-index slice (can set cap), allows program to only pass very specific range of a slice into a func

scheduler preemption

go test -cover (test coverage)

go1.3 (no language changes)

sync.Pool: helpful for controlling garbage

GOOS added solaris, dragonfly, plan9 nacl

precise GC of stack (mostly) with fallback to conservative GC

move away from segmented stacks. Continuous stack allocations provided more consistent performance. He gave an example of decoding JSON with varying stack sizes and the new continuous method provides more consistent performance.

Present:

Windows support

many more docs

community wiki

books

All trends are up and to the right for Go development and usage. Things seem healthy.

People are using Go for cloud infrastructure. He cited many projects (Docker, Kubernetes, CoreOS, etc.).

Many conferences. Go Tokyo, Denver, Paris. India coming up. There is even a (CoreOS) gopher bus! There is a cool virtuous cycle of Go being built using tools built using Go (he mentioned CoreOS and Docker specifically). build.golang.org.

Go has better and better tools all the time. Started with godoc, gofmt, gofix, and he mentioned O(10) tools including and up to goreturns that expands "return err" to include zero values of the expected return values. Lots of cool and exciting tools, and they seem to be coming out faster these days.

The future of Go

go1.4

has precise GC of everything

beginnings of Android support

syscall frozen

pprof is now in Go, not Perl

etc.

go1.5

main theme is that the GC will be concurrent. Stop the world will no longer happen.

iOS revival

ppc64 and arm64

removing more C

the C-to-Go translation (talk summary from GopherCon 2014) will include steps to automatically clean up the code that is emitted by translator

GOTRACE: emits Chrome trace viewer and will allow for us to visualize scheduler actions and more in Chrome

NUMA-aware scheduler for better cache behavior

etc.

go2.0: Will it ever happen? Who knows.

gccgo gets a mention. It's keeping up with gc, and is superior in some ways (codegen, OS, arch), but still lacking in other ways (no precise GC, escape analysis).

gc, gcc, go/types (all different implementations of various parts of Go) help keep each other in check by finding bugs in the other implementations. He mentioned other interesting alternative compilers:

llgo: go -> llvm -> PNaCL

TARDIS Go: Go -> Haxe -> JS, anything

GopherJS: Go -> JS

He's jealous of these compilers since they're written in Go, and gc isn't (yet).

Q&A

Q: He skipped over go2.0; could you talk more about this? A: The reason to do 2.0 is to break things, and there is not consensus about what should, can, or deserves to be broken. No plans for 2.0 currently.

Q: How would you describe your role on go team? A: Supposed to be working on Camlistore 100%, but gets distracted by fixing bugs, responding to the mailing list, etc.

Q: Is Camlistore a real Google project? A: He thinks that Google is pacifying him. He started working on Go by adding to the stdlib to have functionality he used/needed in Camlistore. He figures if they have him working on Camlistore he will likely get distracted and fix Go bugs, so it works out well for Google.

—

Want to hear more from Brad? Follow him @bradfitz, check out his GitHub projects, and see his open-source contributions and influence on Sourcegraph.

Go team Q&A: dependency management, language design, Android, goroutines

photo credit: Nicolas Ravelli

Francesc Campoy Flores, Andrew Gerrand, Brad Fitzpatrick, Dave Cheney, Keith Rarick, and Blake Mizerany sat down for some Q&A at the end of dotGo. Here are selected portions of the discussion.

Q: Antipatterns arise in every language, especially new ones as people find what features can be used and reused. What antipatterns do you see, and what are the better patterns?

Dave Cheney: Too many packages. Packages should be at the granularity of an idea. HTTP is an idea; an HTTP client is not an idea.

Dave Cheney: If you have a utility package, that’s OK, but it should have a name that’s not just “utils.”

Q: There are several dependency management tools in the wild: godep, gpm, etc. Are there any plans to provide this functionality in the core?

Brad Fitzpatrick: We don’t want to dictate a policy, so we hope the community fights it out and a victor emerges. Then maybe we’ll bless that one. Then if everyone likes it and it has been stable for a couple of years, maybe we’ll add it to the core.

Brad Fitzpatrick: Part of the reason why we don’t care as much about dependency management inside Google is that we don’t use the go tool inside Google.

Andrew Gerrand: The lack of versioning built into the Go tool incentivizes library authors to provide good, stable APIs. The convention is to change the import path when the package API changes.

Q: Go is a lovely language that’s fantastic for writing servers on Unix. Consequently, people want to use Go to write desktop and embedded applications.

Dave Cheney: I’d love to see Go on some of the smaller ARM processors. We need to make the compiler generate different flavors of ARM code; that’s straightforward. Also, a garbage-collected language needs space to do bookkeeping; that’s also a solvable problem

Brad Fitzpatrick: People are already writing GUI libraries in Go.

Q: Can you give us an update on Go support for Android?

Andrew Gerrand: Yes! David Crawshaw of Google NYC is working on this. He has a few different ways of running Go code on Android: 1) using NDK, which gives access to the canvas, touch events, sound, etc., for games; 2) using a combination of Java and Go.

Q: Do you consider Go’s garbage collector production-ready for long-running, low-latency processes?

Brad Fitzpatrick: If you’re careful with your garbage (and in Go you can be careful), yes. We were able to refactor dl.google.com to produce much less garbage, and now the pauses are minimal. We’ve probably only had 1 customer inside Google for whom the Go garbage collector was insufficiently realtime.

Q: Any update on dynamically loadable code, like dlopen?

Andrew Gerrand: Check Ian Lance Taylor’s recent document about Go execution modes: different contexts in which Go code can run. There’s a plan for how these various modes can be achieved. We still don’t know when the work will be done or who will do it, but writing that doc is the first step.

Brad Fitzpatrick: Nothing will happen here until the linker is rewritten in Go.

Q: With no mechanism to refer to other goroutines, implementing supervision trees and killing goroutines requires manual efforts. How much of this should be addressed by libraries and how much by changes to the language?

Dave Cheney: At GopherCon this year, there was a strong sentiment that you should design your program so it can crash (and recover safely). The idea that if we just put enough effort into a system then we will achieve complete reliability is not tenable.

Andrew Gerrand: I suppose you could flip it around. What if Go had all these things? Then you’d still need to handle the case where your entire process crashes and your cleanup handlers wouldn’t be called.

Q: Is heap compaction on the garbage collection roadmap, or would that be considered a breaking change for 2.0?

Brad Fitzpatrick: That’s on the roadmap.

Q: Go seems different from other languages in its strong resistance to adding new features. Is that a philosophical choice?

Dave Cheney: Yes. It's a fundamental part of Go.

Andrew Gerrand: Go was designed by consensus by a team of 3. Now its team is much larger, so consensus is much harder to come by. (Slightly joking.) Now there are a lot of small pains that aren't large enough to motivate a change, and the huge pains would require such a large change that'd be untenable. Go 1.x is in a done state. I don't think that adding generics will suddenly satisfy everyone.

Brad Fitzpatrick: Standards committees never remove anything.

Q: Larger companies have a harder time switching programming languages. Do you have any advice for evangelizing Go within large companies?

Dave Cheney: Go often comes into organizations as a solution to specific problems, not by decree from upper management. That's the best kind of evangelism: "This solved a problem for me."

Andrew Gerrand: Point out other really large companies using Go: Apple, Comcast, Facebook, etc. Longer list.

Felix Geisendörfer - GoDrone

photo credit: Nicolas Ravelli

Felix Geisendörfer (@felixge) is the creator of GoDrone and NodeCopter. He also founded Transloadit and was one of the first contributors to node.js.

—

View Felix's slides

Felix is talking about how he built a Go firmware for the Parrot AR Drone 2.0. It runs Linux, has a 1 GHz ARM CPU, has 128MB RAM, and has an open SDK and protocol. The stock firmware is proprietary, which is why Felix got interested in hacking open-source firmware for it.

Felix originally built Nodecopter in Oct 2012 at a one-day hackathon. The hackathon spread to other cities, and there have now been 20-30 of these events worldwide.

Firmware

From a software development perspective, the firmware is the most interesting part of the drone. Can you replace the stock firmware with your own?

The firmware must:

Access the hardware (which Felix reverse-engineered by using strace, etc.)

Maintain stabilization

Physics of quadcopters

Hovering, tilting, and rotating are the basic maneuvers. To differentiate between these maneuvers, you need to apply more or less power to propellers on different planes. This is fairly easy.

What's harder is estimating the placement of the drone. The hardware provides low-level sensor readings (gyroscopes, accelerometer, magnetomer, etc.), and you need to throw a lot of mathematics at it to estimate your placement (and movement).

Controlling a quadcopter

This involves a lot of control theory and complex math.

Realtime

Can a garbage-collected language really power a quadcopter? Is it "realtime enough"? Yes. The drone's motors operate at 200Hz, so you have 5 milliseconds to provide a new input. Even if there's a garbage collection, you can recover from the pause.

Live demo & coding (YouTube)

Normal flying

And the GoDrone flip!

View Felix's slides

—

Want to hear more from Felix? Follow him @felixge, visit his homepage, check out his GitHub projects, and see his open-source contributions on Sourcegraph.

Blake Mizerany - Early Go mistakes, dependency usage

Blake Mizerany (@bmizerany) is the creator of Sinatra and the co-creator of Doozer. He currently works at CoreOS and previously worked at Heroku.

—

photo credit: Nicolas Ravelli

Blake opened up with an allegory about people who jump into things too quickly. Along these lines, he brought up several common Go fallacies that he first succumbed to but has since learned the better of.

Fallacy 1: Go is doing it wrong.

In reality, Go is doing things Go's way.

When Blake started out with Go, he was most familiar with Ruby, and he wrote bmizerany/assert, which was essentially trying to write Go as you would Ruby. He initially tried to make Go do things in Ruby's way. Lesson learned. He now just uses an if-statement and t.Errorf.

Fallacy 2: Predetermination. You know exactly what you need.

E.g., "net/http is lacking. We need more." So you pull in a huge external dependency.

To Blake, immediately deciding to use an external library is folly.

Consider gorilla/mux. Most of the features of gorilla/mux just save you from having to type a few if-statements at the cost of much greater complexity.

Fallacy 3: If it's on GitHub, it's ready for production.

Enough said. "You wouldn't go around picking stuff off the street and eating it. Why do so with your dependencies?"

Conclusion

Most Go programs don't require external dependencies.

Q&A

Q: How did Go get introduced to Heroku? A: Keith Rarick and Blake decided to use Go for a Paxos implementation on a whim. Never looked back.

—

Want to hear more from Blake? Follow him @bmizerany, check out his GitHub projects, and see his open-source contributions on Sourcegraph.

Dave Cheney - Functional Options

Dave Cheney (@davecheney) is a Go contributor who blogs at dave.cheney.net.

—

photo credit: Nicolas Ravelli

A story

Dave Cheney's talk is titled "Functional Options" and started with a story where a developer is tasked with writing a crucial server component, which appears to be simple in the beginning but later is flooded with requests such as TLS support, user feedback, load support, concurrency, all of which require changes to the original API in order to incorporate the new requirements.

An option: Structuring the API

Dave (sarcastically) shows an over-documented API example, which makes its usage ambiguous. Rather than trying to provide one single function to accommodate multiple use-cases, maybe write multiple simple and small functions for each-use case, with short documentation?

Another option: A config structure

Another option, with most advantages would be to use a configuration structure, allowing it to grow in the future while not touching the original API. "What used to be a big doc comment, now becomes a simple comment on that configuration object". This pattern isn't perfect though, because it makes it a bit more difficult to have default values. It is advised to use pointers to configuration objects rather than the object itself, so that when default behavior is desired that parameter can be set to nil, rather than an empty config object.

This is still not the optimal solution because it's not desired to receive nil parameters.

The optimal solution?

Go does not support optional function parameters, but it does support variadic params, and as such, we have the liberty to rid ourselves of pointers while we can continue to use the API by optionally passing it a config function.

But is this still the best way do to things?

The answer: Functional options

In functional options, we initialize our server by passing it a list of functions as arguments, each one of these functions take the server as a parameter and act upon it imposing the behavior that they are assigned too.

IE: NewServer(addr string, options ...func(*Server)) (*Server, error)

In this way we rid ourselves of config objects, nil values, and allow as many functional options as we need, similar to the middleware pattern.

Dave demoes a terminal interface that he has implemented using the above pattern. (https://sourcegraph.com/github.com/pkg/term@master/.GoPackage/github.com/pkg/term/.def/Open)

Functional options allow you to:

let you write beautiful APIs that can grow over time

enable the default use case to be its simplest

give more memorable, meaningful parameters

provide direct control over the initialization of complex values

—

Want to hear more from Dave? Follow him at @davecheney, read his blog at dave.cheney.net, check out his GitHub projects, and see his open-source contributions on Sourcegraph.

#dave cheney #golang #dotgo

Gabriel Aszalos - Mocking in Go with interfaces (lightning talk)

Gabriel Aszalos (@gabrielaszalos) hacks on Node.js, JavaScript, and Go at Thomson Reuters in London.

—

photo credit: Nicolas Ravelli

Gabriel talked about how he builds mocks and tests using mocks in Go. Check out his code at gbbr/mocks.

—

Want to hear more from Gabriel? Follow him @gabrielaszalos, check out his GitHub projects (@gbbr), and see his open-source contributions.

John Graham-Cumming - "I came for the easy concurrency; I stayed for the easy composition"

John Graham-Cumming (@jgrahamc) is a programmer at CloudFlare and the author of The Geek Atlas.

—

photo credit: Nicolas Ravelli

One day when John was at work, he got a message...

"I urgently need a program to take a list of sites and output whether they are on CloudFlare. Can you writ eit?"

"Yes. Sure. How many sites? Best way to check for whether a site is on CloudFlare?"

"About 2 million. Just check the site's nameservers for *.ns.cloudflare.com"

First thought was xargs: cat zones.txt | xargs -I{} dig NS | ...

But that's too slow! It takes 34 milliseconds to perform each operation, and doing them all would take 18 hours. Even parallelizing them with GNU parallel wouldn't work; how would we handle errors, etc.?

So, this is a job for Go!

The program needs to read lines (hostnames) from stdin, perform an operation per line (net.LookupNS), and write the results to stdout. And do this all concurrently.

And repeat...

This wasn't the first (or last) Go utility program John needed to write. And he kept noticing the same pattern in all of the small Go utility programs he was writing. They need to read lines, perform operations concurrently, and print results.

So, John wrote a generalized version of this program. Check out the code at jgrahamc/dotgo (but John suggests writing it yourself to see how easy it is).

By using Go's interfaces, John made it super easy to write programs to solve future instances of this commonly encountered problem.

In the past, John would have used Perl or Python to perform this kind of task. But Go is now eating into his use of scripting languages.

Q&A

Q: How much does CloudFlare use Go? A: Everywhere. Logging tens of billions of page views per day, DNS, DNSSEC, and much more.

—

Want to hear more from John? Follow him @jgrahamc, visit his homepage at jgc.org, check out his GitHub projects, and see his open-source contributions on Sourcegraph.

Francesc Campoy Flores - lessons learned from worldwide Go evangelism

Francesc (@francesc) is a member of the Go team. He's based in Mountain View but his wisdom is global. Check out the talk slides on Speaker Deck.

Francesc's talk is about:

Some thoughts about the difference between learning natural languages and programming languages, false friends, and hard stuff about interfaces.

—

The Go team is committed to growing Go adoption. Francesc introduces people from all around the world to Go, and he's learned a lot about how to improve Go by seeing how new Gophers learn the language.

Francesc himself knows 4 (human) languages, and he relates his philosophy of learning a new programming language to learning a spoken language. When you're learning a new spoken language and you mis-speak, you accept it when a native speaker corrects you. But often in programming languages, newcomers insist on doing things the "wrong" way, not having humility commensurate with their level of expertise.

For example, some Javañeros who start using Go create getters and setters on structs, like GetX and GetY. This is common in Java but not in Go. It's not technically incorrect, just non-idiomatic. But it's important to follow the idioms in Go (and any other language) to get the most out of the language.

Interfaces

Francesc once asked on Twitter, "What's the best thing about learning Go? Worst thing?" One of the answers was "Best: interfaces. Worst: interfaces."

So, let's dig into interfaces.

(Ed. note: There are a lot of great insights here, but they're hard to live-transcribe in text. Check out the slides and wait for the video to be posted at dotgo.eu.)

How do I learn Go?

Know the basics. Read the Go spec often.

Immersion. Write a lot of code.

Don't be embarrassed. You're going to write incorrect code and un-idiomatic code. Get feedback and fix it.

Always pass on what you have learned.

Q&A

Q: What are the next steps for Go's adoption? A: We have great ways for people coming from other languages to learn Go, but there's no good way yet for people who don't know programming to learn Go. Francesc is teaching programming to high-schoolers and he understands that it's tough to have Go as your first language.

—

Want to hear more from Francesc? Follow him at @francesc, check out his GitHub projects (@campoy), and see his open-source contributions on Sourcegraph.

In Paris? He's leading a workshop tomorrow, Introduction to Go:

In this guided tour of Go with Francesc Campoy you'll learn the basics of the language, from syntax to control flow to OO to concurrency.

No previous knowledge of Go is required.

Tomás Senart - Designing successful Web app load tests

Tomás Senart (@tsenart, GitHub, Sourcegraph) is the creator of Vegeta (an HTTP load tester used by Heroku, BBC, etc.) and a former software engineer at SoundCloud.

In this talk at dotGo 2014, he shared Web load testing best practices he's used at SoundCloud and on other large websites.

Why should we load test?

These days, lots of companies have APIs or are investing in SOAs or “micro-service architectures.” On each of these services, you need to be confident that when your load changes, you can handle it. Load testing gives you confidence; it lets you know that your infrastructure can handle future traffic. In summary, load testing is "about avoiding disaster."

But load testing is hard and there is a lot of misinformation about how to do it. Let's see how we can do it better.

Everyone starts by asking "how many requests per second can we do?". We're going to refine this question to get to a more useful and concrete load testing scheme.

Where should we load test?

You should load test staging, so that load testing doesn't affect your live product. But most companies don't have a full staging (with a representative clone of production data), so you probably need to load-test production.

To do load testing right, you need to know all about your architecture: what depends on what, what is cached, etc. You also need to know about your site's usage patterns. You often find that your initial guess about what to load test would not be testing what you wanted (e.g., because it would just hit a cache that a colleague added without your knowledge).

What should we load test?

You might have a lot of API endpoints. Which should you load test? You should isolate the endpoints and test them individually (as opposed to testing conglomerated/"helper" endpoints or running simultaneous load tests).

When you run the load test, you'll get a "requests per second" result, among other data points. But requests per second metric is a benchmark, not a load test. Benchmarking is measuring your system at its peak performance, right before it would flame out. Load testing is about testing your product on everyday and planned growth. Benchmarking is great, too, but don't get it confused with load testing.

How should we load test?

Define acceptable behavior based on your business and technical needs before you start hammering your servers. Be scientific about it. This lets you focus your time and effort on what matters.

Never look at averages. Endpoints have funky distributions over response times. What are the 95th, 99th percentile response times?

Tomás suggests to start slowly with a simple load test, and growing from there. Don't jump right into a very complex load test.

The 3 stages of load testing are:

Load generation (with either a constant load or a dynamic load to mimic actual conditions)

Metrics collection (black box testing relies on external performance measures from the machines generating load; white box testing relies on existing instrumentation embedded in your app to produce metrics)

Analysis & reporting (manual or automated)

Vegeta, a HTTP load testing tool and library (written in Go)

Tomás created Vegeta (browse Vegeta code and find examples on Sourcegraph):

Vegeta is a versatile HTTP load testing tool built out of need to drill HTTP services with a constant request rate. It can be used both as a command line utility and a library.

Vegeta is used by SoundCloud, BBC, UK government, Heroku, and others (Ed. note: and by several other open-source projects).

Why is Vegeta written in Go? It has a fantastic HTTP library and great concurrency support, both key to HTTP load testing. Even with non-kernel threads and garbage collection, Go was able to maintain a constant (high) rate of requests per second.

Browse Vegeta's code on Sourcegraph:

main.go

type Metrics

NewAttacker

ReportPlot

Other projects using Vegeta

Conclusion

Define your expectations, load test based on your expectations, and repeat!

—

Want to hear more from Tomás? Follow him @tsenart, check out his GitHub projects, and see his open-source contributions on Sourcegraph.

Keith Rarick - Go dependency management (vendoring and import path rewriting)

Keith Rarick (@krarick) is the creator of godep, Beanstalkd, and Doozer. He's formerly of Heroku.

—

Keith is talking about Go vendoring and import path rewriting.

First, godep. Godep is a tool that tracks your dependencies and does the "grunt" work of copying vendored dependency code into your project.

Godep began in April 2013 when Keith wanted to be able to reproduce his Go builds.

Godep for reproducible builds

How does it enable reproducible builds?

Writes down a list of all dependencies and the VCS commit ID of each repository

Stores the actual files (at the correct commit) of each dependency in your project

Notates the Go version

Initially, godep didn't actually vendor the dependencies. But doing so made it more reliable and simpler.

Why is it important to store the actual files of your dependencies?

Not everyone has a superfast Internet connection, and it can be slow to download dependencies.

Dependency hosts might go away or change their files.

Go and godep doesn't try to make sense of version strings like "1.2.3." It doesn't grok semver. That's because godep is made for the application owner, not library developers. App developers should take time to pick the exact right commit. Library developers, on the other hand, should not use godep; they should communicate clearly what their dependency version compatibility is.

The power of vendored dependencies (storing all of the files from each dependency)

"single code repository + godep = git bisect superpowers" - @iand

Patching dependencies is much easier when your own repository contains all of the files. Have you ever needed to make an urgent change to a dep and push to production? Do you really want to wait for them to accept your pull request? If you use godep and vendor your dependencies, this is super easy (you just need to change files in your own repository).

How to contribute to a Go repository

fork on GitHub

go get github.com/original/path # not our fork

cd $GOPATH/src/github.com/original/path

add our fork as another remote: git remote add ourfork [email protected]:our/fork.git

This is better than editing your fork because the Go import paths remain internally consistent (original/path not our/fork).

Import path rewriting

Using "go get" to install programs is awesome. But so is using godep. Can we do both at the same time? Not without import path rewriting.

"godep save -r" performs all the usual godep save steps (recording dep commit IDs and copying files), but then it rewrites import paths so that they refer to the godep-vendored packages.

This means that program users can use "go get" to get the program with the exact dependency versions the author intended. "Puppies and rainbows! Yay!"

—

Want more from Keith? Follow him @krarick, read his blog at xph.us, check out his projects on GitHub (@kr), and see his open-source contributions on Sourcegraph.

Jeremy Saenz - building better Go packages

Jeremy Saenz (aka @codegangsta) is the author of many popular Go projects, including Martini, Negroni, Gin, and CLI. He also runs GopherCasts.io.

—

Question: how many people have had to deal with poor code? Everyone!

Question: are you the one who wrote that poor code? Yeah...

"We all have written shitty code." Sometimes we write bad code because we're in a rush. That's OK. But sometimes we write bad code because we overdesign; we think about what code can do, not what it should do.

This talk isn't about how to write idiomatic Go code. Jeremy's going to talk about interfaces and API design, not implementation, today.

What makes good packages? Simplicity, flexibility, and continuity.

Simplicity: singular focus

"Simplicity is a prerequisite for reliability." - Djikstra

Simplicity is not a state but an ongoing process. It need to be maintainable and when defects arise, we need to be able to fix them easily.

Refer to "Simple Made Easy" by Rich Hickey (Clojure author).

Singularity: simple programs have one role, one task, one concept, one dimension. But a simple program doesn't need to be simple in every way.

A coworker came to Jeremy recently and said, "I want to make sure we're building letter openers, not Swiss Army knives." This nicely summarizes his point.

How to achieve simplicity? You need to know:

What does it accomplish?

What does it have to offer?

Having these answers and a clear vision behind your project makes it possible to say no to feature requests, etc., in open-source projects.

Example: Negroni has a very simple interface at its core, which was made possible by strictly adhering to this philosophy.

Flexibility: withstanding time and change

Jeremy is talking about "programs and code that compliment growth" and are malleable in the face of changed assumptions.

When he writes Go, he just feels that his code will last longer than code he writes in other languages.

Go expresses flexibility using interfaces. Take io.Writer for example. Anything that's writing bytes probably will involve io.Writer.

Some people say: "So, if interfaces are so good, we should always use them, right?" No. Interfaces communicate stability, concreteness, and commitment. Only use interfaces when you want to communicate these to library users.

When is something ready to be made into an interface? 3 guidelines:

Usually it's better to return a struct than an interface.

For argument values, it's generally good to make it an interface type. This is because the interface is an input to your routine, which means it needs to have certain behaviors. Exceptions: configuration/option structs.

Example of these principles in action: bufio.NewWriter(io.Writer) *Writer) takes an io.Writer and returns a struct.

Continuity

Continuity is a bit different from the other 2 principles.

Jeremy introduces this concept by relating it to a film. You know when in one scene a guy's tie is straight but then in the next scene it's ruffled?

Your code should look like Go stdlib code and other Go open-source code. Your code should be continuous with the Go ecosystem. How to do this?

Write code like a moron. Be less "smart." Embrace the decisions other people made.

Write code like it already exists.

Write code that looks like Go stdlib code.

—

Want to hear more from Jeremy? Follow him @codegangsta, check out his GitHub projects, and see his open-source contributions and influence on Sourcegraph.

In Paris? Join Jeremy tomorrow for his workshop, Building Web Apps with the CodeGangsta:

Jeremy Saenz (dotGo speaker) will teach attendees the basics of web development using the Go standard library and other auxiliary tools and packages.

During the workshop, attendees will build and deploy their own web app with Go on Heroku. Major concepts like HTTP routing, HTML templates, JSON rendering, and database access will be covered along the way.

Most importantly, attendees will learn how to approach Go web development in an idiomatic way, making them an even better Gopher!

Andrew Gerrand - Five things I love about Go

Andrew Gerrand (@enneff) joined Google and the Go team in February 2010. He's based in Sydney but his wisdom is global.

—

Google was built for scale. Not just machine scale, but also people scale. Google has a lot of developers.

This means the following things are important to have in a programming language:

development speed, execution speed

reliability

simplicity

Previously at Google they could only have at most 2 of these 3. In C++, they had speed but less reliability and simplicity. With Java, they had speed and reliability, but no simplicity. With Python, they had simplicity and development speed but poor reliability (due to lack of a type system, etc.) and poor execution speed. Go was created so Google could get all 3 of these things.

The 5 things Andrew loves are:

1. Interfaces

Interfaces are easy to define and are satisfied implicitly. They encourage composability. It's easy, for example, to compose a gzip reader so that anything that expects an io.Reader can "transparently" read gzipped data.

Interfaces capture emergent behavior. When the same interface emerges in multiple packages, you can define an explicit interface and take advantage of the implementations of it that you've already built.

Overall, interfaces help Andrew write good code quickly. He writes the code first and then can see the patterns that have emerged afterwards.

2. Concurrency

"Goroutines provide concurrent execution. Channels express communication and synchronization. The select statement enables computations on channel operations."

(Ed. note: some other languages have things like goroutines and channels, but select is where the magic is. It's very hard to implement and unlocks a lot of extra functionality.)

What's so good about Go's concurrency model? It just feels natural to Andrew. It's easy to change imperative code to add concurrency in Go without significantly modifying the structure. "There when you need it, invisible when you don't."

3. Workspaces

"A workspace is where you keep your Go code."

Andrew suggests setting GOPATH=$HOME.

Andrew recommends these other talks for best practices:

Go in Production - Peter Bourgon at GopherCon 2014

Organizing Go Code by David Crawshaw at Google I/O 2014

Why are workspaces good?

It means you generally don't need Makefiles or other build tools. If the Go code is correct, the build system can build it.

Everyone in Go land knows how to use Go workspaces. It's a universal concept in Go.

They enable great tools like godoc.org. (Ed. note: And Sourcegraph!)

4. gofmt

gofmt is the pretty printer for Go source code. It takes mal-indented and mal-formatted code and spits out the canonically formatted source.

By show of hands, everyone in the audience has fought with a coworker about whitespace or other code style. gofmt eliminates these arguments and saves tons of time and anguish.

In open source, 80%+ of Go code is gofmt'd. Also, high-quality code tended to be gofmt'd and low-quality code was often not gofmt'd.

gofmt also enables mechanical source manipulation using go/ast and go/printer. Tools like go fix, goimports, and gorename (Ed. note: and goreturns!) rely on the standard formatting style to make purely semantic changes (otherwise there would be lots of whitespace changes).

5. goimports

About half of the audience uses goimports. It adds and removes import statements automatically as you write code, which makes it much faster to write Go. This is especially important because Go is strict about ensuring there are no unused imports.

Conclusion

Go is more than a language. It's an ecosystem. The community is writing a lot of tools (software that helps us write software) that make Go even better.

—

Want to hear more from Andrew? Follow him at @enneff, check out his GitHub projects (@nf), and see his open-source contributions on Sourcegraph.

In Paris? Join him and Francesc (another Go team member) for their workshop tomorrow, Whispering Gophers: Network Programming in Go:

In this codelab you'll build a peer-to-peer chat network to communicate with your fellow attendees, giving you hands-on experience with Go's concurrency primitives and standard library.

We're live at dotGo in Paris! Check back for updates and summaries of the presentations.

Want a Sourcegraph t-shirt? Find us in the 2nd row on the right side at dotGo.

#golang #go #devconference

Trending Blogs

Recently Viewed Blogs

Sourcegraph @ dotGo