Go shines for network services. The standard library has everything you need for networking and the web with very accessible concurrency primitives. It's also a pretty lightweight language that's easy for people to pick up.
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.
I've used Go and Rust for network services, and they honestly feel completely on par with one another from a DX and ergonomics perspective. I wouldn't be surprised if Rust starts eating into Go marketshare for microservices.
I love Rust, but Go is a much much simpler language, especially for network services. For example, the experience of goroutines vs rust async is night and day in terms of complexity. Also, the borrow-checker introduces a lot more ceremony when managing network peer entities, particularly structuring relationships between entities - a very common requirement in network applications.
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.
Are these not also true for Node.js? Add the familiarity of JavaScript, the ecosystem of NPM, and the good-enough speed of V8, and I'm not sure why choose Go.
The convenience of shipping a single compiled binary is one.
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
Very cool about the SEA feature, I haven't seen that before. Thanks for sharing that
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.sumhttps://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 actually agree, and my own Node.js web server doesn't use express.js or anything except for 'mime-types', and only because it's not built in even though it really should be. I never liked express.js's design, and pretty much every useful feature of it is now either built-in or 5 lines of code. Plus, when I dug into its source code and dependencies, I found so much outdated and unnecessary cruft. So yeah I don't disagree. But it still doesn't really push me towards Go. Plus, Go's own http route mounting concept also seems kind of overdone. So even though I can just avoid using it, it still becomes part of that 1.5 MiB that I didn't really need but am forced to bundle, even if it is smaller than the 109 MiB. So in principle it doesn't seem a huge win, just a small one. Compare that to the many TypeScript features and JavaScript features I'd have to give up, and it just doesn't seem worth it.
> But let’s not debate it, learn go for yourself and try it on a small little project
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.
When typescript-go was announced, I almost wanted to give it a serious try. But that article I referred to convinced me that it still has serious QOL issues.
> 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.
> Go has a standard code style, everyone agrees to use the same format and all our code becomes easier to read and standardized.
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.
Additionally, if more performance is needed we can always write a native module.
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.
minimalism in dependencies, security, type system and static analysis. tooling (fuzz tests, benchmarks, etc.). uniform syntax (thanks go fmt) in entire ecosystem.
