OpenPGP support in Go
imperialviolet.org
imperialviolet.org
Even after playing with it and reading a lot about it, I still picked up a few additional things from this article: http://news.ycombinator.com/item?id=2631964
I'd say that's a good place to start if you're still not quite convinced it's worth it.
Personally I will stick with Scala, Java (for Android) and C++ (for when performance actually matter).
I guess it would have been different if Go had been available ten years ago. Now it feels like D, a good idea with a good implementation, whose time has come and gone.
I am going with libtask and zmq in C for now.
If safety is your goal, Go certainly gives you more of it than C.
If "freedom to directly manipulate" things is your goal, Go gives you more of it than all other languages. Go has unsafe package which gives you exactly the same freedom to manipulate random bits in memory as C. And if that's not enough, Go natively supports assembly.
Go is interesting because on a spectrum of efficiency and easy of programming, it gives you both very good ease of programming and a good efficiency. C gives you efficiency but no ease of programming. Python and Ruby give ease of programming but no efficiency.
If you looked at Go, it must have been from a very, very far away.
Every language choice has trade-offs. To address your specific request, I am not bothered by the issues you raise because there are strategies to ameliorate them. Security issues and corrupting memory largely come from unbounded data. C has fantastic tooling to profile and analyze applications. Unlike Go, there is always something you can do to achieve your desired behavior. YES there are warts and problems a-plenty, but they are well-known and there is a vast collection of people and articles about dealing with them.
I never meant to imply that C was more safe than Go. Erlang is, which I meant to imply with the comment about immutable message passing concurrency. Immutable message passing concurrency is amazingly safe and free from classes of errors that Go programmers still have to deal with (race conditions!) In Go, the canonical style is to pass pointers through channels (and pass ownership along with it.) Two goroutines can still mutate the same object out from under each other, leading to all of the potential issues you run into with multithreading in C.
The Go garbage collector sucks, currently (check out the recent mailing list threads with trivial applications that trip it up.) They know this and it is on the roadmap for development, but it isn't there yet; stopping the world to do your work (and taking a LONG time to do so in perverse cases) is not something I want to deal with. When using a "systems" language, I want to have repeatable and knowable performance.
Using the unsafe package defeats all of the benefits of using Go while maintaining all of its shortcomings. Additionally, there is great difficulty with incorporating existing C libraries (yes, cgo is an option but it does not work with gccgo and it is poorly documented -- for instance, how do you make the Go garbage collector aware of C struct lifetimes?) Even if you stay within the language, you have to choose lightweight go-routines or optimized code generation (gc vs gccgo.)
Another irritating thing is that Go maps cannot have binary data as keys, only certain types (numbers and strings, basically.) Discovering this was not easy, and the suggested answer is to coerce an array of bytes to a string (making a copy) for storage and every time the key should be accessed.
> If you looked at Go, it must have been from a very, very far away.
Just because I have come to different conclusions than you have, please do not assume my view lacks research or analysis.
And judging from the last 20 years of programming language evangelism/flame wars, I completely expect to see "X support in AnotherLanguage" and "Y reimplemented in AnotherLanguage" posts followed up by "How AnotherLanguage is so much better than Go" and "AnotherLanguage vs. Go."
Sadly, what we'll never see is a retrospective along the lines of, "Did we waste all our time reinventing the wheel in AnotherLanguage?"