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.
Another area of discussion was the difficulty of using the standard library interfaces. “It would be nice if io.Reader accepted a context so that blocking read operations could be canceled,” said one participant.
Errors in Go also led to discussions. “Many Go users are initially confused by, or don’t understand, the fact that ‘error’ is an interface, and it can be difficult to attach more information to errors without masking sentinel errors such as io.EOF,” wrote one participant.
Source : www.infoworld.com
