Tuesday, October 11, 2016

Impressions from DotGo 2016

The best thing about go is it's community. It has taken a language designed for systems programming and used it in many alternative ways. This boosted the development of the language and emphasized the consistency of go's design.

I attended dotgo last year and enjoyed it very much, so I came to this year's event with great expectations and I wasn't disappointed. The organization, the venue, the food and the happenings were excellent. The highlight of course was the giant French gopher which dominated the stage, and i also liked very much the idea of a professional illustrator that drew the speakers and the best moments of the conference. Unfortunately I am writing from a mobile device of limited capabilities and i can't post links, photos etc. You can find them at Twitter at the organizer's account @dotgoeu. They will also publish the videos from the talks, freely available to the public.

Now, the talks. I will present them not in the order delivered but rather grouped in three groups according to the major aspect of go they revolved around: language, tools, environments.

Language

These are the talks about how to write good idiomatic go.

The first one was from Dave Cheney and he talked about first class functions. He presented examples of functions that return functions and used them to simplify code and write more coherent APIs. This wasn't about functional programming. There is a duality between single method interfaces and functions and go's simple design makes it very easy and straightforward to alternate between these two, something that is very difficult in other languages. In go we get benefit from both sides of the duality.

The next talk was from Damian Gryski who talked about caching and memory layouts in modern architecture. He tried to simplify and present advanced performance topics and he did a great job. His advice: measure first, optimize later.

Peter Szilagyi was next and he discussed immutability and concurrency. Go has no support for immutable objects, so to build his object graph he needed some scaffolding. The resulting code was simple to read, understand and extend. It favors go's simplicity but raises the question if the language needs support for immutability.

Katrina Owen talked about a technique for refactoring that she calls "noop noop noop interface maneuver" and she used it on a buggy piece of code to make it more readable and testable. Basically the technique extracts pieces of code to small interfaces and assembles them in helper types. This can be done easily and fast in go because the types are open and there are no type hierarchies that you must be careful not to break or bloat.

The final talk this group was by Robert Griesemer, one of go's creators. He gave a talk about software design and prototyping. As a working use case, he extended go to support two dimensional slices and showed how good is go at rapid prototyping. A great talk that emphasized the cultural difference between hackers and engineers.

Tools

A good language should support good tools. Go does this excellently.

Rhys Hiltner presented practical examples of using the go execution tracer. This is a tool that gathers execution events, for example a goroutine starts, and presents them in a compact form to the user. It can be used alongside a profiler to check how a large program behaves. Rhys presented examples of application bugs, false alarms and bugs in the go runtime. That is the talk that emphasized the design consistency of go. You get an excellent tool from the standard library and you can use it in a uniform way to investigate your application and the go runtime all in once. Compare with other platforms that rise barriers between your code and the platform.

Next was Matthew Holt who talked about ACME, the automatic certificate management environment and how easy it is to use from go. He argued that we should encrypt our apps since now it it very easy especially in go. I am not a security expert to have an opinion on this but the talk received many kudos from people involved with the subtleties of TLS.

Environments

Go was designed to run in a networked environment but what exactly is a node of such an environment? Is it just a traditional computer?

Dmitri Shuralyov maintains gopherjs, a go to javascript translator, and he believes that a browser can be a very friendly environment for go programs. He run ivy, Rob Pike's apl interpreter, in the browser, used chrome to stream http content written with net/http and as this wasn't enough he demonstrated an example of GL written in go, running in the browser. A great talk. The point is that it makes you rethink the basic interfaces of the standard library and how they map to the browser environment. What is an io.Reader in chrome and how well the fetch API maps to net/http and vice versa. After you define these building blocks the code is the same, both for the browser and the desktop computer.

Go can also run very well in mobile devices. Elias Naur talked about the latest version of gomobile and the features that allow you to write go and create bindings for Java/Android and Swift/iOS. The percentage of go code in a mobile app increases but we are not to 100℅ yet. Daring explorers can program Android in Go straight away.

Next was Kelsey Hightower, of kubernetes fame, who talked about why static binaries that bundle application code and the platform runtime are great for deployment. He demonstrated the concept using kubernetes and increased the size of the cluster for each run. Go binaries don't even need a container like docker, although it is highly recommended but for other reasons not for the sake of deployment. It was a very nice and lively talk about the go feature we all loved from the first days of the language.

Brad Rydzewski talked about plugin architectures for go, or in his words "designing for the unexpected". When you design a system and you release it to public, you can't predict the changes. Sometimes a plugin architecture is more suitable for projects that customization needs are highly anticipated. This is a case where our beloved single self contained binary is not always the best choice. There are alternatives like custom binaries or RPC to a process running the plugin or RPC to a container running the plugin. Brad discussed all these and the new architecture of his CI tool that incorporates these ideas. Clearly this is an open topic and I would like to see a solution in the standard library.

Conclusion

I really enjoyed this year's dotgo and I left with new ideas, new images and new friends. The go community has the best balance between going forth and stay relevant. We want to advance but we also want to stay relevant. It is a great feeling to be a part of such an active and prospering community.

See you next year at dotgo 2017

No comments:

Post a Comment