Concurrency with goroutines and channels in Go is pretty awesome, as is the tooling: race detection, code formatting, PPROF performance monitoring, vetting (finding incorrect printf strings), and a great test framework with parallel execution support. The standard library is enough for most of what you'll need, and it's all open source, so you can learn to write idiomatic Go from it.

And if you want to use external code, you can download it with and integrate it into your main package in about 90 seconds (go get + go install). In order to learn to use it, godoc is there.

You can get static linking in C/C++ with `gcc -static`.

Sort of. On Linux, libstdc++ depends on the NSS system which dynamically loads libraries to implement things like getpwent(). Last time I had to actually make a portable static executable (admittedly some years ago) this was a real problem, and it was easier to statically link everything except libstdc++, then ship a copy which was loaded using RPATH in the linker settings.

This is however a tooling issue, not a programming language one.

And Go's tools have a great reputation.

(Disclaimer: Not a Go programmer, just read articles about it.)

>>>>Try doing that in C/C++.

Lua.

You can still get segfaults in Go.

"panic: runtime error: invalid memory address or nil pointer dereference"

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.

> Once Go is installed, I can make a simple web app from scratch that displays parameters from the URL or request body in just over 95 seconds with Go, using only the standard library. I can cross-compile it for another OS and architecture, then deploy a single binary file without worrying about dependencies, dynamic linking, or segfaults. Try doing that in C/C++.

NodeJS runs on top of C++ :P

"then deploy a single binary file without worrying about dependencies, dynamic linking, or segfaults"

Yeah, he meant do it WITHOUT implementing an app server and a JIT for another language first.

With std.

It will be possible in C++17.

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n424...