[supersillyus]

You can leak memory by leaking goroutines. If a goroutine is waiting on a channel that nobody else has access to, it lives forever, as does the memory it references.

So, you can pretty easily leak memory without messing with unsafe things.

[voidlogic]

That is a pretty serious bug, that is not at all as easy to miss as something like a memory leak is in C/C++.

It is also pretty easy to detect by this (or something better), which might be handy in a big program: http://play.golang.org/p/XmKfgQ4TmS

[supersillyus]

I somewhat disagree. Even if you don't use channels as iterators/generators (which many folks do), it's not hard to end up with a goroutine blocked on a channel that'll never be closed/written to, and this situation (like memory leaks) can result from changes elsewhere in the program or branches not normally taken. A goroutine count doesn't seem like it'd be useful for diagnosing this in a non-trivial program. The runtime could probably detect if there are goroutines blocked on channels that no other goroutine has access to, and that'd be quite helpful for debugging, but as of now it doesn't. Even if it did, it couldn't catch all goroutine leaks.