Go Toronto Meetup - Aug 2019
Aug 2019    |    toronto     go meetup     golang    


The Go Toronto meetup, GoTO for short, has been running on and off for many years since its inception in 2013. Huge shoutout to Tim and Zach for keeping it afloat, all the speakers for their insightful talks, the various companies whose offices we crashed and lastly all the folks that come out.

Check out the “What we’re about” section of the Meetup page for more info about the meetup itself.

Gophers have drifted in and out of the meetup, but the language and community are still as relevant as ever.

This year Go will be celebrating a 10-year milestone and 7 years of a stable 1.0 release. So the local meetup, the passionate Go developers around the world, all contributors and the core team itself will have much to reflect upon.

But that’s another post for another day. Back to meetup fun.


Location

The kind folks over at Horizon Blockchain Games offered to host the meetup on Aug 21’2019.

๐Ÿ•๐Ÿ• ?? You betcha.

Support from companies is what makes or breaks these meetups. We have been fortunate to have an enthusiastic and supportive ecosystem in Toronto.

In the spirit of the community both marketing and sales pitches are usually kept to a minimum, but sponsors are encouraged to chat about what they’re up to, what their team is like and whether they are hiring. In my opinion this is a win-win situation. Meetup folks get exposed to companies using or adopting Go, various tech stacks and a general feel for the company and industry as a whole.


Speakers

The first speaker was Peter Kieltyka.

webrpc: a simpler way to write api services


Google slides located here and the project there: github.com/webrpc/webrpc

Personal bias, I was quite excited and super intrigued by this talk because I’ve come to appreciate the power, safety and resulting simplicity of generated code, especially after using twitchtv/twirp for quite some time.

Think about all the upfront work, and maintenance, in a RESTful api:

  • routing, URL schemas
  • hand-written clients
  • dealing with and making conscious decisions on http semantics
  • serialization
  • etc.

Seriously, after one accepts code generated clients and servers one becomes liberated. It’s a feeling akin to the “he is the one” scene from the 1999 Matrix movie.


I’ve experimented with machinebox/remoto and gRPC. Also proteus, which works backwards by using Go code as a source of truth to generate protobuf (as an intermediary) and then to other languages.

But I never found the right development ergonomics as compared to twirp. But that’s a post in itself for another day.

As Peter points out, the goal of webrpc is quite simple:

Make it super easy and quick to develop type-safe Web Services for modern web applications

The idea is to reduce the amount of boilerplate code one writes and focus on the business logic, i.e., the “handlers” and the corresponding requests / responses. Furthermore, RPC frameworks provide an elegant way to interact with services, all parts of the application feel as if they are a single function call away.

Why not encapsulate the boring bits, with sane defaults, and focus on what matters?

I could probably spend hours talking and writing about this topic, but for now I’ll point the reader to the meetup recording, to be posted here shortly, and the slides.

A memorable quote, from this talk, arguably a great t-shirt slogan:

REST is making me tired


The second speaker was Vikram Rangnekar.

writing high-performance code in go


The talk content can be found here., recordings there.

If I get some time I’ll spin up a server to host these .slide files (ideally there would be a service that takes a link, parses the .slide file and displays it live). For now, if you’re feeling adventurous download x/tools/present and run present ./... from the root of the /slides directory.

So, performance.

  • code that runs fast
  • minimize I/O latency
  • efficient, in terms of GC (garbage collector, side note, really interesting blog post here)
  • etc.

I’d argue majority of software should be written with the following in mind: correctness, readability and simplicity as opposed to being very performant from the onset. Focusing on writing good software will prevent most scaling issues from happening in the first place; I think that was one of the underlying points of this talk.

That’s not to say you shouldn’t spend time properly designing systems up-front. There is a fine balance between the two extremes of never think about scaling vs making every line of code as performant as possible.

Thankfully the act of choosing Go will get you pretty far in terms of performance.

But, at some point (in the event your project becomes popular enough) you may be tasked with debugging performance-related issues.

There will be lots of low-hanging fruit.

Go provides tools to benchmark and dig deeper into the internals of your code, out-of-the-box!

The testing package supports benchmarking to gauge the performance of your code. Make sure there is a baseline metric, so as you refactor programs the performance doesn’t decrease. This should be measurable and incorporated into a CI pipeline.

Profiling data can be consumed by pprof. Vikram goes on with examples on using pprof to hone in on top allocating functions and subsequently on reducing allocations.

Interesting talk!

Lastly, if you’re interested in this area check out dgryski/go-perfbook.

Suggestions, corrections, concerns? reach out