3 ms·
We do have to acknowledge Go's significant influence on language tooling. I'm not sure my own joy in Rust's tooling would be in the same place at all if we didn
by mathw 2y ago
We do have to acknowledge Go's significant influence on language tooling. I'm not sure my own joy in Rust's tooling would be in the same place at all if we didn't have Go there shipping package management and autoformatting out of the box. Autoformatting - what a revolution in creating a language community where that's a standard, required part of the workflow! What an entire class of pointless arguments that's helped to eliminate. Marvellous.
I'm glad I turned down a job working in Go though. Whenever I read some open source tool's code to find out what it does, anything in Go seems unnecessarily verbose and extremely simplistic. It's all the design principles of Java that I don't like, but more of it. Not my style, but an undeniable positive impact elsewhere also.
And to some extent the idea that we can have modern languages with modern tooling which compile to native code and run really fast is much perpetuated by Go, and this is highly valuable in a world where far too many things are written in JavaScript and bundled with a web browser to render them because that's "easier".
- benhoyt 2y ago> It's all the design principles of Java that I don't like, but more of it. I'm curious what you're referring to there. I think of Go as the "anti-Java". Where Java has "org.apache.commons.httpclient", Go has "net/http". Where Java has stuttering like "final Logger logger = LogManager.getLogger();", Go has "logger := log.New()" (and no log4j vulnerablity). A typical "simple" app in Java puts files in "src/com/username/simplewebapp/subdir", typical Go project structure is to put files in just "subdir", or even just in the root dir. And so on.