What I Learned at GopherconEU

Me at Gophercon

Between the 27th and 29th of June, I attended the GopherCon EU conference. This was the second conference I had ever attended, and, after the great experience I had at Golab 2022, I was very excited about it, given that it is considered one of the “MVPs” of the Golang conferences around the world.

One thing that really made me attend this conference was the high amount of Google managers and developers that were in the audience as well as giving speeches. These are the people that make the Go magic happen, and I was really excited to meet them and hear what they had to say.

In this article, I will try to explain some of the things I learned from the talks I found most interesting (and was able to understand!)

Building Modern CLI Applications in Go — Marian Montagnino

This is a special bonus part! The day before the conference, I attended one of the workshops the Gophercon team had prepared. CLI Applications are not the type of projects I work on in Go, so I was curious about their structure and best practices. Luckily for me, Marian was there to help out with all my doubts.

We covered many subjects like:

• Design and development of a CLI tool in Golang
• Testing the CLI tool
• Integration of third-party APIs and libraries to your CLI tools
• Deployment and Documentation of your CLI tools

The workshop was centered around a Go library called cobra-cli. We worked with it during the entire workshop since it was built especially for CLI application development in Go. I found it very simple to use, combined with all the best practices and examples around CLI apps that Marian explained.

The workshop also covered application deployment using goreleaser which is something that I did not know about. It’s not just used for CLI Apps. You can deploy any Go project to multiple platforms using gorelaser.

I will not go into more detail. I could, since this was an eight-hour-long workshop, and each of the parts I mentioned above took us around two hours to cover, but you can find the complete workshop (examples included) here.

Big thanks to Marian Montagnino for the well-organized workshop! She was a great mentor, always answering our questions and doubts. She was very cheerful and always had a smile on her face! If you are interested in CLI application development in Golang, I recommend checking her book out. I have it (signed by her), and although I still have not finished it, it’s a good piece of IT literature to have for sure!

State of the Go Nation — Cameron Balahan

This was the first talk of the entire conference! Cameron Balahan, Project Manager at Google, started his talk with a brief walkthrough of the evolution of the Go programming language from its creation back in 2009 to its current version, Go 1.21.

One of the things that Cameron kept constant during his talk was the main objective of the Go team: Compatibility is more valuable than any breaking change and innovation. This answered one of the questions developers tend to have — will we ever see a Go 2.0? And the answer is no.

Cameron also showed some interesting statistics gathered by the team regarding Go usage:

• 3x more developers than 2018
• 93% of satisfaction with the language

How will the language evolve in the future?

• Generics. A topic that is very popular in the Go community. The generics package will only get bigger and better.
• Iterators. Which I believe is already here.
• Better onboarding for users. This includes documentation improvements and more precise error messages in the Go libraries.
• Backward and forward compatibility making Go production ready.
• Profile guided optimization as well as RAM efficiency.

These are just some of the things Cameron mentioned. He ended up giving a big thanks to the Go Community for all the help they have made (indicating the growing number of external contributors) in making the language better and better over the years.

Go Right Ahead! Simple Hacks To Cut Memory Usage by 80% — Yiscah Levy Silas

This was the talk I was most excited about! I love the topics of optimization and cost reduction, and with a title like “Cut memory usage by 80%,” Yiscah Levy got me hooked!

The talk started with a simple recap on why it’s important to optimize your projects:

• Scalability
• Reliability
• Reduce costs
• User experience

As well as the challenges of memory optimizations:

• Difficulty in reproducing. Local is not prod, and it cannot be replicated so easily.
• Tradeoffs. Memory vs CPU vs Code quality vs Other performance tradeoffs
• Third-party libraries. Sometimes we use libraries that are not memory-optimized, but we still need them

And then the fun part began! Yiscah started showing some tips to optimize your memory usage.

• Field alignment

Given the following structure definition:

type ExampleStruct struct{
    testBool1 bool // 1 byte
    testFloat1 float64 // 8 bytes
    testBool2 bool // 1 byte
   }

Having a structure defined like that will require a size of 24 bytes (three blocks of eight bytes). This is because a 64-bit machine can only get eight bytes of data at a time. Since we have defined testBool1 and testFloat1 in that order, they do not fit in one block of eight, and we need another one. So, we will pad seven bytes to the first block (where testBool1 is located) and then reserve another block for the testFloat1 and then, yet again, reserve another block for testBool1, padding it with seven more bytes. This can be optimized if we put both booleans in the same block. To do that, we can change the structure definition to the following:

type testStr struct{
    testbool1 bool // 1 byte
    test bool2 bool // 1 byte
    testfloat1 float64 // 8 bytes
   }

Now, we only need two blocks of eight bytes vs the three blocks in the previous definition.

• Size declaration

This one is easy. If you know the size of your slice or array, create it with that given size. Otherwise, each time you append a new value, there will be another memory allocation for the bigger array or slice.

s := make([]int,0) //Incorrect   
s := make([]int,5, 5) //Correct

• Regex on repeat

Another easy one. When you are using regular expressions, if the regular expression is used to match in multiple instances, don’t initialize the regex always. Try not to call this more than once during execution:

r, _ := regexp.Compile("p([a-z]+)ch")

• Goroutines

Finally, it was time for the dreaded goroutines, a powerful and dangerous tool if not used correctly. She mentioned some tips on how to manage memory usage like:

• Limiting the number of goroutines in your code.
• Always give them a cancellation token or a timeout to avoid prolonged resource consumption.
• Synchronize your goroutines properly.
• Monitor and profile using tools like pprof

Vulnerability Management for Go — Julie Qiu

Julie Qiu is a member of the Go Security team, and her talk was all about the new vulnerability management improvements that the Go team has made. After a quick introduction to the concepts of vulnerability and software supply chain, Julie got right into the question we all wanted to know: How do we detect vulnerabilities in Golang?

The first (and most “vanilla”) approach was to directly compare the go.mod file contents (that is, where all the dependencies of your project are indicated) against some vulnerability DB. Well, in a manner, that is exactly what the Go team did, but with some tweaks.

First, they needed to create a DB with comprehensive and high-quality data. To do this, they used sources like:

• GitHub vulnerability DBs
• National vulnerability DB
• Direct contributions from Go developers

The second topic they handled was “low-noise alerts.” Just because you have a vulnerable package imported does not mean you are directly exposed to this vulnerability.

Given the following diagram:

If you are directly importing Module A, which uses Function D from Module B, then even though Module B has a vulnerability, your project is not directly vulnerable since Function B is the one that has the vulnerability. The Go team decided that these vulnerabilities should be notified but in a different manner than a direct vulnerability that needs to be corrected.

Finally, once all the previous requirements have been defined, the Go Team wanted to make widely available tooling to detect these vulnerabilities. These include:

• Go CLI. The command govulcheck analyzes your dependencies and gathers all vulnerability information that your project might have.
• Golang packages page. When you search for the package, if it’s vulnerable, it will have a red flag, and once you click it, you will see a description of the vulnerability.

Example of a Vulnerable package

• VS Code Go Extensions. The inclusion of the Go Vulcheck Toggle.

Overall, this was a great talk, and it showed that Julie has experience in talks! It was straightforward, easy to follow, and very well-structured. It took on a major subject like project security and showed off all the new “toys” that the Go Team has made to take it head-on.

I have used govulcheck to test it out, but I still have some ideas on how to improve my vulnerability detection and correction (using govulcheck but I need to see if it can return a structured response like JSON so that I can process it) and I will surely be including it in my CI/CD pipelines in the future.

Useful Functional-Options Tricks For Better Libraries — Julien Cretel

This was a talk that, if I am being completely honest, I was not going to attend since it overlapped with one about testing I wanted to see. However, after some digging around, I liked the topic and wanted to see what Julien wanted to show us about Functional-Options.

The first part of the talk was an introduction to the Function-Options pattern. I will not go into it, but you can find a good explanation of the pattern here.

The second part of the talk was about when we should use this pattern and the best ways to implement it. Julien mentioned the following:

• Functional Options tend to be more “expensive” to use. Don’t use them in performance-heavy scenarios. They are good for middleware or initialization usage.
• Design functions as fallible. Just return an error and inform your users that there is something wrong.
• Guarantee insensitivity to function order.
• Elucidate multiple calls to the same option. This can be done by making your functions additive (the last option value added is the one that persists) or marking a failure (if someone calls the same functional options twice, return an error).
• Strive for immutability
• Declare a custom option type

func NewCORS(options ...Option) (*Middleware, error) better than ... 
func NewCORS(options ...func(*config) error) (*Middleware, error)

• Options should operate on an intermediate, non-exported struct type.
• Declare Option as an opaque interface type
• Consider enforcing constraints at compile time thanks to multiple Option types

Overall this was an interesting talk, made even more interesting because I had never heard of this pattern. I liked the way it was structured and that Julien gave some solid examples of when and how you should use it. You can check Julien’s presentation for examples of all the points I mentioned above (here’s the link).

Conclusion

There are a lot of talks that I did not mention, but I wanted to center this article on the ones I found most interesting (I don’t want to discredit any of the other talks, of course).

I must credit our Gophercon hosts: Mat, Ale, and Natalie. I really liked their positive vibe and how they gave their best to interact with the crowd and entertain us all (Mat, if you see this, maybe I can get an invite for the next Go Time episode 😉). That was one thing that I did not expect from the conference, and it was a pleasant surprise.

In conclusion, Gophercon EU was a fun experience. Although I left with a mixed sense of the talks (some I really enjoyed, others I did not understand or find that interesting), I’d recommend every developer to attend at least once. If not for the talks, just to be around the community and get in touch with your fellow colleagues. Like Cameron Balahan mentioned: One of the best things Go has, is its continuously growing and healthy community.

I would like to give a big THANK YOU to MagicBell, one of the sponsors of the GopherCon EU, for allowing me to attend the conference. Thanks to their giveaway, I got a combined ticket for a workshop and the conference.

I also want to thank TravelgateX for paying all the expenses for me to attend the GopherCon.

See you next year GopherCon. Who knows, maybe GopherCon US 😉

Happy coding :)

Want to Connect?

As always, feel free to contact me if you need some help with something 
I have mentioned or if you have a suggestion on how I can improve this 
article. 

You can DM me on my Twitter any time.