|
|
|
|
|
by royletron
1280 days ago
|
|
Meh, I feel a little like this is dunking on Javascript for the sake of dunking on Javascript. Ever done the same with a PHP app? Go? Python?! They all have issues with versioning and this is why there are a good set of tools to deal with it - pyenv/nvm etc. It's like they've listed all the good reasons to use JS and then kicked it because it's cool to hate on JS. Hi, I am Darren, and I love JS - I will no longer be ashamed by it. |
|
Heck, I think half a year ago, I unearthed a project I wrote in Go1. ... I think 6? 8?, Anywho, way before modules were introduced. All I had to do to get it to build was a `go mod init app && go mod tidy`.
And all of this is baked into the official toolchain that comes with the language. So is testing, benchmarking, documentation-generation. As a bonus, the official proxy provides a handy way for package discovery, but without relying on any one centralized repository to fetch said packages.
The language itself doesn't change a whole lot, and by design encourages a straightforward and to-the-point style of doing things, (at the cost of being somewhat verbose sometimes, but I think that's an acceptable tradeoff). The result (and also a big thanks to `gofmt` at this point) is a coding style that is pretty consistent between many modules written 5 years ago and projects started yesterday. The designers make sure that newer versions of Go itself don't break things, with even generics not breaking any backwards compatibility.
And if I want to upgrade a dependency, there are only 2 possible outcomes: Either the go-tool can resolve the dependency graph to something that works for everything in the project, or it cannot. Either way, provided I `go mod vendor`ed, I won't end up in a situation where I just cannot build any more.