[aaronblohowiak]

I looked into it. Go neither provides you the safety of immutable data structures nor the freedom of direct memory manipulation. You're still expected to track who "owns" what struct so you can avoid concurrency conflicts, though it does provide nice mechanisms to pass that ownership along (in the form of thread-safe buffered queues.)

I am going with libtask and zmq in C for now.

[kjksf]

How come you're not bothered by C's numerous deficiencies, like being the one language responsible for majority of security issues, ease of corrupting memory, tediousness of manually managing memory and the fact that half of professional programmers can't decipher C type declarations of medium complexity (http://www.infoq.com/presentations/ECC-Fun-Writing-Compilers).

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.

[aaronblohowiak]

> How come you're not bothered by C's numerous deficiencies, like being the one language responsible for majority of security issues, ease of corrupting memory, tediousness of manually managing memory and the fact that half of professional programmers can't decipher C type declarations of medium complexity (http://www.infoq.com/presentations/ECC-Fun-Writing-Compilers).

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.