It seems kinda strange to me, honestly. All the big SSL libraries have had (and fixed) very subtle side-channel, timing, etc attacks... so why open ourselves to known exploits, if the fixes weren't re-implemented in Go?
That is a big potential issue, but really, you can deploy a standalone binary written in go within 2 minutes that supports the state of the art(minus perhaps some subtle but important fixes) in TLS.
If not anything else, that is pretty damn cool.
Like the other fellow said, it's not as though fixes to attacks will not be accepted into the language.
I don't like Go's large number of inconsistencies.
This includes the builtin function/keywords: len,cap,new,make,range and the built-in types: map,lists,arrays.
For example, as long as you were going to have built-in functions and keywords like len and cap, why not make them pretend to implement an interface so that user types could implement them?
Why can functions return multiple values but not channels?
Why vary range semantics between the different collection types? Seriously the first value over lists should be the index? Most everything else returns an error, but channels return ok for a second value?
They don't allow generic user types, but didn't even bother to adhere to some standard syntax for specifying the types in the built-in collections. I.E.: chan type, map[type]type, []type Sticking to some kind of system would at least give a preview of what user generics might have looked like. Now if they ever do implement generics they'll have to figure out some crazy system to make the built-in types make sense (or deprecate the old syntax).
There is a lot to like about Go, but I can't help but feel that re: hype, Go is the future MongoDB of PLs (overall I like MongoDB too).
Shameless plug: a few friends and myself ported the reference toolchain to Solaris (illumos). We hope to integrate this upstream now that Go 1.2 is released.
It is not illumos-specific, but currently it does not work on Solaris 10. It would be trivial to make it work on Solaris 8-10. The main reason I haven't fixed it is because I don't have any machine running Solaris 8-10. We need a builder that does continuous integration.
If people are interested in these older systems, and if someone donates a builder, I can make Solaris 8-10 work as well.
This is slightly OT, but I figured this thread is a good pool of Go people =).
What books/resources would you guys recommend for a beginner to learn Go?
I'm coming from a (predominantly) Python background.
I've seen Mark Summerfield's book (he also wrote the the PyQT book and Programming in Python) on Go, which seems pretty good, and I think I'll take a shot at the official tutorial.
Is there anything else you guys would recommend?
Also, is it just me, or is the word "go" hard to search for - I know there's golang, but I'm always worried I'd miss things, if people just use "go" when they write.
When I got started, I found Effective Go [0] and the Go Blog [1] extremely helpful. Effective Go goes over important properties of the language and Go Blog often go over important issues related to both language and standard libraries. I learnt about slices, interfaces, and json library all from Go Blog.
Also I think the best way to learn a language is to use it instead of reading a book. Pick up one of you old projects, and rewrite it in Go. Or pick up a new simple idea and implement in Go.
I initially had the same concern. "Golang" is a better keyword than you might think. Google is pretty smart to interpolate where it might be missing on certain pages.
Do the tour, read effective go, then start writing. As you have issues not solved by googling, join/ask golang nuts. Not a more helpful group of people in the tech world, in my opinion.
It's great that cgo now supports C++. I know that it's against Go's philosophy of short compile times, but more than once I had some C++ code that I liked to compile/link with Go code directly.
I think it's a good option to have, though some may see code compiled with Go that links to C++ code compiling slowly as the "supposedly fast" Go compilers fault.
This is perhaps a silly request: I would love to see a preview of the HTML output of this tool! Is there a page somewhere I could have a look at (really for curiosity more than anything else?)
There is no mechanism for manually excluding code. But you can view the coverage profile in a web browser. We're going to publish a blog post about the new cover tool in a day or two.
