Can you tell us about your experience at dotGo 2014? Any updates to your talk from back then?
I really enjoyed speaking at dotGo back in 2014. I found the challenge of preparing for the 18 minute timeslot made me focus precisely on the idea I wanted to communicate. The dotGo format really challenges speakers and I think the audience get a lot of value from a day full of talks without the waffle that you can perhaps away with in a longer speaking slot.
The dotGo format really challenges speakers!
When I spoke at dotGo in 2014 I wanted to tell people about Rob Pike's Self referential functions blog post, which I felt had not received enough attention. In the past two years its been wonderful to watch the idea mature from Rob's original blog post, to my presentation, to the gRPC project, who have continued to evolve this design pattern into what I think it its best form so far.
What is your current involvement in Go's development? Do you have plans for the 1.8 cycle?
As someone who cares a lot about Go advocacy, fast compilation is a cornerstone of the promise of developer productivity Go has made with its users. My main focus for 1.8 is the same as 1.7, keep the pressure on compilation speed to get back to where it was in the Go 1.4 days.
I wrote about the improvements that were made back in July (http://dave.cheney.net/2016/04/02/go-1-7-toolchain-improvements), which holds true for the version of Go 1.7 that shipped in August, but there still remains a lot of work to do.
With much more capable committers than myself like David Crawshaw, Josh Bleecher Snyder, Matthew Dempsky, and many other, doing the hard work to improve the compiler's data structures and algorithms, and Keith Randal and his team continuing to improve the quality of the actual code produced by the compiler (and as the compiler compiles itself, the quality of the compiler) the outlook looks good.
However for at least a year now, since the move from google code to github, we have not had a reliable set of per commit performance benchmarks for the compiler and standard library. If I serve no other purpose in the Go 1.8 cycle, it is to continue to track compile times and keep this issue front and center of the people who care about the speed of the compiler.
I'm also working on a proposal to bring some of the ideas from my errors package (https://godoc.org/github.com/pkg/errors) into the standard library package, of the same name, in time for Go 1.8. Hopefully there will be something for people to debate by dotGo.
You are doing a workshop in Paris on October 9, the day before dotGo 2016. What can we expect?
Back in April I gave a talk about writing high performance Go programs at GopherChina in Beijing. In preparing that talk I found had to cut out so much material that I started to wonder what I could do with all the bits that did not fit into my time limit.
I really want this workshop to be interactive, not just three hours of me waving at a screen.
Thanks to Ferdinand and the rest of the dotConferences team I'll be hosting a half day workshop on writing high performance Go programs on the 9th of October. This will be the first time I've given this performance focused workshop.
I really want this workshop to be interactive, not just three hours of me waving at a screen, and it is my hope that the workshop participants will be able to apply the material to their own programs during the class.
If you want to attend this workshop, you can register here.
You are a speaker at dotGo 2016 as well, can you give us a few spoilers on your talk?
A few months ago, when I was talking to Gophers at a conference in London, several of them noted that while they understood the notion of a function that returns a function, they were worried that other Go programmers would not be able to understand this style of programming.
I think that first class functions are a very important, and powerful idea, and depending on your background as a programmer, either something you're very familiar with, or something that is totally foreign. My talk attempts to demystify what first class functions, or as some people know them, closures, are, how you can use them, and if there is time, show a few things that we can do with them that are unique to Go.
Anything else you'd like to share?
I'll also be at the golang.io meetup in Paris on the 11th of October presenting a talk called "Gopher Puzzlers". If you're going to be in Paris on the Tuesday, I encourage you to come along and test your knowledge of how well you know our simple language.