Comment by liampulles
9 hours ago
I love Go. One thing I haven't seen noted here is how great it is for use in monorepos. Adding a new application is just a matter of making a folder and putting a main packaged go file with a main() func. Running go install at the root ./.. takes care of compiling everything quickly and easily.
This combined with the ease of building CLI programs has been an absolute godsend in the past when I've had to quickly spin up CLI tools which use business logic code to fix things.
I don't understand how this isn't also true for practically every other language?
It just isn't. There's nothing stopping other languages from being that easy but very few even try.
Go sees itself more as a total dev environment than just a language. There's integrated build tooling, package management, toolchain management, mono repo tools, testing, fuzzing, coverage, documentation, formatting, code analysis tools, performance tools...everything integrated in a single binary and it doesn't feel bloated at all.
You see a lot of modern runtimes and languages have learned from Go. Deno, Bun and even Rust took a lot of their cues from Go. It's understood now that you need a lot more than just a compiler/runtime to be useful. In languages that don't have that kind of tooling the community is trying to make them more Go-like, for example `uv` for Python.
Getting started in a Go project is ridiculously easy because of that integrated approach.
The distinction, I believe, is between "possible" and "easy". Go makes a lot of very specific things easy via some of its design choices with language and tooling.
As a counter example, it seems like e.g. c++ is mostly concerned about making things possible and rarely about easy.
It’s not true of C/C++ which need changes to the build system. Also true for rust workspaces which is how I’d recommend structuring monorepos although it is generally easy (you just need to add a small cargo.toml file) or you can not use a workspace but you still need to declare the binary if I recall correctly.
It's true for any C/C++ project which bothers to write 10 lines of GNU `make` code.
The problem is that many projects still pander to inferior 1980s-era `make` implementations, and as such rely heavily on the abominations that are autotools and cmake.
4 replies →
With bazel/buck/pants/etc won't be problem for other major languages.
Have you worked with those before? "Quickly and easily" are not exactly what comes to mind.
Agreed. This use case is not mentioned enough.