Hacker News new | past | comments | ask | show | jobs | submit login
Go 1.1 RC2 is out (groups.google.com)
86 points by mitchellh on May 7, 2013 | hide | past | favorite | 27 comments



I have been learning go for the past 4 weeks now and love it. Does anyone have any advice on a good GUI library that works well with Go? I have had a look at some of the Qt bindings but they are not that great sadly.

Also is there a decent MSSQL library for Go yet?


Also is there a decent MSSQL library for Go yet?

You will find some here:

http://godoc.org/?q=mysql

http://go-lang.cat-v.org/pure-go-libs

EDIT: I just realized that you asked for MSSQL libs and not MySQL. Sorry, those links wont help you.


No worries. I have had a pretty good look but have not found anything for MSSQL sadly. There are some bindings for Qt and some custom widget kits but nothing that great sadly. I would love proper Qt bindings but that will take a while.


I use this one for MSSQL through ODBC: https://github.com/LukeMauldin/lodbc


Implementing the TDS protocol is fairly straightforward, and although it may take some time, it will help a lot of people and likely make you even more familiar with the language. I did it in pure-JS for node.js and it was a great learning experience.


don't use go with mssql. why would you want to do that.


As a product, MSSQL is surprisingly solid. That said, unless you're being forced to use it, I'd concur with avoiding it. And if you are going to use it, then why Go? Why not just stick with C#/C++ or any other language with established libraries for MSSQL.


Picking what language to use based on your database seems silly.


You should pick a language based on project and customer requirements, not what you like to use.

Since MSSQL is mostly used in Windows shops, nothing more natural than using a language directly supported by Microsoft.


Same reason golang apps need to run on windows. Golang needs good library support for MSSQL.


I love how they update every few weeks :) I'm looking forward to each new version like a kid in a candy store.


Better than that, this version (I think) comes with the database performance improvements that made Golang go back to the tippy-top of the Techempower benchmarks.

Massive improvements were made. This is impactful and cool stuff. :)


FYI they're not these doing quick release cycles because they want to.

This is RC (Release Candidate) 2.

The way release candidates work is they can't become an official release if issues are found with that candidate.

They're putting out this second RC because they want to get to the official 1.1 version, but there where issues with RC 1 and as such it failed as a candidate for the official 1.1 release.

Over the next few weeks they will be hoping there is no RC 3.


Don't expect too many new versions. Go's philosophy is "less is more". 1.1 was needed to fix a few nagging problems. With v 1.5 or 2.0 they might introduce generics (still being discussed ) and that's it. I think most changes will be performance based and nothing to the language itself.


I doubt they will change much after 1.1, given the designers' philosophy in language design.


That's my favorite feature. They still may make significant changes that don't effect syntax.


That is what made me disregard Go, after my initial interest on the language, but then again I am a CS guy that feels at home with FP and similar stuff.

Nowadays I rather play with D and Rust, but I wish success to the Go team anyway, as choice is always good.


What are some common gotchas I should be wary of if I want to try out Go? I haven't touched the language since I first heard about it, due to an issue that has been left unfixed for almost three years.

https://code.google.com/p/go/issues/detail?id=909

Here is a C# example of what I'm looking for:

LINQ brings brevity and clarity to complicated collection operations. However, if you rely on it in performance-critical applications, then you will find that it causes enough garbage collection overhead to slow your app to a crawl.


From what I know on the topic issue #909 only ever had a realistic chance of affecting 32-bit users. And from the looks of it, they've made the GC in Go 1.1 more precise, so hopefully the incidence of those problems on 32 bit goes down even more.

I use Go exclusively on 64 bit and have never had that problem. This includes Go programs that use 64GB+ of memory that can run for days. I also use other long running Go programs (a web site and an X window manager) and haven't run into problems.

> What are some common gotchas I should be wary of if I want to try out Go?

The most common complaint people have is that Go doesn't have "generics" like that found in most other statically typed languages (e.g., parametric polymorphism or ad-hoc polymorphism). You can still get a lot of code reuse through Go's flavor of polymorphism (structural sub-typing), but it requires a little brain rewiring---and that puts some folks off.


Is there a list of changes since Go 1.1 RC1? Just curious what held up the release.


  *C: add Jeremiah Harmsen (Google CLA).
  *cmd/cgo: correct pragma name in comment.
  *cmd/ld: add .note.GNU-stack section for external linking (thanks Shenghou Ma),
        fix SDYNIMPORT symbol test (thanks Alex Brainman),
        fix another unsigned value causing bugs on Plan 9,
        fix syms that are both cgo_import_static & cgo_import_dynamic.
  *database/sql: remove an unused field from Rows.
  *doc: add FAQ entry about language changes,
        fix formatting in effective go code snippet,
        link to Go 1.1 release notes,
        only U+FEFF is a byte-order mark; U+FFFE is not.
  *go/build: document GOOS.go also has implicit GOOS build constraint (thanks Shenghou Ma).
  *go/doc/example: Fix bug causing false negatives for Example playability.
  *image/png: fix error message to not return width twice.
  *libmach: fix build on Plan 9 (thanks David du Colombier).
  *net: do not call syscall.Bind twice on windows (thanks Alex Brainman).
  *regexp: doc fix.
  *runtime/cgo: export symbols in both internal and external link mode.
  *runtime: fix crash in badsignal(),
        reduce max arena size on windows/amd64 to 32 GiB (thanks Shenghou Ma).
  *syscall: fix prototype of Fchflags (API change) (thanks Shenghou Ma).
  *text/template: comment fix.


One big one (for Windows users) was they reduced the amount of heap a Go program on Windows can access from 128 GB to 32 GB. This was to work around a design flaw in the Windows virtual memory allocator that forces virtual memory commitments that are free in Linux/BSD/OSX to have to be backed with memory, or more commonly, swap on Windows. On the other OSs mentioned above the Go runtime's pre-allocation of virtual memory space is non-backed.


There are not a lot: https://code.google.com/p/go/source/list Go1.1rc1 was issued on May 1, unfortunately I can't see the tag but all changes since May 1 till go1.1rc2 tag fit to one web page so it's not hard to click all of them to have a vision.



That's not what he asked for. I'm too curious about the changes since RC1.


There is no new features here, it's just issues being fixed and closed, mostly weird and harcore ones.


Which is typical for RC releases, feature freeze and bugfixing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: