[billsimpson]

> I never, ever want to write any OS-specific code

With Go, you never, ever have to write any OS-specific code. From a single source, you can build executables compiled for different operating systems.

In any case, you're right that it can be nice to simply "run" a JavaScript application directly from its source code without worrying about compilation.

> You need to compile to code for every single platform, making code distribution costly. With Node.js you can simply distribute the code as it is and it probably works in any platform.

You're missing the point about distribution. Let's say you write a non-trivial command line application, and want to distribute it to your clients. With Go, you can distribute your program as a self-contained executable file. 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. The cost is negligible.

Compare that to Node. How are you going to distribute your Node app to clients? Is every client going to install Node on their personal computer? Will they be able to figure out NPM? Yes, it's easy, but they'll mess it up anyway. What happens when the network has a hiccup and npm doesn't download your dependencies correctly, or they try to upgrade your dependencies and everything breaks?

If you plan on distributing your Node code, you're pretty much limited to distributing it to other Node developers. That's not going to work for everybody.

[rakoo]

> With Go, you never, ever have to write any OS-specific code

It actually depends what you want to do. Since Go tends to be low-level, there may be a moment where your code goes into syscall land, in which case you're going to be OS-specific.

The most recent example I have in mind is mmaping a file: see https://github.com/edsrzf/mmap-go: there is a windows- and a unix- specific version. If you're using something else, you're out of luck (with this package at least)

There is a syscall package, but it's just piling up a lot of syscalls with already some OS-specific stuff. It is going to be so much of a burden to manage that the Go team plans to abstract this in a new package (https://golang.org/s/go1.4-syscall)

[nawitus]

>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.

[curun1r]

> > 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.

[Rapzid]

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.

http://golang.org/src/net/

[andrewchambers]

Obviously you need to write OS specific code, even with node, if you are doing platform specific tasks. Normally you don't need to care.

[filipedeschamps]

You don't need to include the binaries, once you can run "npm rebuild" in the installation process.