Topi Kettunen's Homepage

Another neat finding in Go’s language server. Basically, I wanted to include some sort of way to run some static analyser with my language server. I remember golanci-lint was long the “de facto” tool for this, but seems that staticcheck has grown a lot in popularity. So I wanted to integrate that with my gopls.

Naturally, the first step was installing the tool itself. Fortunately, that can be done super easily with just:

$ go install honnef.co/go/tools/cmd/staticcheck@latest

Next I needed to enable this somehow with gopls. Again fortunately, all the possible settings for gopls can be found here. Including the simple variable for staticcheck. To pass in this setting to eglot, I need to configure variable eglot-workspace-configuration, which basically allows you to configure LSP servers specifically for a given project and given LSP.

To pass in the setting to the gopls, we need to pass in a plist with the configurations we want:

(use-package eglot
  :custom
  (eglot-workspace-configuration '((:gopls . ((staticcheck . t))))))

;; OR

(setq-default eglot-workspace-configuration '((:gopls . ((staticcheck . t)))))

Naturally, you can pass any setting you desire that is available for the language server this way.

I needed to write some funky Go code using relatively new Go generics in it, just to quickly notice that my LSP client in Emacs didn’t recognise those like you would expect. Fixing gopls was relatively straight-forward, since my issue seemed to be just an old version. So I just installed gopls while having Go 1.18+ installed. In my case, I had already generics-aware Go version installed but seemed like that I had installed my gopls version before the generics update, so I had to just reinstall it with:

$ go install golang.org/x/tools/gopls@latest

After that gopls was pleased, or at least my eglot didn’t complain about syntactical errors in my code. Pretty much immediately I realised that now my goimports was broken, so it didn’t organise my imports accordingly. I knew that gopls was able to do this stuff instead of using goimports, but I just never was eager to fix something that was already working. But since now it was broken, I decided to find a way to fix it.

What I did was just uninstall goimports from my machine and started relying on gopls for organising my imports. Previously, I had set my Emacs so that when I saved my files, it always ran goimports (when working on Go files, of course). Setting my eglot to do that was relatively simple, but then I noticed that it only formats my code, it doesn’t automatically import the libraries like how goimports does.

Like I mentioned earlier, gopls should be able to work exactly like goimports in this case, so I had to start digging on how I can make my eglot to do this. Basically, how gopls does this, is it uses source.organizeImports action for it. So I needed to run that somehow on save.

Fortunately, eglot exports all these code actions that the LSP can do with a neat function called eglot-code-actions. After some tinkering, I was able to call that before the save:

(use-package go-mode
  :ensure t
  :preface
  (defun tok/gofmt-before-save ()
    (interactive)
    (gofmt-before-save)
    ;; Run `eglot-code-actions' only in buffers where `eglot' is active.
    (when (functionp 'eglot-code-actions)
      (eglot-code-actions nil nil "source.organizeImports" t))
  :hook (go-mode . (lambda ()
                     ;; Using depth -10 will put this before eglot's
                     ;; willSave notification so that the notification
                     ;; reports the actual contents that will be
                     ;; saved.
                     (add-hook 'before-save-hook 'tok/gofmt-before-save -10 t))))

I decided to use gofmt-before-save, which comes from go-mode here since I noticed that if you would just run eglot-format-buffer formatting doesn’t open a new buffer where it lists all the errors and instead prints them in the LSPs messages. You can probably dig them somehow from there and print in a new buffer, but I liked already the existing behaviour of running gofmt with go-mode so I decided to use that one.

Small fix, but a really good one. Happy generics-aware hacking.

Last week, Russ Cox from Go team started a discussion about the possibility of starting to collect telemetry from Go usage.

How do software developers understand which parts of their software are being used and whether they are performing as expected? The modern answer is telemetry, which means software sending data to answer those questions back to a collection server.

I believe that open-source software projects need to explore new telemetry designs that help developers get the information they need to work efficiently and effectively, without collecting invasive traces of detailed user activity.

I have written a short series of blog posts about one such design, which I call transparent telemetry, because it collects as little as possible (kilobytes per year from each installation) and then publishes every bit that it collects, for public inspection and analysis.

I’d like to explore using transparent telemetry, or a system like it, in the Go toolchain, which I hope will help Go project developers and users alike. To be clear, I am only suggesting that the instrumentation be added to the Go command-line tools written and distributed by the Go team, such as the go command, the Go compiler, gopls, and govulncheck. I am not suggesting that instrumentation be added by the Go compiler to all Go programs in the world: that’s clearly inappropriate.

Cox also published three part introductory blog post about “transparent telemetry” that is worth a read:

• Transparent Telemetry for Open-Source Projects

• The Design of Transparent Telemetry

• Use Cases for Transparent Telemetry

So this whole discussion got me thinking about my feelings towards Go and, possibly, its future. First, I enjoy working with Go. As a language, it’s delightful to work with. It’s safe and fast, and I feel productive in it. But if the Go developers would introduce something like telemetry collecting your Go usage, I would have to re-evaluate the need/desire to use Go in current/new projects. There aren’t many developers that enjoy something like this in their toolchains. Or that would willingly allow something like that.

Sure, collecting telemetry in Visual Studio Code hasn’t affected too much in its popularity. But then again VSCodium is also quite popular, so clearly, some people hate this kind of telemetry, even in their favourite tool. Of course, I’m not yet even talking about the legality of collecting something like that. Because if something like this would be on by default, even if opt-out is offered, looking at GDPR, this can be considered illegal.

Of course, Go has had some “trust issues” for many due to it being language primarily developed, or at least funded, by Google. So naturally, people tend to have certain ideas and feelings about it even without touching it. Understandably so. Many people have already raised criticism in Go, for example, in their usage of Google run closed source Go module proxy mirror (proxy.golang.org), which is set on by default. This is also odd since Go’s import system was made to be decentralized from the get-go. Still, they decided to introduce something like this to increase reliability when importing libraries.

Considering all this, personally, I feel that if they were to introduce something like this to the Go toolchain, especially if it’s set on by default, it’d be a horrible thing for Go making the language to start fighting a big uphill battle, which may never end. I would still like to continue working in it, but if something like this were to happen, I feel that I couldn’t continue working in it if I had a choice.