Go 1.2 is released

http://blog.golang.org/go12

by enneff • 13 years ago

317 44 13 years ago

blog.golang.org

brunoqc2• 13 years ago

About test coverage. Is there techniques to exclude code that use the database so we get a higher percentage?

enneff4• 13 years ago

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.

brunoqc2• 13 years ago

Thanks!

interstitial• 13 years ago

Looks like an algorithmic or manual bitcoin-sweep of the front page took place. I welcome a programming language article to the #1 spot.

songgao3• 13 years ago

I don't see `TextMarshaler` and `TextUnmarshaler` mentioned in `encoding/json` or `encoding/xml` document. Are there any reasons not doing that?

enneff4• 13 years ago

I think it's a documentation omission. Please file an issue: http://golang.org/issue/new

songgao3• 13 years ago

Thanks for the link. Will do that now

memset• 13 years ago

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

shurcooL• 13 years ago

What tool?

twotwotwo• 13 years ago

There's a tool that highlights the code to show which paths are covered by your test suite. (See the other reply for pic.)

enneff4• 13 years ago

http://i.imgur.com/PJBBMu8.png

saurik• 13 years ago

People were also discussing this when the code hit, for those who didn't see that discussion.

https://news.ycombinator.com/item?id=6818371

klobucar• 13 years ago

PR is up for the formula additions to homebrew.

cmaggard• 13 years ago

And merged.

alecco• 13 years ago

The test and coverage features might bring me back to Go.

slowmover• 13 years ago

What made you decide to leave?

libria• 13 years ago

Possibly the lack of test and coverage features that might now bring him back to Go.

4ad4• 13 years ago

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.

justin66• 13 years ago

How'd you get past the split stack not working properly on SP... oh... I guess this means Illumos still isn't running on SPARC yet. ;)

Nice work BTW.

kaib• 13 years ago

Why wouldn't split stacks work on SPARC, is there something about the architecture that makes it impossible?

Zariel• 13 years ago

1.3 they are planning to have contiguous stacks

4ad4• 13 years ago

When I was involved with illumos development, it did run on SPARC. Don't know the status now. Not many people interested in keeping it alive, I guess.

I'd love the technical challenge in bringing Go to SPARC, but writing a new compiler is significant work. Gccgo works on SPARC, in the meantime.

pstuart3• 13 years ago

Is it Illumos specific or would it work on Solaris 10 as well?

4ad4• 13 years ago

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.

shykes• 13 years ago

Here's the pull request for switching to 1.2 stable in Docker: https://github.com/dotcloud/docker/pull/2978

Everlag2• 13 years ago

Official TLS 1.2 support? Oh yes please. Increases in JSON speed? Oh hell yes.

I'm loving how Go, as a package in the standard lib, now supports better TLS than most servers.

scott_karana• 13 years ago

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?

vanderZwan• 13 years ago

It's an open source language - surely critical security fixes are easily patched in?

Everlag2• 13 years ago

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.

ominous_prime• 13 years ago

They're implementing the reference so that the library can be improved over time. If you want a native implementation, you have to start somewhere.

The go TLS stack does need to be seriously audited, but that's expected, and it's going to take time for that to happen.

lloeki• 13 years ago

re-implemented in Go

Conversely, this enables a host of features (e.g cross-compiling) unavailable or disabled were you to link against C-land using cgo.

victorhooi• 13 years ago

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.

enneff4• 13 years ago

http://tour.golang.org/ - as you already mentioned.

https://gobyexample.com/ - a nice resource for beginners.

http://learnxinyminutes.com/docs/go/ - quite dense but a good overview.

songgao3• 13 years ago

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.

[0] http://golang.org/doc/effective_go.html [1] http://blog.golang.org/index

mholt• 13 years ago

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.

axaxs• 13 years ago

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.

kvtrew76557• 13 years ago

Have the GC issues been resolved yet (particularly on 32 bit)?

howeman• 13 years ago

Not fully, but mostly. See comment 64 of issue 909. https://code.google.com/p/go/issues/detail?id=909

microtonal• 13 years ago

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.

codygman• 13 years ago

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.

craigyk• 13 years ago

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

Go 1.2 is released

Related Stories