Interview: Jaana B. Dogan’s vision of Go

Jaana B. Dogan and her vision about Go

The conference dotGo was the perfect occasion to interview Jaana B. Dogan, Software Engineer at Google. Siegfried Ehret seized the opportunity to learn more about her role in developing tools like pprof and her vision of Go.

Siegfried Ehret: Classic and inevitable first question, who are you?
Jaana B. Dogan : I am Jaana B. Dogan, I am a software engineer at Google. I currently work on our instrumentation framework. Internally, it is the central framework where we do stat collection, tracing and so on. It is also the common context propagation layer for all languages.

How was your day ?
Good and very busy! When I was trying to get prepared this morning, I was very anxious and my slides were not ready. I had two versions of the talk: one was 10 minutes long and the other one was 30 minutes, and there was no way that I was going to end up with something that is going to last 18 minutes… So it was a little frustrating.

What is your typical day?
So, I am kind of like leading the project and it is a good mix of negotiating with people, writing code and experimenting a little bit… Doing design docs, reviews… I enjoy it so much because I have the freedom and flexibility to do different things. Some of these tasks are coming in cycles, and they will define my days.

Where are we today in the tooling?
In Go 1.10 there will be a new Web UI coming to pprof, so you will be able to see pprof on http when you set the -http flag and it will basically work like the pprof tool, but in a web page. We have the flame graphs, which is contributed by Netflix, which is awesome! Lots of people use flame graphs as their entry point for profiling, and it will be such a good contribution, because we will provide this out of the box and people will know about their dependencies and run it so easily without extra stuff. It lowers the entry barrier.

About Go, what is your favorite feature?
I think all the concurrency features, even though sometimes the internals are confusing. There are tons of optimizations that I discovered when I was learning more about the scheduler. There are tons of hooks that optimize things because the scheduler knows a lot about what is currently running, and the concurrency, restrictions and so on. So most of the concurrency features are the reasons why I actually ended up writing Go code in the beginning.

What do you expect from Go 2?
Error handling, we need something about that. Generally speaking, we are not doing a great job about it. Lots of users just bubble up the errors and we are not giving them the primitives to understand the current calls and what the error could be and like how they can handle it. We also are not providing all the diagnostic information on it, you know, like the stacktrace, frame pointers and so on… So you have 2 options: either to handle an error or to report it and we are bad in both, so I really hope that we will have better error handling.

I also really want to see generics in some sort of form that looks good within the type system, but it will be a significant rewrite of everything, probably. This is concerning all people because of the possibility of fragmentation.

How did you end up working on the lower parts of Go, like the scheduler?
I am not working on the scheduler but on diagnostic tools, just to clarify! But sometimes, I have to dig to understand how things make sense and what we need to instrument. I used to work on platform teams and, at some point, when the Go project was becoming more of a successful thing, there was a possibility that I can actually join the Go project. I was initially thinking that my stronger skills are API design and tooling because of my background in platforms. But I became passionate about diagnostics very recently and it contributed a lot, I mean I just wanted to get out of my comfort zone and learn.

Do you have a favorite quote?
Yes, a quote from Sam Boyer!

Design depends largely on constraints — Charles Eames

That is my new favorite quote! The whole idea about constraints driving the design is something that is so essential but I think we underestimate it a lot. Especially as programmers, we like to abstract things and just like create these different boundaries than reality.

How would you convince someone to work with Go?
I would first try to understand what type of problems they are solving and see what they need and what parts of Go align with their problems. I think it is also frustrating and unrealistic to suggest using Go to someone if the problem they are trying to solve is not really aligned with our ecosystem or the solutions we provide.

Once we can agree it is a good solution, the conversation evolves to become more like “these are the things I wanna do”, and “how can I learn ?” and the person usually go through the typical learning cycle of Go: existing docs, the Go Tour, Effective Go, all the written material, and good API design. I think we are lucky in terms of API design, readability, and there are still material out there that I suggest people to go through. For me, what was really useful was actually getting my code being reviewed, and I was so lucky because Brad Fitzpatrick was reviewing my code! I ended up learning Go so well because I was lucky. Contributing to a Go author’s personal project would also be awesome because you can learn a lot by learning style and it is a way of thinking.

Great, thank you for your answers!
Thank you so much!

Links

Vous aimerez aussi...