[mo1ok]

Yep, this is a huge problem in the ecosystem right now. The irony is that JS, an interpreted language, is becoming slower to compile than some of the newer compiled language (i.e. golang, which compiles to machine code and therefore avoids all compatibility issues).

[klodolph]

Golang doesn't avoid all the compatibility issues. On the contrary, there's a ton of Golang that won't run on anything but Linux.

[guessmyname]

> […] there's a ton of Golang that won't run on anything but Linux.

Please give examples so I can fix them.

Go code is highly portable to the supported platforms. In all my 5+ years developing code on Mac and cross-compiling for Linux servers, I can count with one hand the number of broken packages due to compatibility issues with the target operating system.

With my experience I am sure that I can fix the cross-compatibility issues in the code that you have had problems with, but I need names and/or links, please point me to them.

[klodolph]

I don't have examples off the top of my head, but I'll tell you how it happens.

* Use of cgo and platform-specific headers / libraries

* Use of golang.org/x/sys/unix, especially ioctl

* References to external utilities and files only typically installed on Linux, especially with os/exec, or use of GNU extensions in system utilities

* Inability to correctly handle paths on Windows (use of "path" instead of "path/filepath")

* Inability to correctly handle case-insensitive file systems

* Creation of paths containing characters illegal on NTFS, or with names that are otherwise illegal on NTFS (through the normal APIs)

* Deleting files or using deleted files in a way that works on POSIX but not Windows, this particular one is especially common because the mandatory file locks on Windows will bite you hard if you are used to the POSIX way of doing things

* Difference in semantics for filesystem change notifications. In JavaScript I can use chokidar and in Golang I can use github.com/fsnotify/fsnotify, but that doesn't change the fact that the underlying notification systems have radically different semantics. You can't really paper over these differences, you have to actually test your code on different platforms and make sure they work correctly on those platforms

Go code doesn't strike me as radically more portable than, say, Java, C#, or JavaScript. The fact that you haven't personally encountered problems often is good, but this isn't an indication that Go "avoids" portability problems. And compiling to machine code is not really a piece of the platform portability puzzle... it just means that you don't have to worry about having a different runtime version on your target.

The bottom line is that while Golang makes portability easier, for anything but relatively trivial programs (and "trivial" is getting larger and larger every day), your program is only portable as far as you have actually tested it on other systems. This is less work in Golang than it is with C++, and I'm really thankful for it, but it's not a radical change and it's not substantially different from the portability story that Node.js has.

[marcus_holmes]

I cross-compiled to Windows the other day for the first time (from Linux). It gave me a perfectly-working .exe in less than a second on my first try.

I love JS too, but I have yet to get Webpack or Babel working in less than a couple of hours.

[aczerepinski]

Can you expand on this? I’ve used a decent amount of Go packages and they all run as expected on my Mac.

[klodolph]

I expanded on this here: https://news.ycombinator.com/item?id=18116730

[ndnxhs]

Probably stuff that hardcodes paths like /tmp