I ' m speaking at Gopherchina and Gophercon Singapore

This is a creation in Article, where the information may have evolved or changed.

In April and may I'll be speaking at Gopherchina and Gophercon Singapore, respectively. This post was a teaser for the talks, were selected by the organisers. If you're in the area, I hope you ll come and hear me speak.

Gopherchina

Gopherchina is the third event in this conference series and this year would return to Shanghai. I was lucky to attend the event, and am looking forward to 2017.

The Hidden #pragmas of Go

Go isn ' t like C. It doesn ' t has a preprocessor, it doesn ' t has macros, and it certainly doesn ' t has #define , but Go does has pragmas.

What is Pragmas? The name come from the #pragma declaration, which tells C compilers to alter their interpretation of a piece of code. Now, Go doesn ' t has a #pragma directive, but it does has ways of altering the operation of the go compiler via directive s Yntax hidden in comments.

This talk would explore the history of these directives, what and why they is used, and how can I, but probably shouldn ' t , use them in your own code.

Gophercon Singapore

Gophercon Singapore is the latest in the Gophercon franchise, and as flight times go, relatively close to home. I ' m delighted to has the opportunity to present at their inaugural conference.

Concurrency Made Easy

In my experience, many people who come to Go doing so because they has a problem where being able to run more than one task At a time in their program would is beneficial. Ruby and Python programmers come to Go because the concurrency stories are much better, the same is true of Node programmers; The event loop is still inherently single threaded.

But, the most programmers the stick with Go for a while tend to look back on their early efforts and say things like "Wow, I really went overboard with channels " or " I went crazy with goroutines when I started writing Go. It was impossible to understand what theprogram did ". For people who learn Go formally from an instructor or a book, the concurrency sections is always the last section They cover.

So there are a dichotomy here. Go ' s headline feature is simple, lightweight concurrency. As a product the language sells itself on that feature alone. On the other hand, there are a narrative that concurrency isn ' t actually so easy-to-use, otherwise people wouldn ' t make I t the last things in their books or classes, or perhaps more accurately, concurrency are not the solution to every problem.

With this as a background, I ' d like to explore some strategies for using concurrency in Go without the pitfalls of Convolu Ted code, the importance of memory ownership, and the best-of-the-structure a Go program using Goroutines.