We've moved from .NET and C# to Go, and I'd argue that it's very competetive with general purpose languages like C#, Java and similar for a different philosophical approach to enterprise tech. It's been a great technical fit for us in both finance and energy, but the main purpose for our adoption is because it's opnionated approachs are a much better fit for us than traditional OOP languages. There is no "magic", everything is explicit, the standard library is incredible and it's a relatively easy langauge to write and read.
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.
Go has surprisingly good "UX", which I don't hear people talk about much. It compiles very quickly and gets out of your way. I've found it useful for a few reasons:
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.
- Fast compiler with easy cross compilation (super handy e.g. for developing Linux network services on a Mac)
- 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 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.
It's like a more robust python. Compiled so you don't deal with the annoyances of using a scripting language to build, deploy and run applications. But also way simpler then something like c++ or rust. Though I do wish it had some more nice syntax and features.
When you want to have native code in clouds like Vercel and Netlify, unless you rather go via nodejs native modules.
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.
The hype has gone as it is now just another programming language in common use. The use cases are the same as they've always been. Networked and distributed systems.
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
