I have been developing in Go for several years and feel like I have seen most it can offer which is quite a lot for backend/networking systems.

Besides its GC implementation that works very well most of the time, it also has simple but strong debugging tools to investigate how well you are handling memory allocation and CPU usage. Enforcing consistent coding style also makes it very easy to read other people's code and quickly contribute.

My suggestion to others is to avoid prematurely optimizing memory usage (e.g. trying to do zero-copy implementations) and always investigate performance via these profiling tools Go offers (e.g. pprof). Very often Golang's compiler or runtime will automatically optimize code that may not seem to allocate optimally.

There are still downsides but some of them are actively worked on:

1. Generics are still lack-luster (... but good enough to start replacing a lot of boilerplate code and will improve later on)

2. Error handling is still tedious (fortunately it seems to be their next big focus), it should take less code-space and have an option of stack-trace

3. Stdlib logging is too simple, lacks levels and structured-logging-style (currently actively discussed: https://github.com/golang/go/discussions/54763)

4. Low-level UDP networking is weak (soon to be fixed as they accepted this proposal: https://github.com/golang/go/issues/45886 ), this will become more important as we transition to QUIC protocol

5. CGo (C interop / C FFI) is pretty bad performance-wise compared to other languages, it's OK if it is an I/O operation but anything C interop that requires low latency won't be running great

6. Similar to other languages, nowadays there are growing external dependency trees (e.g. I always wanted to use testcontainers-go to make integration tests easier but man, have you seen the dependency tree you will pull in with that pacakge?), solution in my eyes is flattening and standardizing most commonly used packages but Go in particular is very opinionated regarding what is included in stdlib

The above downsides mostly come from the background of creating distributed data pipelines and certain data collectors/parsers. For building API servers, I keep hearing it is a godsend in its simplicity, so your mileage may vary depending on the business domain you work in.

I would be interested to hear other people's experience with Go, however!