Hacker News Reader

Comment by kyrra | Hacker News Reader

Some of the pain points I've seen:

* while "go get" is nice, it doesn't handle version pinning at all. So for a large team working on a go program, you need another solution. Luckily there are tools like godep[0] that will allow version pinning and putting it's source code into your projects root.

* debuggers (gdb) are only partially supported. Most people don't have problems with this, but occasionally it's an issue.

* Windows support is not as strong as Linux and OSX. But it still works surprisingly well.

[0] https://github.com/tools/godep

View on HN

A serious question (not saying you're wrong, I'm just genuinely curious): What issues have you run into with Go and Windows? I've been shipping libs and programs written in Go for Windows without issue.

As for debugging, there were some comments about this recently on golang-nuts. A discussion about debugging[0]. Also Rob Pike saying GDB support is 'poor'[1] and there are bugs[2] that aren't a high priority to fix. Though, as many people pointed out on the mailing list, print statements and unit tests will cover 95% of your issues.

As for windows support, I should say that it's really just as good as the gnu toolchain support is on windows. There is no support for using Microsoft's toolchain on Windows. It can also take some work to make go apps not run within cmd terminal. I saw a blog post about it recently but I can't find it right now. But it also mentions things like the syscall[3] library docs on golang.org are actually for Linux, and it takes some steps to get them for other platforms, see the header comment here[4].

So Windows support is pretty good, but it is definitely not Google's focus. But if you've ever heard about what Windows is like within Google, there is a good reason for that.

[0] https://groups.google.com/forum/#!topic/golang-nuts/YG-APRPw...

[1] https://groups.google.com/forum/#!msg/golang-nuts/DS5ZGswXC6...

[2]https://code.google.com/p/go/issues/list?can=2&q=label%3AGDB

[3] http://golang.org/pkg/syscall/

[4] http://golang.org/src/pkg/syscall/syscall.go

I still don't see any problems with Windows support here. Debugging is a problem, actually, but other than that everything seems fine. The syscall interface gives you access to call any Windows API you want.

I wouldn't imagine writing a GUI app in Go, Go just isn't made for that and it would be silly since Microsoft's .NET tooling is so darn good. But Go for services and command line apps for Windows it has been fantastic.

Go on 32 bit Windows is a unreliable. I wrote about it some time ago[0]. I don't think it will ever be fixed.

That said, I still use Go all the time.

[0] http://www.abtinforouzandeh.com/2012/04/08/Do-Not-Use-Go-For...

Sometimes I wish debugging worked on Windows, but generally speaking I've found Go makes unit testing natural enough that it's not a big deal.

Same here. Good support in LiteIDE. Debugger works from LiteIDE. Been meaning to try this LightTable plugin (https://github.com/toqueteos/LightTable-Go) but haven't gotten around to it yet.

Hey, I'm one of the contributors for that plugin. There's still a lot of work to be done, but I'm finding it fairly usable right now. If you get around to it soon, make sure to grab the plugin from Github and not the plugin manager. The version in the manager is very out of date. And pull requests are very welcome.

EDIT: For the record, I'm using it on Windows

Reply on news.ycombinator.com