How Google’s Go language could be improved

Posted on 08-08-2017 , by: admin , in , 0 Comments

To improve development tools for Google’s open source Go language, Go might be getting its own language server, akin to Microsoft and Red Hat’s Language Server Protocol.

The notion came up in a Go language contributors’ discussion group, so it’s not a done deal.

The group’s consensus recommendations are:

  • Adopt a language server IDEs and other tools. It would index and display information about code and packages. “Microsoft’s Language Server Protocol was suggested as a good starting point because of its wide support in editors and IDEs,” said one participant. That protocol was designed to integrate multiple language across code editors and IDEs.
  • Establish a standard “counter” API that would report statistics.
  • Rewrite some of Go’s assembly code.
  • To bridge the gap between assembly and Go, consider rewriting the crypto code in Go. For performance purposes, crypto code in the language was mostly written in assembly. But the code is hard to debug, maintain, and read. “A rewrite in Go would make maintenance easier. Adding processor intrinsics and better support for 128-bit math would improve Go’s crypto performance,” one participant said.
  • Expand the math/bits package planned for the upcoming Go 1.9 release to accommodate the rewrite. The math/bits package offers optimized bit manipulation. (Go 1.9 is due this month.)
  • Refactor garbage collection and related tools in the compiler and runtime, to reduce overhead in core tools and IDEs.
  • Perhaps embed the compiler into the IDEs for quick syntax-checking.
  • Compile code in memory, benefiting environments that lack a filesystem. Developers also could run tests continually.

Other issues raised in the discussion group included dependency management and interface issues. Contributors noted that making critical fixes to packages in the standard library requires waiting six months for a new version of Go to ship, or for a point release for security issues. “Better dependency management may facilitate the migration of some packages out of the standard library and into their own projects with their own release schedules,” wrote one participant.