Go 1.11 is released - WebAssembly and Native modules

This Friday was the release of Go 1.11. The key things of the release are experimental support for WebAssembly, as well as a new concept for Modules that are intended to become the standard for code distribution.

Before moving on to the main things of the release, it is worth saying a few words about changes that are not so noticeable to the user. As in previous releases, in Go 1.11, work was done to improve the libraries of the language, toolchain and runtime (for example, there are no limits on the maximum Heap size now). Of course, work was done to improve the performance of the language (most of all - in math / big - long arithmetic).

Now about WebAssembly. Actually, on Habré there are already several articles on how to write code for Wasm on Go. So, this experimental feature in the release is not news at all. However, I think everyone understands that this is very important. After all, if the computer turns out to work out the toolchain, as well as the Wasm to a production-ready state, then we can write the front-end code in a pleasant language with static strong typing (hello, javascript!). Here is a small example of the use of technology -


By the way, different solutions have already begun to appear to improve the lives of programmers for developing under the frontend. For example, https://github.com/dave/wasmgo - compiling Go to WASM, and deploy to CDN into one command.
')
We now turn to the most important thing, in my opinion, in this release - the System of Modules. About these modules, conversations have already begun for quite some time. They were known to the world as Vgo . The modules have even been discussed in the runet - https://habr.com/sandbox/115542/ , as well as within the Devzen podcast by the famous Gopher - Alexey - https://devzen.ru/episode-0180/ . A good introduction to the modules is https://roberto.selbach.ca/intro-to-go-modules/ .

The most important thing in these modules:

• Work on Semver . Moreover, the go mod command allows you to update only on the maximum Patch version (the third version number), and on any maximum Minor version (the second or third version number). You will not automatically upgrade to the major version that breaks compatibility - and this is very wonderful.
• The process of abandoning the GOPATH concept has begun . Go developers want to get away from this abstraction in 2019, so now new modules work only outside GOPATH. However, you can set the environment variable GO111MODULE = on to remove this restriction.
• Started the process of avoiding Vendoring. So far, there is an opportunity to put dependencies in a separate folder in new modules, and use them from there. However, in the future, Go developers want to get away from this. In their opinion, dependencies should always be retrieved from the repository (for example, GitHab), or the company should proxy the repository by caching the sources on its side (for example, using Artifactory).

It is important to understand that the new modules are also still an experiment. Modern development tools are not quite ready for this yet. Therefore, you may have to continue to live with Dep . However, there are already attempts to launch Vgo on public CI - https://arslan.io/2018/08/26/using-go-modules-with-vendor-support-on-travis-ci/ .

In GoLand, new modules already exist as an abstraction. However, everything works relatively wet (for example, if you download a module using Vgo, but not doing go get , then the code will not begin to be analyzed):



Let's sum up. Go 1.11 is a great release. Nothing broke here (as usual) - and this is very cool. There were interesting features. We automatically got some performance boost. In general, everything is as it should be in a modern language for industrial development. And the changes will be in the future Go 2, which is now being actively discussed.