Interview with Anderson Queiroz: Golang is The Perfect Language for the 21st Century

Introduction

We’re thrilled to present an in-depth interview with Anderson Queiroz, Lead Backend at Blacklane. Grigory Petrov, Developer Relations at Evrone.com, spoke with Mr Queiroz at the GoDays conference in Berlin that was packed with hands-on workshops and developer talks about Go.

Anderson Queiroz presented a report "Writing a code generator to make your code more secure" at the conference and we couldn’t miss a chance to hear from him first-hand about the advantages and downsides of Golang compared to other languages, the ecosystem of Go, the error control and code generation.

The Interview

Grigory: Anderson, thank you for your talk "Writing a code generator to make your code more secure." Surely, code generation is one of the big things nowadays. Before we talk about it, can you tell us a little more about how you started using the Go language? Why did you choose Go, among other things? 

Anderson: Well, in my previous company back in Brazil, one of our developers came up with the idea of building a new service in Go. He introduced Go to the company, and we built a really good piece of software, replacing Java with Go. I got interested in it, began to explore what Go could do and realized that it was very different from other languages. With Go, you can see the sides of the binary, the speed, and the memory consumption, all that is really helpful.

Then, I started to learn Go a lot by myself. I read "the Effective Go" which is a really good source for someone who is already a software engineer, but wants to learn a new language. "The Effective Go" perfectly explains what Go is, how it works, how things are done in the language. Later, I came to Berlin and got a chance to start a full-time job in Go. Since then, I fell in love with it and always try to learn more and share the Go philosophy with the world. 

Grigory: That's cool! At the conference, I heard that the developers often move from Java to the Go language because of a binary footprint and a memory footprint. But, let’s admit that Go is not all about rainbows and unicorns. It does have negative aspects. Judging by your transition from Java to the Go language, what are the downsides of Go compared to Java? 

Anderson: In Go, you have to start to take control of a lot of stuff. Most of the other languages have been out for a long time, they have huge libraries, all sets of frameworks. In Go, we don't have a lot of things that you got used to in other languages, and we don't have generics. It's harder to implement methods for every single type. 

In Go, a bit of repetition is not bad because even when you keep repeating the code, you start to understand the costs. We have more work as engineers who write the code, but it also brings awareness of what's happening. Such a trade-off is good, mainly for new developers. I started to learn to code with C by myself long ago, and I got a computer science degree in universities in Brazil and Glasgow.

I can see the code and understand the hidden costs, but a lot of people who are just learning from tutorials don't see it. I believe it's quite important to learn and understand stuff better. 

Grigory: Yeah. Talking about the Go language ecosystem, I often hear that it's not so big. For example, if we take Java, Python, or Ruby and we have a task outside of simple API, for example, we need to rotate, emerge, process some audio, compress or decompress files. In Python, Java and Ruby, we have dozens of different libraries competing with each other. We just pick the best library and use it. But in Go language, if I want to rotate or resize the image or put a watermark on it, I will have just one library, which will be a rough wrapper over ImageMagic. That makes me sad. From your point of view, what do you think about the Go language ecosystem? Is it enough for your work and, what do you do if you can't find the library for your task at hand? 

Anderson: Oh, that's definitely true. Go is a new language. There is a huge part of the community that's used to the idea of “cloud development”. They are writing web servers or cloud infrastructure tools, everyone knows Docker and Kubernetes. I strongly believe that a number of libraries will appear as Go becomes more and more available. A couple of weeks ago, we had to calculate the distance between two points, and I saw my colleagues having to implement the function manually.

But also that's the point of it. You can find the definition of the implementation quickly on the Internet. You get to spend a few more minutes, but you're going to get more knowledge, and that's the fun thing. You pick the best library, how many times should you re-inspect it to check what you are bringing to your code? It’s very important to be careful with what you import. 

You should find a quick summary of packages, read what package is important, what it does, check if it is licensed or not. I think it's really good to think twice - do we need this library? Do we know what these libraries are doing? Just check the dependency. I think it's a part of working with the language. Even though Go is consolidated in the market, it's still new. It's only ten years old, it doesn’t have everything we need.

If you find something that's missing in the language, I highly recommend you to contribute to open-source! It’s going to go live, get a couple of stars on Github, somebody will notice it, and it might grow into a really big thing. 

Grigory: Absolutely, it's amazing to be a software developer in 2020! Let's talk about the language itself. In a couple of years, we will have the Golang 2.0. Until now, we successfully solved the Gopath issue. But, the next issue, error control, is not resolved yet. In the Java world, if you want to handle some errors, you just use Happy Path for your code, put a few try-catch blocks if you expect some errors, and a the majority of error control is under the hood. If something breaks, it's an exception. Unfortunately in Golang it’s different. Do you think that Go has too much error control? 

Anderson: Well, definitely when I started Go, I thought that was too much. I remember myself trying to abstract something, extract some small piece of error handling as a method. There is no straightforward way around it by the idea that Go is built with. But one right side of it is that nothing is going to explode in your hand. Because in Java program it is usually clear when things can break. When you code in a language like Cotlin, Python or Javascript, there everything can explode.

However, in Go it can't. If things fail, it’s something extraordinary. I use static analysis to analyze the code and cyclomatic complexity to see how complex the code is, I try to bring some formal, not opinionated information about the code. In Go, you have so much error handling that the code itself becomes bigger. I think Go should definitely improve but shouldn’t lose the security and the safety that explicitly error handling brings. And I think that's good. 

Grigory: Let’s talk about the features that we, Gophers, want to improve in our language ecosystem tooling. What are the best things to improve in the Go programming language in five years to come? 

Anderson: I think error handling is important, you want to have less repetitive code, but in a way that it keeps the safety. Golang should be more documented, but it's a matter of time. Sometimes I struggle a bit with how to replace modules to be able to test one program that's using the library we are developing as well. I think these things are going to improve and I think they are going in the right direction. 

I'm not going to speak about generics, because in most of the work that I have done, you don't really need generics. In Go, I could probably just do things with some type checking. I can say that I'm pretty happy with what we have in Go now as for my current needs it's good. 

Grigory: Yeah, Sounds great. And, let’s get back to the topic of your talk, code generation. In Russia at our Go conferences, I heard that our developers like to write the high-level code in Python or Ruby and generate Go code from these high-level languages. For me that sounds weird. What do you think about code generation in Go and what are typical tasks for it? 

Anderson: In my opinion, code generation is really well applied to do things that are too repetitive to be done in real life. I wouldn't use another language and generate the Go code from it. The best language to write JavaScript on is JavaScript, right? The same is with Go. 

You should be careful with the code, because you can miss the full power of the language. I think when you're starting, it might be something that might solve your problem, but I would migrate and write proper code. If you're just writing the whole production code in one language and compile it into Go, it's going to be a lot harder. So I don’t think it's the best option.

Grigory: Yeah, that’s true. Can you name one thing that you like most about the Golang?

Anderson: The fact that it's a simple language. For example, if you change the job and have to write project in Java, it would be the same Java, but you can just feel that you have to learn everything again, because you use a different framework, for example. In Go, I have a really good understanding of the language as a whole. Things usually don't surprise me. I think this is the one thing that everyone likes about Go.

Grigory: Sure. We, software developers, like to name things and we like to name languages. Java is the enterprise language, and Python is the universal glue and the second best language for any task. Ruby is the productive programming language, Javascript is asynchronous web language. If you wanted to name the Go programming language, how would you call it in one sentence? 

Anderson: I’d say that Go is a language built in the 21st century for the 21st century. It is really the first language that I saw that was really easy and helpful for doing many useful things. That is what Go is for me, the perfect language for the 21st century. 

Grigory: That sounds great. Thank you for your time!