Have you ever needed to pick a log package for a Go project? Should you use logrus, glog/klog, the package in the standard library, or something else? The packages have different APIs making changes later a fair amount of work.

This is all made more complex when packages that aren’t applications could or should leverage logging. These packages are essentially libraries. Sometimes they do a lot. I find need to be especially true when packages could benefit from debug level logging. As someone pulling packages in that depend on different logging packages it can be a bit of an inelegant mess. Next thing you know, applications have multiple dependencies on packages that do the same thing. Like Kubernetes which depends on 5 logging packages.

Logging is just one example of this problem. There are many others. Most recently I was looking at metrics.

We can do better.

Going Where Others Have Gone Before

PHP, the extremely popular and often decried language, used to have a similar problem. There were frameworks and “platforms” that were mostly separate from each other. Zend, Symphony, and Drupal are just a few examples. If you wanted a package that did something you needed to look for a package in that ecosystem to make sure there was API compatibility. Functionality wasn’t portable due to API differences.

To try and solve this problem the PHP Framework Interoperability Group (FIG) was created. People with a vested interest from different projects came together and created a set of PHP Standards Recommendations (PSR).

Often the PSRs are interfaces, like the Logging Interface. When this happens there is a package that can be imported with the interface (like the log one).

Their message is pretty clear:

Welcome to the PHP Framework Interop Group! We’re a group of established PHP projects whose goal is to talk about commonalities between our projects and find ways we can work better together.

Go Could Use The Same Thing

Go could use something similar. What would working in Go look like if there was a set of Go Standards Recommendations (GSR) for Go APIs to functionality like logging, metrics, tracing, and other things? There are some obvious benefits:

• You could have one package implementing a piece of functionality and inject to other packages that need it
• If a package is no longer maintained it’s straight forward to swap it out for another package
• When someone wants to start a new project in a common area it can be easily used
• Smaller dependency trees in applications and less repeating
• Testing and mocking becomes less work and easier

Is it time for a Go Package Interoperability Group? I believe it would be a benefit to those building packages and applications in Go.