Using Go plugins in your projects comes with a lot of caveats. As of writing, there hasn’t been much development on the feature recently. The commit history shows us that the last commit happened nearly 2 years ago. On the gopher slack, the sentiment, more or less, is that this is not a priority anymore. Along with this, there are multiple issues that come up with maintaining projects that use it:
I was on the hunt to find out how to organize my blog and project archive pages by year in Hugo. After being unable to find any easy solutions I decided I would sit down and write the go template to render these pages myself. The idea was simple, iterate over the list divided by year into sub lists and render tables, but it turned out to be a bit tricky.
If your CGO development toolchain depends on external dependencies such as system libraries, or you want to develop on an older version of go while having a different version on your host, you can use a docker container and mount the source from your host machine and build the project inside the container. This can enable us to have a consistent development environment across various developers and their host systems without having to modify system libraries.
Go recently introduced a heavily requested feature that allows programmers to set socket options before accepting and creating connections. You can find a mention of this in Go 1.11 Release Notes. Although, not many have written on this and implementing this is a bit confusing due to a change in the way one has to implement this. So I decided to share this with others who might be interested in using this feature.
I had originally written a Lyric API as a hobby project way back using Node. I published it on github as a combination of API server hosted on heroku along with a library hosted on NPM. It still gets 50 downloads a week and the hosted heroku API server is actually used by many people even though it offers little to no functionality. I was recently looking at wtf dashboard and even contributed a small patch to it.
Suppose you have a HTTP request to be sent but don’t care about the result or errors. This request is sent through a function which is usually called inside a goroutine and is not in any way a core aspect of your main logic. The only important part is forming the actual request and the payload. When you wrote this function, you did not write tests as it would be a pain to make the function return something and check it.