What are the good use cases for Go today? It looks like the hype has gone.
In a world where 4chan can serve 4 million visitors on some dated apache server version running a 10k line PHP script which hasn't been updated since 2015 it's important to remember, that for 95% of all software (if not more), any, general purpose language will be just fine technically speaking and it's in the development processes (the people) the actualy differences are found. Go is productive and maintainable (cost-efficient and rapid changes) for teams that work better without implicit magic and third party depedencies.
The hype may be gone, but the Jobs aren't. In my area of the world Go is the only noticeably growing programming language in regards to job offerings.
1. The standard library has a real HTTP/2 implementation (unlike Python).
2. The Go compiler creates statically-linked binaries and cross-compiling is painless.
3. Channels and goroutines make it relatively easy to write parallel code. There are certainly sharp edges, like every language.
- Pretty decent concurrency built in
- Small language spec that is very easy to read and learn
- A very good and well thought out toolchain and tool ecosystem. This is hard to list as a selling point or quickly summarize but it makes Go code pleasant to work on. Things that other languages have ti have complex third party tooling for are simple and boring in Go.
- If you are writing code that interfaces with Kubernetes or a popular container runtime like Docker or Podman, it is a natural choice.
- Pretty good performance as far as garbage collected runtimes go. Not the best, but really good.
Go is very much faster, you save time and money on computing resources.
Go has built in testing and type support, making it easier To write more reliable and more bug free code.
But let’s not debate it, learn go for yourself and try it on a small little project. I’m convinced you’ll pretty much not want to switch back.
I like VS Code's default code style for TypeScript, but partly because it is not too opinionated about whitespace (though it gets close).
But after 10 years, I finally went back to manual CSS formatting. I just can't write CSS without the option of single-line rulesets.
gofmt doesn't (or at least didn't) allow single-line blocks ever. This is just too opinionated, and for that reason it will one day change, even if that day is 20 years from now.
Having a standard is fine. But software is not just technical, it's an art too.
Would you be willing to make a Long Bet about it? https://longbets.org
I've been both right and wrong about long term predictions often enough that I've learned to just stop caring about it. (But I am right in this case.)
I wrote a lot of Go from like 2010 to 2013 or so.
A few days ago I read an article from someone clearly experienced in general software good practices, who masterfully laid out every complaint I had when I left Go.
I wish I could find it, but I think it was from this year or last year. The only example I can remember is repetitive explicit error handling with a comparison to more modern languages.
I have the opposite experience here, I find golangs error handling to be too abstract at times. I need to know what error and in what situation a function can return an error. An abstract error doesn’t help with that and an exception even less so. I need to dive into a functions source far too often to try to understand in what situation an error might occur and what that error would be if it is even typed.
If you fine error handling annoying and only handle it high up in the call chain your codebase is either brittle or returns generic unusable errors and you have to rely aggressively on runtime tracing which is very expensive.
https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...
I also think the ecosystem of NPM is, for some, not a positive. I can regularly write go programs with no or very minimal dependencies (and those dependencies are themselves often the same way). The go standard library is pretty well thought out and the included batteries are mostly high quality. Easy integration with pprof, opinionated testing, embed, pretty good datetime primitives, etc
2. Which is better, having 70,000 packages but only 700 good ones, or only 500 packages and every one is good? I'm on the fence.
This is sort of the worst case comparison, but a hello world program in go is 1.5 MiB and the SEA node equivalent is 109 MiB. Obviously as your program becomes more complex that fixed overhead becomes less of an issue but I think it's still a useful comparison.
For the packages, the thing I prefer even more so is writing an application with 0 dependencies at all. net/http, net/http/pprof, flag, pprof, etc are all built in and high quality and you can easily build clis/servers with them. Even a really full featured CLI builder package like cobra has just a few transitive deps and gorilla/mux has none: https://github.com/spf13/cobra/blob/main/go.sum https://github.com/gorilla/mux/blob/main/go.mod
If I compare that with express.js or commander its a very different story (though, in fairness to commander, they all seem to be dev deps).
I don't think it's bad per se to have deps, just a different culture. https://news.ycombinator.com/item?id=43935067 kinda beat that horse already though
However, I would use Go instead when deploying in cloud providers like Vercel and Netlify, as explained in a sibling comment.
It is easier to just go with the less friction option, and deploying such modules requires not only knowing how to write them, also mastering the whole deployment process, thus not something I would advise in teams with mixed skill levels.
There are some Googlers angling for this.
Not that I'm against Rust for network services, but with Rust you're accepting increased complexity for increased safety - a worthwhile tradeoff depending on the project.
Right. Go is a great language for the server side of web client/server things. It's more reliable than C++, easier than Rust, and is hard-compiled to a read-only executable, which is good for security. Goroutines, which are cheap but can block, get rid of the async/sync distinction. The important libraries are maintained by Google people and used internally, so even the unusual cases are well-exercised.
What more do you want?
They build on top of AWS Lambda, but do not expose the full capabilities, so Go it is.
Working on DevOps space, most tools related to Docker and Kubernetes are written in Go, as this is its reason to fame. Although Rust is starting to show up as well.
But in reality, TypeScript is probably its only legitimate use-case, and only because it already had very stringent requirements.
Most projects either stick to Node.js, or if they need more efficiency, they get rewritten in C++ or Rust, instead of ported to Go.
well, that's the point. it is excellent language for server programming. and not just faster, it is more stable, scales complexity better, stronger security