Golang seemed like a pretty interesting language to try. First of all, I am interested in the context of server-side business logic. The usual frameworks in this area are Spring, RubyOnRails, Django.

First, I wrote some small utilities (for example, UDP Sniffer). Then a back-end project of medium complexity (not publicly available). To understand the size: 14 http endpoints, 1 of them graphql (there are even more than 30 queries and mutations), Postgres.

At the same time, some things in the platform are very impressive:

  1. Take the standard library seriously: it is expected that in most cases it will be used, and not something third-party.
  2. A single automatic formatting style.
  3. The generated executable file contains all the main dependencies.
  4. Efficient use of iron, especially at low loads. The same Java can even work faster, but it is very difficult to run it quickly and on small hardware (native compilation, etc.).
  5. Easy cross-compilation.
  6. An interesting approach to multithreading.
  7. Interesting syntax style.
  8. Quick assembly.

As a result, the main thing I didn’t like was error handling. In the world of business logic, we usually can’t do anything about technical errors – we usually just return an error to the query and need logs to figure out what happened. At the same time, Golang, in order to get a stacktrace, assumes explicit processing at each level of the call. It turns out that the code increases by about 3 times and it does not carry any value.

The main list of problems:

  1. Error handling. For more information, see above.
  2. There are still quite a few Golang programmers and they are harder to find or train than on the Kotlin.
  3. Slow assembly. But isn’t it fast? If we take into account code generation, it turns out to be noticeably slower than Spring… And code generation is due to the limitations of the language itself. However, in the future, I think there will be some kind of cache for code generation and it will work out instantly. But not now.
  4. The syntax is not well developed - in many cases it is too verbose.
  5. Starting with a certain project size, there is a feeling that the growth of the code base is hard, harder than Java / Kotlin.

In general, it is very suitable for console utilities and for network servers, i.e. as a replacement for C/C++/Python(cli).