Go 1.4 Beta 1 is released(groups.google.com)
groups.google.com
Go 1.4 Beta 1 is released
https://groups.google.com/forum/#!topic/golang-nuts/7VAcfULjiB8
7 comments
More useful is a link to the release notes: http://tip.golang.org/doc/go1.4
Thanks, I should have done it like that.
The encoding/gob package has been rewritten to eliminate the use of unsafe operations, allowing it to be used in environments that do not permit use of the unsafe package. For typical uses it will be 10-30% slower
This seems like a highly questionable decision to me. I've invested a lot of time into optimizing my code that uses encoding/gob, so to now get hit by a wholesale 30% slower stamp from the Go team is a bit weird. These environments that can't use encoding/gob with unsafe, can't be that common, however it seems that everyone will suffer from their limitations.
This seems like a highly questionable decision to me. I've invested a lot of time into optimizing my code that uses encoding/gob, so to now get hit by a wholesale 30% slower stamp from the Go team is a bit weird. These environments that can't use encoding/gob with unsafe, can't be that common, however it seems that everyone will suffer from their limitations.
Trivial solution: "fork" the old, fast version of std library code into its own repo and the only change you need is to import that repo instead of "encoding/gob"
I did that few times (mostly in the other direction, where I wanted features from unreleased version of Go)
I did that few times (mostly in the other direction, where I wanted features from unreleased version of Go)
> These environments that can't use encoding/gob with unsafe, can't be that common
They aren't, but I will provide one example that benefits from this change. As of 1.4, because of this change, it will be possible [1] to use encoding/gob (and other packages that import it) in the frontend via the GopherJS project.
[1] https://github.com/gopherjs/gopherjs/commit/7d67c77e85187c7f...
They aren't, but I will provide one example that benefits from this change. As of 1.4, because of this change, it will be possible [1] to use encoding/gob (and other packages that import it) in the frontend via the GopherJS project.
[1] https://github.com/gopherjs/gopherjs/commit/7d67c77e85187c7f...
Maybe their target is the App engine.
It's true that you can't directly import unsafe in your own Go code on App Engine. However importing standard library packages like encoding/gob, which then proceed to use the unsafe package for themselves, works just fine on App Engine.
App Engine is actually the biggest reason why I don't immediately like this change. For other environments I can just fork the Go 1.3 encoding/gob implementation and use that. However on App Engine I can't import unsafe myself, so the only way to run really fast unsafe code, is to use the standard library. This latest change removes that option from me.
App Engine is actually the biggest reason why I don't immediately like this change. For other environments I can just fork the Go 1.3 encoding/gob implementation and use that. However on App Engine I can't import unsafe myself, so the only way to run really fast unsafe code, is to use the standard library. This latest change removes that option from me.
It's more that by removing the use of unsafe it will play more nicely with the new concurrent garbage collector (slated for Go 1.5 in June).
Thanks for the heads up.
Are also there plans to expose more primitives in unsafe?
I remember seeing some posts related to possible required features as part of re-writing the whole stack in Go.
Are also there plans to expose more primitives in unsafe?
I remember seeing some posts related to possible required features as part of re-writing the whole stack in Go.
It would make more sense to me to have an safe but api-compatible library version that doesn't use unsafe.
Not a great sign for lib updates in the future.
Not a great sign for lib updates in the future.
They also found (and fixed) some bugs and the code will be more robust to future implementation changes.
- `atomic.Value` is more or less a type-safe pointer with atomic updates. https://codereview.appspot.com/147720043 uses it to speed up reads on a concurrently accessed, rarely updated map, for instance.
- look forward to the 1.5 GC changes, can see them being huge for apps that are sensitive to peak latency (where there's a cluster of Go services you hit with fan-out, etc.).
- interested in seeing how folks use `go generate`, both what they do with it and how it is to use.
- look forward to the 1.5 GC changes, can see them being huge for apps that are sensitive to peak latency (where there's a cluster of Go services you hit with fan-out, etc.).
- interested in seeing how folks use `go generate`, both what they do with it and how it is to use.
That's a very useful new type that I hadn't seen in the commit logs. Thanks for pointing it out!
"Go 1.4 can build binaries for ARM processors running the Android operating system. It can also build a .so library that can be loaded by an Android application using the supporting packages in the go.mobile repository."
http://golang.org/s/go14android
http://golang.org/s/go14android
Worth noting that Go has been able to generate Android-compatible binaries for some time -- Linux ARM binaries -- however they are executables, not libraries. Still possibly usable, but more awkwardly.
So now they added the ability to generate libraries. Which is interesting because, to my knowledge, they still don't support building libraries on any other platform. It would be useful.
So now they added the ability to generate libraries. Which is interesting because, to my knowledge, they still don't support building libraries on any other platform. It would be useful.
I just saw David Crawshaw do a demo of a “full Go” program on Android, a 3D gopher rendered and rotatable by touch. I don’t claim to understand the details but, if I understand correctly, Go was handling the whole thing – touch events and OpenGL – without depending on interop with Java APIs.
> without depending on interop with Java APIs.
This is impossible, unless the device was rooted.
NDK code can only produce shared objects, which are loaded into the Java application processes.
The so called Native Activity is just a Java wrapper with a pre-defined set of methods, like touch events that map into a set of pre-defined export symbols.
The so called native activities run on their own thread and get the Java events, like touch, over an UNIX domain socket.
3D graphics programming is one of the few blessed NDK APIs. Even 2D is not accessible to the NDK in a developer friendly way, except for a bare-bones framebuffer, even though Android UI makes use of SKIA.
Outside 3D graphics, sound and partial POSIX support there isn't that much available in the NDK world without interop to Java APIs (sensors are actually JNI wrappers).
It will be nice to have Go available, but most likely the Android team will keep the same cage for Go code.
This is impossible, unless the device was rooted.
NDK code can only produce shared objects, which are loaded into the Java application processes.
The so called Native Activity is just a Java wrapper with a pre-defined set of methods, like touch events that map into a set of pre-defined export symbols.
The so called native activities run on their own thread and get the Java events, like touch, over an UNIX domain socket.
3D graphics programming is one of the few blessed NDK APIs. Even 2D is not accessible to the NDK in a developer friendly way, except for a bare-bones framebuffer, even though Android UI makes use of SKIA.
Outside 3D graphics, sound and partial POSIX support there isn't that much available in the NDK world without interop to Java APIs (sensors are actually JNI wrappers).
It will be nice to have Go available, but most likely the Android team will keep the same cage for Go code.
Can you give a bit more info about that 'happening'?
[deleted]
These aren't actual APKs right? I'm assuming this is an actual binary that would get called by an FFI from java land.
You're correct; these aren't APKs. I saw the lead dev present the project at a meetup and it appears that they're targeting games and apps developed using the Android NDK rather than standard Android Java apps.
> Updating: Code that depends on the old, erroneous behavior will no longer compile but is easy to fix by adding an explicit dereference.
Is there a `go fix` script for this breaking change? If not, why not?
Is there a `go fix` script for this breaking change? If not, why not?
> for _ = range x {
can now be:
> for range x {
Funny enough I just ran into this awkwardness yesterday (I was ranging over a Ticker to send keepalives but did not need the timestamp).
can now be:
> for range x {
Funny enough I just ran into this awkwardness yesterday (I was ranging over a Ticker to send keepalives but did not need the timestamp).
To everyone searching the page for "generics", they're still not there.
You were thinking maybe a gigantic new language feature would show up in the delta from 1.3 to 1.4.
If you follow Golang development, one of the uncanny things about it is how they really seem to nail the release schedule. They say what they're going to do. They say when they're going to be done. Then they do it, and announce their completion.
I think you can safely assume you'll know a ways ahead of time if Golang is suddenly going to become acceptable to people who require parameterized types to adopt a new language.
If you follow Golang development, one of the uncanny things about it is how they really seem to nail the release schedule. They say what they're going to do. They say when they're going to be done. Then they do it, and announce their completion.
I think you can safely assume you'll know a ways ahead of time if Golang is suddenly going to become acceptable to people who require parameterized types to adopt a new language.
Pretty sure you just fed and obvious troll, who's account was created 8 hours ago :)
Most likely they will never be.
I have decided to shut up about them.
Regardless of having generics or not, every line of Go code is a line less of C or C++ with Cisms code, so in a way it is already an improvement.
I have decided to shut up about them.
Regardless of having generics or not, every line of Go code is a line less of C or C++ with Cisms code, so in a way it is already an improvement.
Bringing in support for code generation as part of 'go build' certainly makes it easier for code generated generics to happen.
You can fake it if you really want them: http://clipperhouse.github.io/gen/
I remember being so angry at delphi for its lack of generics.... I didn't think this would happen again.
I think you're looking for https://github.com/bouk/gonerics which is generics via the opaque import expressions.
I think the devs have been clear on no need for generics anytime soon. If they do anything like generics its going to be structures and patterns for concurrency related development.
but i searched this page and here they are! ;)
I think you're looking for rust-lang.org
This comment is not helpful. The languages are very, very different.