The only thing preventing me from using Go on Windows is lack of production quality cgo on Windows x86 and x64.
For example, using external linking should "just work" with recent versions of sqlite3 but it fails on Windows.
For example, using external linking should "just work" with recent versions of sqlite3 but it fails on Windows.
In my experience, certain aspects increase risks when using go:
1. go is buggier for Windows than Linux and FreeBSD, even though they are all "first class" platforms in go.
2. cgo is also buggier for Windows than Linux and FreeBSD. cgo is not go, as Rob Pike said, so this is listed separately.
3. 386 was buggier than x64, at least in go 1.2 to 1.3 on Windows. I wish I could ignore 386 and XP but I cannot.
So if a project includes all of the above aspects, well...it wasn't a good outcome for me, so I ended up sticking with C and C++ on Windows for non-hobby software.
However, I've been very happy with go 1.4.3 + cgo + x64 on FreeBSD 10 and will probably update to go 1.6 or 1.7 within a year.
Regarding go on Windows, I'm hoping to see go-sqlite3 issue #272 resolved: https://github.com/mattn/go-sqlite3/issues/272
And go issue #14397 cmd/link, runtime: panic "invalid spdelta" with -ldflags="-linkmode internal"
And go issue #10776 cmd/link: windows cgo executables missing some DWARF information
And go issue #12516 runtime: throw in linked c++ library causes app crash even if caught, on windows platform
And so on...
I really love using go (with cgo) on non-Windows platforms, but I can't see this combo being useful on Windows for mission critical projects for a while. There's so much more to go than the language itself and switching gears to use other languages that don't offer that is painful.
Maybe LXSS.sys will eventually make this irrelevant -- at least for companies that migrate from older versions to Windows 10 or to a non-Windows OS.