

Go 1.4 Beta 1 is released - pjmlp
https://groups.google.com/forum/#!topic/golang-nuts/7VAcfULjiB8

======
sandyarmstrong
More useful is a link to the release notes:
[http://tip.golang.org/doc/go1.4](http://tip.golang.org/doc/go1.4)

~~~
pjmlp
Thanks, I should have done it like that.

------
Strom
_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.

~~~
pjmlp
Maybe their target is the App engine.

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

~~~
pjmlp
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.

------
twotwotwo
\- `atomic.Value` is more or less a type-safe pointer with atomic updates.
[https://codereview.appspot.com/147720043](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.

~~~
bgentry
That's a very useful new type that I hadn't seen in the commit logs. Thanks
for pointing it out!

------
marcuskaz
"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)

~~~
mwsherman
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.

~~~
pjmlp
> 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.

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

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

------
degutis
To everyone searching the page for "generics", they're still not there.

~~~
tptacek
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.

~~~
SEJeff
Pretty sure you just fed and obvious troll, who's account was created 8 hours
ago :)

~~~
tptacek
I'm sure you're right; I'm just chasing the little dopamine hit from
predicting someone would make a comment about generics and knowing how I would
respond.

