Made a library? Written a blog post? Found a useful tutorial? Share it with the Go community here or just enjoy what everyone else has found!
In my previous blog post on using golang in production, I have mentioned that interfaces are my favorite feature in golang.
As a follow-up of this comment, I would like to share how we are using (my current project is also in golang!) the interfaces to keep our code clean and consistent through a series of three blog posts This blog post series assumes that you are familiar with the basics of interfaces in golang. If would like to know what it brings to the table, I strongly recommend to check out this well-written article by Yan Cui.
Release 0.9 has just been announced (here and here and here) and to me it already looks quite mature and really promising. One key feature is that pipelines can pass not only text but also other data types like lists, maps, or functions.
(Available on macOS and Linux via Homebrew/Linuxbrew:
brew install --HEAD elvish. Currently, without
--HEAD, brew installs v0.8.)
I'm Releasing the Golangflow source out to the wild! - Github
This site is built using the awesome web framework Buffalo created by Mark Bates. It's been amazing learning the framework coming from Rails background and having Mark help me every step of the way. Have fun and contributions are most welcome :)
What are Goroutines?
Goroutines are functions or methods that run concurrently with other functions or methods. Goroutines can be thought of as light weight threads. The cost of creating a Goroutine is tiny when compared to a thread. Hence its common for Go applications to have thousands of Goroutines running concurrently.
Since we began our transition from Scala to Go, we discovered that when there's no right tool for the job, we can make a rough one ourselves in an hour or two. If it makes sense we can iterate on it until it becomes something the whole team can use, then the whole company, and then, sometimes, the whole world.
In this blog post, I'd like to share two of these tools: sql and chart, that we've been using a lot lately. Together, they compose an interesting pattern for tinkering with multiple databases individually or concurrently within the terminal.
Most Go binaries come without any man page. On the other hand, most Go projects include a README file. So why not substituting that readme file for a man page? The tool
goman does exactly this. Starting from the binary,
goman figures out where the source code is, and renders the README file to the terminal - even with colors if the README is Markdown-formatted.
What should I test? What you need to test in Go is really not much different from any other programming language. Except maybe that you need to take extra care with pointers if you are not coming from that background. Generally I advocate testing on all levels. Which in practice only means that you need to care for testing not only on the top level layers (e.g. your HTTP endpoints), but also ensure that the underlying structures are also well covered.
The Go language is great for concurrency, but when you have to do work that is naturally serial, must you forgo those benefits? We faced this question while rewriting our database backup utility, mongodump, and utilized a “divide-and-multiplex” method to marry a high-throughput concurrent workload with a serial output.
PegoMock is a mocking framework for the Go programming language. It integrates well with Go's built-in
testing package, but can be used in other contexts too. It is based on golang/mock, but uses a DSL closely related to Mockito.
Lottip is proxy for MySQL RDBMS with web GUI. It will show you what's happening under the hood of your database layer. As it sits between your application and MySQL server there's no need to use tools like Wireshark or enable general logs to see which queries are being executed. It comes as single binary with zero dependencies and consists of 2 parts: proxy server and embedded GUI. https://github.com/orderbynull/lottip
HyperLogLog with lots of sugar (Sparse, LogLog-Beta bias correction and TailCut space reduction).
An improved version of HyperLogLog for the count-distinct problem, approximating the number of distinct elements in a multiset using 20-50% less space than other usual HyperLogLog implementations.
zerolog - The zerolog package provides a fast and simple logger dedicated to JSON output.
Zerolog's API is designed to provide both a great developer experience and stunning performance. Its unique chaining API allows zerolog to write JSON log events by avoiding allocations and reflection.