Notes from Gotham Go

Notes from Gotham Go
Thanks to Anthony Quintano for the base image! CC BY 2.0

Last week, I had the pleasure of joining gophers at Gotham Go. It was a incredibly dense single day of information. What follows is a quick impression of each talk, along with links to more detailed material. Special thanks to Peggy Li for tossing her notes on github!

UPDATE: VODs are appearing online now. You can view these talks on Youtube.

/ruby/go our path from ruby to go

[tweet id=649949496089157632] Brittany Wald and Jen Eisenberg shared a few of their learnings while building a highly scalable  API in Go. They work for Paperless Post, which relies heavily on Rails. For this project, they chose Go. Their talk is a guide through a Rails dev’s journey into Go.

They started with a look at requirements. The service would need to accommodate tens of thousands of users, with potentially millions of requests. Rails seemed like it might not be the best choice, specifically because Paperless Post is also eyeing microservices these days.

Brittany had a few great quotes about their journey to Go. A favorite was, “All gaps in your programming knowledge will eventually resurface as bugs in your code.” If you’re interested in learning more about the bumps they hit, check out the more detailed notes over on github.

Additionally, once it’s complete, their app will be opensourced at github.com/paperlesspost/rollouts.

Fuzzing Beyond Security: Automated Testing with go-fuzz

Filippo Valsorda from CloudFlare spoke next.

Filippo started with a question, what’s the usual development cycle look like for code that parses strings? Write a function to parse strings, then you write tests, and if it seems like it’s working then ship to production.

Pretty quickly most devs bump into some odd user inputs. Fuzzing is a good way to find these odd strings before users do. If you’re unfamiliar, fuzzing describes feeding programs automatically generated inputs with the intent of triggering unexpected behavior. Fuzzing starts with a sample string, then mutates it, and tests again.

Filippo recommends fuzz testing anytime you expect users to bump into corner cases. Those tend to be difficult to catch in a pre-release brainstorm. You can read more about how fuzz testing works on their blog about it.

Using go/types for Code Comprehension and Refactoring Tools

[tweet id=649953890172059648] Alan Donovan is a Google NYC engineer. He focused his talk on Go’s tooling, and gave a pretty snazzy live demonstration of some of the power.

The first of Alan’s demos was a naive search and replace. He showed how this frequently results in bugs. He then whipped out a tool called gorename. Which, like magic, deftly sidestepped + warned when naming conflicts appeared.

Some notes on other snazzy tools, like Oracle can be found on the github notes.

The core lesson from Alan’s talk is that most of a programmer’s time is spent doing menial tasks. “What types satisfy this interface?” Lightweight solutions to these problems are the sign of a good language.

go get -news (Using Go and Python NLTK for news analysis)

JP Robinson is an engineer at The New York Times. Similar to the first talk, they’re a shop that doesn’t usually use Go. In this case, they lean heavily on Python. JP shared learnings while porting a news service over to Go.

The service in question performs natural language processing on emails, and content from other services. The output of the service is statistics about the amount of duplicity, who broke the news first, etc.

For details on JP’s project, you can head over to the NYT blog or check the github notes.

The main lessons JP offers to other folks making the leap:

  • Always pick idiomatic 3rd party libraries.
  • Use bytes over strings, where possible.
  • If you can’t fully rewrite a service, it’s always possible to abstract it.

The “Modern” Garbage Collector

Verónica López is a physicist turned developer at Ardan Labs. Her talk was about both the technical and social impact of Go’s latest 1.5 release. She presented an update to Go’s garbage collection, which has a few implications in both fields.

As part of the technical side, Verónica stopped by a 1978 paper from Djikstra, and Erlang’s VM. Both of these influenced some of the decision making behind the 1.5 GC tweaks.

The social impact is that the recent changes silenced many of Go’s critics. Which means, to folks interested in tinkering with Go, the language suddenly appears a lot more accessible.

At the end of her talk, she offered a bit of insight: Go only very recently switched to bootstrapping the compiler. The first step of bootstrapping is just to get it working. The next step is optimization!

Go Highlights from the New InfluxDB Storage Engine

Paul Dix is the CEO of InfluxDB. His talk is about the nitty gritty details of data storage. If you’re a data geek who loves diving into algorithms, this talk is for you.

Paul detailed how he was able to utilize Go and a few clever algorithms to achieve a massive write throughput and a 20x improvement in compression.

A detailed look at the technical bits should be available on InfluxDB’s blog later this week.

Paul’s Go specific piece of wisdom is: Not having generics is actually Ok! This means you may occasionally have to copy and paste some code. But, at the end of the day, no generics creates more readable code. All of us read a lot more code than we write.

Introducing GoBridge

Verónica López retook the stage to share a quick note about a new Go community, Go Bridge. If you’re familiar with Rails Bridge, it’s the same sort of community.

Their goal is to educate underrepresented communities. This is good news for all of us as it both increases adoption of Go, and increases diversity.

If you’d like to get involved, check them out at github.com/gobridge.

Boring is Beautiful

[tweet id=650016523730448384] Kyle Erf is a developer at MongoDB. His talk took a bit more of a philosophical slant. In addition, Kyle shared a few of the common mistakes he sees new Go developers making.

From the high-level Kyle says, “Good code is easy to understand, easy to work with, and easy to replace.” He reinforced this point with a 2,000 year old Daoist parable. Enticingly, it’s titled ‘The Dexterous Butcher.’

Details on the specific beginner mistakes can be found the github notes.

Go can make you better at your job

[tweet id=650023797626675200] Brendan O’brien is a designer turned CTO, and I should mentioned: also a proud Iron.io customer. His talk was one of the best philosophical takes of the day. Brendan asked a few questions to kick things off.

First, “[from] what perspective do our tools ask us to take on a problem?”

Brendan is a fan of the trend towards simple, opinionated, tools. Go being chief among them. He warned that there’s a dark-side of highly opinionated, as well.

As an analog, Brendan introduced the crowd to the International Style of architecture. Like Go, IA is a highly opinionated take on a subject. But, contrary to Go, International Architecture, “asks you to take a reductionist perspective on problems.”

Go doesn’t ask you to take any perspective. It’s boring. And, boring gives you more time.
Less mental overhead!

This means we have more time to engage nicely with non-technical people. Which means engaging in real issues.

Chaos Monkey on Your Laptop

Matthew Campbell was the back-end server lead for Eikon Messenger. This was an app like Slack, but aimed at financial institutions rather than developers. The requirements called for supporting 300,000 concurrent customers and some complex use cases.

To complicate things, actual money would be made using this product. So, there was a very low tolerance for bugs. Matt’s talk was about his need to properly flush out bugs, and how he went about it.

A jump to a full-fledged Chaos Monkey system is daunting for most. So, Matt’s talk is a nice guide for how he was able to tackle the problem incrementally.

Detailed notes on his journey can be found here.

Go and gRPC

Sameer Ajmani leads the Google NYC Go team. His talk was about a snazzy new tool, Google RPC. It’s a high performance approach to RPC.

gRPC is the open source version of an internal tool at Google called Stubby. Sam’s talk included a run through some common RPC use cases, and a live demo!

You can find his slides online, and notes from his talk on github.

gRPC.io is the new tool’s homepage. It’s available in 10 different programming languages already!

What’s New in Go Crypto

[tweet id=650046334754521088] Nick Sullivan is a lead on the security team at CloudFlare. His team has created and open sourced several Go projects including Red October and CFSSL.

His talk was a look back at the journey some tools took on their way to open source. For example, through some clever assembly coding tricks from Nick’s team, many of the functions of the Go crypto library have seen up to 20x boosts in performance.

Some of this work is even being leveraged by nifty projects like Let’s Encrypt.

Slides from Nick’s talk are available online, as are a few notes. This is a great one for the InfoSec crowd.

The Legacy of Go

[tweet id=650054461042393088] Dave Cheney closed out the day. He’s a Go contributor and passionate advocate of Go.

Dave started with a few hard questions.

  • How will Go be remembered?
  • What’s the biggest mark that Go will leave on our profession?

To answer the above questions, he took a look at the legacy of a few other popular languages and frameworks. C, C++, and even Rails got some stage time.

Dave took a guess at what will likely turn into Go’s legacy by naming:

  • Go’s opinionated nature (go fmt)
  • The removal of thread management (goroutines)
  • Objects defined by behavior (interfaces)

Finally, Dave closed with an inspiring thought. “Almost all the Go code that will be written, has yet to be written.” We should optimize for this larger group of people who have yet to write Go code.

For more on Dave’s talk, check the github notes.

Conclusion

[tweet id=650057736214970368]

Gotham Go was a blast! I’m inspired to get hacking on a few projects. I know after talking to many of the other conference goers, I’m not the only one.

Echoing the Dave’s closing remarks, I’m also looking forward to more user groups and more events. For our part, if you’re in the San Francisco Bay Area join us at the next GoSF event!