The widely used self-referential function pattern as options, originally proposed by Rob Pike1, allows us to design a flexible set of APIs to help arbitrary configurations and initialization of a struct. However, when such a pattern is cumbersome when we use one option to support multiple types. This article investigates how the latest Go generics design could empower a refreshed “generic” functional options pattern and show what improvements in the future version of Go could better support such a pattern.
Recently, I have been rethinking the programming patterns regarding
graphics applications, and already wrote a 3D graphics package in Go,
While I was designing the rendering pipeline APIs, a tricky deadlock
struggled with me for a while and led to creating an unbounded channel
as a workaround solution eventually.
In the Go 1.17 release, we contributed a new cgo facility runtime/cgo.Handle in order to help future cgo applications better and easier to build concurrent-safe applications while passing pointers between Go and C. This article will guide us through the feature by asking what the feature offers to us, why we need such a facility, and how exactly we contributed to the implementation eventually.
GUI programming in Go is a little bit tricky. The infamous issue
regarding interacting with legacy, GUI frameworks is that
most graphics related APIs must be called from the main thread.
The issue violates the concurrent nature of Go: A goroutine maybe
arbitrarily and randomly scheduled or rescheduled on different running
threads, i.e., the same piece of code will be called from different
threads over time, even without evolving the go keyword.
About six months ago, I did a presentation1
that talks about how to conduct a reliable benchmark4 in Go.
Recently, I submitted an issue #416412 to the Go project, which is also a subtle issue that you might need to address in some cases.