Ask HN: What type of applications is Golang best suited for?
I'm diving into Golang and I'm curious about its strengths, cons, and best use cases. While I know it's praised for its performance and simplicity, I'm looking for real-world examples and experiences.
11 comments
[ 3.4 ms ] story [ 38.2 ms ] threadEDIT: In terms of strengths it's a relatively small/simple language. Good out of the box tooling, e.g. profiling, linting, doc generation, package management, code formatting. Fast compile times. Garbage collected so not a lot of memory management headaches. Strongly types. Performant. (maybe not as easy to squeeze the last cycle out of things as you can with C or C++ but not an unreasonable tradeoff between performance and language runtime/abstractions).
Some people move to Go from Python for performance reasons (and other reasons).
I'd think twice about using it for web front end or complicated GUI although both are of course possible
What libraries did you use? Were you using tinygo?
Any kind of systems programming or DevOps CLI that's getting a bit too heavy for Bash. (The fact you can `scp` the statically-linked binary it creates into another machine and have it just work is a huge plus.)
- Web servers/backend and API
- Cloud and network services
- CLI tools
- Distributed systems & concurrency
- Being a productive programmer
- Easy to learn
Go is not best for:
- GUI apps
- stuff where metaprogramming is important
- Stuff where verbose error handling is important
- Hooking to C libs has been very problematic and error-prone for me at times. It can be done, but...
Real-world examples:
- SyncThing
- Caddy
- Large parts of Bit.ly
- Mattermost
- Kubernetes
- Docker
- Terraform
- InfluxDB
- Grafana
- Traefik
- Etcd
Do not use it for FFI or systems programming as it has godawful FFI overhead. Do not use it for high-performance data processing either - if you need high level language for that, use C# instead which offers rich SIMD capabilities.
Generally speaking, Go has pretty bad relationship with performance ceiling due to weak compiler and lack of true zero-cost abstractions.
It's on the other side of spectrum of compiler capability when compared to GCC, LLVM, .NET and OpenJDK.