Qs. Welcome and thanks for taking out time to share your thoughts. For the benefit of the readers, could you tell us something about your-self?

Sriram: I love developing systems, and over the last 27 years, have written everything from operating systems for embedded devices to enterprise-scale distributed systems. I also have a love for programming languages, and am constantly on the lookout for a language that is high-level and expressive and yet suitable for building low-level software (like network stacks and operating systems). I now straddle industry and academia; I teach an advanced distributed systems course at IIT Bombay and am writing a book on that topic.

Qs. Why and when did you decide to start working with Go? Sriram: I was very influenced by CSP and the Pi calculus, and the languages Occam, E and Erlang. Spending some quality time with Tony Hoare and Robin Milner (at Cambridge University) got me to start seeing architectures at all levels (from CPUs and their memory hierarchies to clusters to WANs) as communicating state machines (CSMs). Many of the patterns applicable to distributed systems are directly applicable to designing lock-free data structures, if you view the underlying hardware as a composite of communicating state machines.

For a while now, I have been exploring different mechanisms for supporting hundreds of thousands of concurrent CSMs. I learnt to express problems in terms of coroutines from Mr. Coroutine himself, Martin Richards (inventor of BCPL, precursor of C), but didn’t care for limitations of that solution, such as fixed-sized stacks and lack of fault isolation. My PhD thesis was an attempt to deal with these issues while keeping the performance and space advantages of coroutines – take a look at the Kilim project for a way of supporting millions of ultra-lightweight threads in Java. And of course, I was very familiar with Rob Pike’s work on NewSqueak and Plan9.

So, when Google’s Go was announced, it felt so familiar that it was anticlimactic! At the same time, I was excited that a C-like language from with lightweight threads had the possibility of industrial adoption, following Google’s lead.

Qs. How should one go about learning the Go language? What material (books, eBooks, online tutorials etc.) would you recommend?

Sriram: One can spend way too much time just reading, and not doing anything. I’d spend a day or two going through the materials on golang.org to get an overview, then start implementing tiny projects (walk a file system to detect duplicate files, a small parser, an HTTP server and so on). For every package in the library, think of the smallest project (not more than 2 pages of code) to use that package. That’s how you learn to ask targeted questions and to appreciate nuances in answers.

My students at IIT are given just a few days to get up to speed in the language, then off they go to build systems. I could not have done this with any other language.

Qs. What best practices are most important for a new Go programmer to learn and understand?

Sriram:

• Use the testing, race-detector and go vet tools at all times.
• Understand the performance and space cost of features. Many Go programmers tend to start using goroutines a bit too liberally. Prof. John Ousterhout has a term called “classitis” – “classes are good, so more classes must be better”. Goroutines are good and inexpensive, but they also result in independent failure modes, increased communication complexity. They are an appropriate tool to implement concurrent behaviours, but beginners make the mistake of assuming that goroutines allow you to do more things in parallel, which is not always the case.

Qs. What are the pros and cons of Go that are being discussed in the development community and what is your opinion on that?

Sriram: One man’s Occam’s razor is another person’s regression. People coming from other languages miss generics, functions such as filter and fold (and writing one is truly ugly in Go), and exceptions. Although I have learnt to live without them, I remain hopeful, since Swift and D have shown a syntactically and semantically uncluttered way of incorporating generics into the language, while maintaining respectable compilation speeds.

The good part of having such a simple language is that one doesn’t spend time wondering whether some code or architecture is idiomatically the correct way to go … there are not that many ways to do it. In Scala, I get paralyzed designing a collection class in “the Scala way”, in addition to worrying about covariance, iterator design, number of copies etc.

What Go lacks in purely syntactic terms is compensated by the strength of the runtime and library ecosystem, and the relentlessly engineering-oriented culture of the community. In my mind, it ranks highest in its ability to get stuff done without much ado and with much directness (e.g. no MetaFactory objects ala Java), combined with reasonable performance and space efficiency. I have noticed that in languages that support high levels of abstraction, there is a tendency to start creating generalized frameworks far too early. The Go culture is refreshingly free of premature abstraction.

I am especially biased towards the seamless first-class support for lightweight threads in the runtime and in the libraries. Consider, for example, the amount of time one spends in Java and C++ worrying about blocking the thread, which is why you have so many asynchronous networking and event frameworks. In Go, one simply blocks without worrying, and all network I/O gets multiplexed without blocking the kernel thread. Hopefully, async disk I/O will be supported as well one day.

Qs. Most beginners in Go would like to contribute their time, skills and expertise to a project but invariably are unaware of where and how to do so. Could you suggest some?

Sriram: Sure. Here are some that occur to me.

• Take an existing project that interests you, and insert logging statements liberally. Then selectively enable the logs of different subsystems to figure out how they work and interact. For the benefit of others, you could put together an “internals” document. In a short time, you’ll have enough insight to contribute productively.
• Take a field that interests you and do something simple but non-trivial. If you are interested in a databases, build a simple consistent key-value store, for example. This is akin to picking up speed on the highway on-ramp in order to merge seamlessly with fast-flowing traffic on the highway. I prefer this approach to learning, because the insights you get from doing something from scratch helps you see both the clever aspects and misfeatures. Even a well-known architecture will have bugs and accidents of history, and may be forced to propagate a bad design in the interest of backward compatibility. It is good to approach the problem from a clean-slate.
• My third suggestion is to write an efficient Go wrapper for a C library. This can be a useful contribution to the community.
• Finally, take some of the performance shootouts (search for “golang vs. … performance”) and try to improve upon the answer.

Qs. What has been your biggest challenge while working with Go?

Sriram: None that I’d really call ‘a challenge’ .. it really is a trouble-free language. There are a few annoyances, like lack of a good source-level debugger. But it is a young language, and I am willing to wait.

Qs. What types of applications are currently being developed in Go and what changes do you foresee over the next year or two?

Sriram: I’m interested in developing large-scale distributed systems, and while I don’t expect earth-shaking changes on that count, progress is steady and fast. I expect there to be a ton of clustering frameworks in a years time. Docker and etcd have made it cool to use Go in the cloud (outside of Google), and more will follow.

Qs. How do you see the market for Go Programmers in the work place? What is the future for Go?

Sriram: Early adopters are all over the language, if Hacker News’ front-page is any indication. I believe Go is on the cusp of widespread adoption, and expect there to be a steady movement from Java, Scala, Ruby, Python and C++ to Go. I think the turning point will be when the GC and runtime performance unequivocally overtakes the JVM in all cases.

Qs. Do you have any other suggestions for our readers?

Sriram: Just build stuff.

Thanks Sriram for sharing your views with us. I am confident that your insights would help all the would-be Go programmers. In case you have any queries and/or questions, kindly post your questions here (as comments to this blog post) and Sriram would be glad to answer.

Tweet
← Back to blog home comments powered by Disqus