>With Go, you never, ever have to write any OS-specific code.
Okay. The article claimed otherwise: "In Go, you can define different files for different operating systems that implement functionality depending on the operating system."
>Yes, you may generate a few versions (Windows, OS X, etc.) depending on the needs of your clients, but the cost is a few seconds of compile time, and a few seconds posting links to the Windows, OS X, etc. executables.
Except when the developer only compiles for Windows and Linux, but someone wants to run the code on Mac os X.
>Will they be able to figure out NPM? Yes, it's easy, but they'll mess it up anyway.
You don't need NPM. You can fetch the dependencies and include that with the installer. There's a downside to that, though, which is binary-packages with npm.
> > With Go, you never, ever have to write any OS-specific code.
> Okay. The article claimed otherwise: "In Go, you can define different files for different operating systems that implement functionality depending on the operating system."
Both the article and the poster you're replying to are correct. You almost never have to write OS-specific code, but you can write it if you feel there's a benefit to it. Much like Node doesn't make you write C++ code but allows you to do it when you feel it's necessary. The article's main point was, I'm assuming, alluding to Go's build tags which are much more elegant than the traditional pre-processor directives used in the C/++ world. They give you a powerful expression language for targeting specific runtime environments that lets you separate out your OS-specific code in a very clean way.
When it comes to distributing an application, there's another advantage that Go has over Node. One of the common ways that people are distributing server applications these days is as Docker images. It solves the problem of users needing to understand npm quite nicely for a Node application, but makes the distributable artifact significantly larger since it includes the bulk of an OS alongside the application code. With Go's ability to create a statically-linked binaries, you can build your Docker images "FROM scratch" and images can be as small as 2.5m.
Further to what curun1r said, most(all?) of the Go stdlib is written in Go and that has much platform specific code. Hence, it supports it. However, unless you're writing system code you will most likely never need to touch this.
Okay. The article claimed otherwise: "In Go, you can define different files for different operating systems that implement functionality depending on the operating system."
>Yes, you may generate a few versions (Windows, OS X, etc.) depending on the needs of your clients, but the cost is a few seconds of compile time, and a few seconds posting links to the Windows, OS X, etc. executables.
Except when the developer only compiles for Windows and Linux, but someone wants to run the code on Mac os X.
>Will they be able to figure out NPM? Yes, it's easy, but they'll mess it up anyway.
You don't need NPM. You can fetch the dependencies and include that with the installer. There's a downside to that, though, which is binary-packages with npm.