Ask HN: What type of applications is Golang best suited for?

15 points by Gooblebrai ↗ HN
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 ] thread
I would say "web application backend". It's easy to instantiate a web server with a few lines of code. There is good library and open source support for things like database drivers, JSON, YAML, cache management, HTTP, gRPC. Goroutines allow for concurrency (e.g. processing many concurrent HTTP requests) with relatively low overhead.

EDIT: 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).

Can't we do the same thing with python, flask? Yes, not compiled and strongly typed but it's still easy to instantiate a web server with a few lines of code, no?
It's going to be a lot less performant, but yes Python has a lot of library support as well and you can create a web basic web server with relatively little code. Go's HTTP stack though is part of the standard library while flask is not (there might be some standard library equivalent though).

Some people move to Go from Python for performance reasons (and other reasons).

(comment deleted)
we needed a command line network debugging tool/app for some customers to run. turned out that Go's ability to cross-compile and build single-binary apps on mac/windows/linux/android/freebsd was just perfect for that use case. single code base, easy build management, single-file .exe distribution per platform, same app experience on all platforms for customers. A+.
Golang, in my experience is good for developing: - CLIs - Backend services exposing REST, gRPC APIs which are fast, and performance - pretty decent for scripting too - event based services which need to scale using concurrency

I'd think twice about using it for web front end or complicated GUI although both are of course possible

So does this mean that you have been using golang in the frontend via web assembly already?

What libraries did you use? Were you using tinygo?

No, sorry could have phrased that better. I've not used Golang for front-end development, and would think twice about doing so.
Backend web stuff. Think endpoints.

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.)

Go is particularly good for:

- 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

Networked microservices and console utilities (though one could argue C# is the better option for this now thanks to ASP.NET Core, Spectre.Console and ConsoleAppFramework).

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.