But you also get a stack trace without needing an IDE and debugger.

I've been working with Go daily for a few months now at my job and I'd like to point out that Go stack traces have a really big signal to noise ratio. There is a lot of cruft that mostly nobody cares about and sometimes it can be hard to pinpoint exactly where something crashed (at which line) with a panic.

Just saying, they should probably improve it to be less verbose and more concise.

In that case you would say it has a really low signal-to-noise ratio.

Yes, you are 100% correct, I dun goof'd. I would edit the post but apparently I can't, so I'm sorry for that. Same for the other person commenting on it.

I realize I'm perhaps somewhat annoying, apologies, but that would make the signal to noise ratio _small_, not big.

It's literally (SIGNAL) / (NOISE), so if the noise is larger than the signal, the ratio goes down.

The stack trace contains the stacks of all the goroutines. The running goroutine which caused the panic is printed first, so it should be pretty easy to find the source of the problem. At least I haven't had any issues in debugging complicated apps with thousands of goroutines...

But you can get that in C++ if you really wanted to as well.

I just wanted to point out that not having to worry about segfaults is clearly wrong.

Go doesn't really take any steps from preventing pointers from being null or forcing you to deal with possibly null pointers, or accessing uninitialized maps or slices.

I'm wondering why I'm being downvoted for a factual statement.

The parent of this comment said "without worrying about dependencies, dynamic linking, or segfaults".

This is blatantly wrong. Pretty sad what HN has become.