OpenPGP support in Go(imperialviolet.org)
imperialviolet.org
OpenPGP support in Go
http://www.imperialviolet.org/2011/06/12/goopenpgp.html
11 comments
Anyone else think it may be time to look seriously at learning Go?
It's a fun language with a lot of potential.
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.
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.
I've been playing with it off and on for over a year now -- it's definitely worth learning -- it'll shape your perspectives, and as a more-and-more viable substitute for other compiled languages, it's really quite nice.
No - I looked at it, but when I need such a low level language I want the added control I get from C/C++ and the ceremony needed to get Go to do something is almost as much as these languages.
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.
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.
Absolutely - if only to be able to read things like Tonika and Doozer.
I've been looking for a decent personal project for Go for a while now. It looks like a nice fusion of ideas.
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.
I am going with libtask and zmq in C for now.
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.
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.
> 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.
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.
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?"
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?"
If X is an OpenPGP implementation, I support this. We need more implementations of this standard.