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++.
Maybe a better comparison is to more systems-level applications like you might code up in C. The same benefits carry over to those, without a significant performance hit (usually).
(And to be fair, sometimes C/C++ is the better tool for the job. But give it a shot; Go is pretty handy when you don't need to drop down to lots of unsafe memory and CPU operations.)
By the way, your existing C skills will be very useful in Go. For example, struct fields will still be padded unless you pack them carefully. Your experience with buffers, streams, memory allocation, and data structures will definitely not be wasted in Go.
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.
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.
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.
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.
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.
> 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++.
Try doing that in C/C++.
Maybe a better comparison is to more systems-level applications like you might code up in C. The same benefits carry over to those, without a significant performance hit (usually).
(And to be fair, sometimes C/C++ is the better tool for the job. But give it a shot; Go is pretty handy when you don't need to drop down to lots of unsafe memory and CPU operations.)
By the way, your existing C skills will be very useful in Go. For example, struct fields will still be padded unless you pack them carefully. Your experience with buffers, streams, memory allocation, and data structures will definitely not be wasted in Go.