

OpenPGP support in Go - cannedprimates
http://www.imperialviolet.org/2011/06/12/goopenpgp.html

======
quinndupont
Anyone else think it may be time to look seriously at learning Go?

~~~
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.

------
Aloisius
I for one look forward to an endless stream of "X support in Go" and "Y
reimplemented in Go" posts over the next few years.

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?"

~~~
dchest
If X is an OpenPGP implementation, I support this. We need more
implementations of this standard.

