Inteview with Frank Müller: One Decade of Go - the Power of Concurrency

Frank Müller, Solution Engineer at Loodse, is one of the co-organizers of the GoDays conference in Berlin, which took place in January of 2020. It has been an exciting moment when Google announced its Language Go in 2009. After some hype and early years of establishing the language, it was settled as a robust and scalable fundament for networked systems. We invite you to enjoy a travel through a decade of our beloved Go within the interview of Grigory Petrov, Dev Rel at with Frank Müller. Evrone.com The Interview Hey Frank, thanks for your keynote and the report about the world of Go functions. It was inspiring to hear about the whole decade of your experience with Go! How did you join the Go community? Grigory: Before Go, I was working with Erlang and was interested in the concurrency in programming. Erlang was a very extravagant language. In 2009, it was the first time when I heard about Go and saw that it had a pretty similar approach. It had goroutines, the syntax that was familiar to developers who come from languages like Java, C, C ++. In Go, we had concurrency; the language was clear and readable. I started looking into it and got interested. Frank: Great! Go unites Java- or C-like syntax with Erlang-like concurrency. During the past five years, concurrency became wide-spread, it was introduced in Python and Ruby in means of coroutines, and it was a huge success. Go became famous because of it. After ten years, in 2020, what would you say about the Go language itself, its ecosystem, and the concurrency compared to other languages like Python, or, for instance, Rust? Grigory: Most of them work on a thread basis, which is not concurrency. The concurrency should be used as a design pattern. I don't think that it's good to put a task to the background and then wait for a reasonable response. When we have real concurrency, like an Erlang, we can design the software in a different way. That's the critical part; it's a design pattern, not the technology. And the technology is needed for the design pattern. Frank: Nowadays, we have Python, Node, Ruby, Rust with the same concurrency models. If we think about the Golang in 2020, what are the most significant Go benefits apart from its concurrency? Grigory: The concurrency was the reason why Go attracted my attention at first place; it is essential to let it run in modern distributed environments where you have thousands of connections. But the most important feature of Go is that it is simple and extremely productive. The Golang developers promised to keep the language standard. And they've been successfully doing it for the past ten years! They are focused on improving the language's robustness, its performance, adding new libraries. Go is just a robust tool for modern distributed development. I hope it doesn't change with the release of Go 2.0. Frank: Yeah, I remember the struggle for transition from Python 2.0 to Python 3.0, from Ruby 1.8 to 1.9. Let's speak about the microservices in Go. It often happens that the businesses come to the developers, require various sets of features for the project, and the software notably grows. Aren't you afraid that if the microservices have to turn into big services with lots of logic, Go will not catch up? Grigory: The microservices are focused on covering the tiny aspects of the business. What's interesting about Go is that it's not just the language, it's the community. The simpleness of the language led to the community that dislikes frameworks. It's OK to import a given package for a particular task; you can use a Spring framework, for example. We often see in the communities that every time somebody asks, "Which framework should I use for the web services?", at the same moment, the community answers, "Don't do it!." Very often you get the response "Simply use the standard library". It's not a language feature; it's more a community feature to stay away from large frameworks and large layers. Frank: Don't you think that such an approach limits Go to some simple things, and Go will never be used for complex business logic projects, like enterprise automation? Grigory: I've done business applications in the past, and out of my experience, they are by far more simple than technical applications. So the term "simple" is not the right term here. Using Go for typical business tasks won't be the problem. I remember developing a microservices-based distributed application for the logistics business. The microservices built with Go were great for logistics tasks. Frank: Alright. And I would like to conclude the interview with a question that I ask each of the key people in our industry. We, developers, like to name things, and we like to name languages. Python is the second-best language for any task. Javascript is a web language; Ruby is a productive language; Java is an enterprise language. How would you describe Go in one phrase? Grigory: I'd say Go is the language for the cloud-native world. Frank: Fantastic. Thank you, Frank! Grigory: