
Go 1.4 is released - ahochhaus
https://blog.golang.org/go1.4
======
krat0sprakhar
> The most notable new feature in this release is official support for
> Android. Using the support in the core and the libraries in the
> golang.org/x/mobile repository, it is now possible to write simple Android
> apps using only Go code.

This is fantastic! Are there any example Android apps released by the Go team
to help get started ?

~~~
alfiedotwtf
And now things just got interesting. I'll put my money on the availability of
Go on Android being the catalyst for its future hockey stick growth.

~~~
bsaul
I would be extremely surprised to see a language having no class, no
inheritance and no good IDE become successfull in modern app development.
Android devs are used to such a different type of programming, i don't expect
them to accept banging their heads on so many walls for such little gains.

Ps : my stand is the opposite for server side dev.

~~~
jud_white
> no good IDE

LiteIDE is open source, cross-platform and pretty enjoyable.
[https://code.google.com/p/liteide/](https://code.google.com/p/liteide/)

~~~
bsaul
It's the one i'm currently using, but calling it enjoyable is really excessiv.
You can't compile or get any kind of completion while running your program,
you can't define a script to be called when hitting "run" ( it always tries to
launch your current file). It doesn't have any kind of macro or refactoring
features, etc..

Coming from xcode and pycharm, it still feels a decade younger.

------
xrstf
Damn, another project giving up on Mercurial and switching to Git. :-/ A few
more major ones and basically nobody is using Mercurial anymore. How sad.

~~~
rnhmjoj
I have never use hg. I don't really see much difference. What do you like
about it?

~~~
McP
There isn't much of a difference. The underlying principles of how they work
are essentially the same. However hg has IMHO a more pleasant UI, and it's
easier to customise. I believe Facebook chose hg for the latter reason:
[https://code.facebook.com/posts/218678814984400/scaling-
merc...](https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-
facebook/)

------
pjmlp
Even if I don't agree with all design decisions, Go is certainly coming
forward.

Congratulations to everyone involved.

------
_RPM
Can someone give me a compelling reason to start programming in Go? My default
language at the moment is C, or C++.

~~~
mholt
Once Go is installed, I can make a simple web app from scratch that displays
parameters from the URL or request body in just over 95 seconds with Go, using
only the standard library. I can cross-compile it for another OS and
architecture, then deploy a single binary file without worrying about
dependencies, dynamic linking, or segfaults.

Try doing that in C/C++.

Maybe a better comparison is to more systems-level applications like you might
code up in C. The same benefits carry over to those, without a significant
performance hit (usually).

(And to be fair, sometimes C/C++ is the better tool for the job. But give it a
shot; Go is pretty handy when you don't need to drop down to lots of unsafe
memory and CPU operations.)

By the way, your existing C skills will be very useful in Go. For example,
struct fields will still be padded unless you pack them carefully. Your
experience with buffers, streams, memory allocation, and data structures will
definitely not be wasted in Go.

~~~
codexon
You can still get segfaults in Go.

"panic: runtime error: invalid memory address or nil pointer dereference"

~~~
howeman
But you also get a stack trace without needing an IDE and debugger.

~~~
Morgawr
I've been working with Go daily for a few months now at my job and I'd like to
point out that Go stack traces have a really big signal to noise ratio. There
is a lot of cruft that mostly nobody cares about and sometimes it can be hard
to pinpoint exactly where something crashed (at which line) with a panic.

Just saying, they should probably improve it to be less verbose and more
concise.

~~~
riobard
In that case you would say it has a really low signal-to-noise ratio.

~~~
Morgawr
Yes, you are 100% correct, I dun goof'd. I would edit the post but apparently
I can't, so I'm sorry for that. Same for the other person commenting on it.

------
valevk
There is a new range syntax[1]. The release notes say it's rarely used, but
makes code cleaner. In which cases would the syntax be useful?

[1]
[https://golang.org/doc/go1.4#forrange](https://golang.org/doc/go1.4#forrange)

~~~
thomasahle
If they added support for `range 10` to iterate 0-9 this would be useful for
doing things a certain number of times. Now it's probably mostly useful for
emptying iterators.

~~~
andrewchambers
Why do they need to add support for this?

it already exists...

[https://github.com/bradfitz/iter/blob/master/iter.go](https://github.com/bradfitz/iter/blob/master/iter.go)

~~~
thomasahle
I don't think that would be considered good Go code. It's no shorter than
writing out the 3-part for loop, and it is probably slower.

~~~
andrewchambers
what extra operations do you think range on a slice would do? The generated
assembly is probably the same. Stylistically it is odd however.

------
rcarmo
Nice. Now all I need is for someone to turn
[https://github.com/jcla1/gisp](https://github.com/jcla1/gisp) into a slightly
more complete LISP and I'll have a nice environment for all kinds of ARM
systems.

Edit: typo/autocorrect

~~~
rxaxm
this your project? i'm down to do this

~~~
rcarmo
Nope, just something I've been keeping track of. Needs macro support, for
starters, and this fork
([https://github.com/masukomi/gisp](https://github.com/masukomi/gisp)) is
adding tests.

------
cryptos
I wonder why they didn't move the main code repo to GitHub as well.
[https://go.googlesource.com/](https://go.googlesource.com/) is somewhat poor
compared to GitHub.

~~~
dsymonds
Because we want a good code review system, and GitHub doesn't have that.

More discussion:
[https://news.ycombinator.com/item?id=8715529](https://news.ycombinator.com/item?id=8715529)
[https://news.ycombinator.com/item?id=8605204](https://news.ycombinator.com/item?id=8605204)

~~~
touristtam
Gerrit looks pretty horrid to use to be honest.

~~~
skj
Its UI can appear clunky in some ways, but once you get the hang of its
nuances code review is very clear and easy to manage.

------
makeramen
At first glance it seems like you will be able to use go on Android the same
way you can use C and C++ through a jni bridge between the java and go code:
[https://github.com/golang/mobile/blob/master/example/libhell...](https://github.com/golang/mobile/blob/master/example/libhello/README)

I'm very curious to how the go runtime and GC will work.

------
nXqd
Now you can write Android application and eventually iOS ( I don't know if I
need that ), this is quite interesting. Congrats go team !

~~~
saosebastiao
Did I miss something? I didn't see anything about iOS.

~~~
bradfitz
[https://groups.google.com/forum/#!searchin/golang-
nuts/ios/g...](https://groups.google.com/forum/#!searchin/golang-
nuts/ios/golang-nuts/mmB2q8RqB-Y/LDog1d7ZM5kJ)

Quote:

gophers,

I'm happy to announce that the iOS port of Go recently gained full cgo and
external linking support.

I've also got a simple C based application working on a real iPad.

The port lives in ios3 branch of
[https://bitbucket.org/minux/goios](https://bitbucket.org/minux/goios). Read
misc/ios/README for some rudimentary documentation.

The port is Go 1.4+, and it's based on upstream dev.cc branch. I intend to
propose for inclusion into Go 1.5 after finding a way to test it (either build
each test as an App, or use the open source xnu/arm port). Brad mentioned that
inclusion of iOS support might happen in Go 1.5 in his talk the state of the
gopher ([http://talks.golang.org/2014/state-of-the-
gopher.slide#40](http://talks.golang.org/2014/state-of-the-gopher.slide#40)),
now I believe it really will happen.

The iOS port is my first Go OS port, but it's the only one that takes almost 3
years to complete. :)

Go build iOS Apps. Let's see when can we see a Go based App in the store.

Minux

~~~
tptacek
I love Rob Pike's contribution to the thread:

 _Ken and I ported Plan 9 to the SPARC in 6 days over one fun Christmas
break._

 _I wrote the disassembler (for the debugger) and Ken wrote the assembler, so
we could cross-check each other 's work. The hardest problem other than
fighting register windows occurred when we both misread the definition of an
instruction the same incorrect way._

------
hanief
Can you build Android UI using Go? I have not found a good UI library in Go.

~~~
tjohns
You can access OpenGL, but the full Android framework isn't directly exposed.
It's similar to developing in C++ using the Android NDK.

From the documentation
([https://godoc.org/golang.org/x/mobile/app](https://godoc.org/golang.org/x/mobile/app)):

    
    
      An app can be written entirely in Go. This results in a significantly
      simpler programming environment (and eventually, portability to iOS),
      however only a very restricted set of Android APIs are available.
      
      The provided interfaces are focused on games. It is expected that the
      app will draw to the entire screen (via OpenGL, see the go.mobile/gl
      package), and that none of the platform's screen management
      infrastructure is exposed. On Android, this means a native app is
      equivalent to a single Activity (in particular a NativeActivity) and on
      iOS, a single UIWindow. Touch events will be accessible via this
      package. When Android support is out of preview, all APIs supported by
      the Android NDK will be exposed via a Go package.
    

Alternatively, you could write your UI code in Java and call into a Go shared
library via JNI methods, if you aren't worried about graphics and just need
code portability. Again, this is similar to working in the NDK.

~~~
hanief
Thanks for the link. I just read about it. So probably it's not a substitute
for Java (yet) right? I guess it's kind of a replacement of C++ for multi-
platform games development.

------
bgentry
Doesn't look like it's been pushed to the canonical git repo or Github just
yet: [https://go.googlesource.com/go](https://go.googlesource.com/go)
[https://github.com/golang/go/releases](https://github.com/golang/go/releases)

Aside from that, this is yet another great release! :)

~~~
dsymonds
It will be soon. I'm working on it.

~~~
bgentry
Looks like it's up now :) Thanks!

------
frik
What's the current roadmap for dynamic linking / shared library support?

Is this the current one?
[https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLo...](https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLovrHvvLhK_h0KN8woTO4/preview?sle=true&pli=1)

------
Kabukks
Just to make sure I'm not missing it: fsnotify didn't make it into Go 1.4,
right? 1.5 maybe? :)

~~~
krat0sprakhar
Pardon my ignorance but if fsnotify is not available how is Hugo (static site
generator) listening for events in the filesystem (to reload the server)

~~~
mischanix
By using platform-specific cgo calls.

~~~
regecks
Probably unimportant for the asker, but go-fsnotify uses syscalls, not cgo.

------
JulianMorrison
I think they ought to add a one argument version of the copy() keyword to
bitwise-duplicate and fix up the pointers on the built-in slices and maps.
This would support the copy-change-replace semantic their example for Value
follows.

------
JulianMorrison
"Package glsprite blah blah blah TODO". Okay then :-D

~~~
BarkMore
I was going to suggest that you report this as an issue at
[https://github.com/golang/mobile](https://github.com/golang/mobile), but
issues are disabled on that repo.

~~~
fhs
They're using one issue tracker for everything:
[https://github.com/golang/go/issues](https://github.com/golang/go/issues)
Issues for sub-repositories like this go there also.

------
fxbois
Mobile development will soon be exciting with the fight Go vs Swift

------
cyber1
Super!

------
bpatel576
Good god. Seriously, another language. I'm just starting out learning how to
program, and I find it irritating that there are so many languages and it's
not that easy figuring out which ones you should learn and which ones you
shouldn't.

~~~
FraaJad
focus on

step 1. getting good at solving problems in _one_ language

step 2. get really good at that language. (ie., know how to avoid pitfalls,
get best performance, know corner cases)

step 3. learn new languages that expose you to newer paradigms (ie., you know
"OOP" languages, learn FP langauges next).

------
codemac
And they actually stuck with their go generate design? What an unfortunate
mis-step.

Let the makefile's continue.

I've seriously thought about moving to gccgo just to try and get a build
system where I can actually inject dependencies on .go files builds again.

~~~
bradfitz
You seem to be confusing compilers and build systems. You can use whatever
build system you'd like and with whichever compiler.

~~~
Gracana
Is it possible to do away with the typical Go project directory structure? I
thought all that was enforced by the tools, but it's possible that I didn't
dig deep enough to uncover greater flexibility.

~~~
codemac
No it's not if you ever intend to type `go`.

The go team has decided that the go language doesn't depend on any build
system, but pushes a single build system one that requires source code
compatibility and provides no benefit over many existing and easy to use build
systems (makefiles, tup, etc).

------
teddyh
This relatively recent trend of company-specific languages annoys and disturbs
me.

I don’t ever want to be tied to a language and library ecosystem under the
thumb of a single (large) corporation. Not Visual Basic, not .NET, not C#, not
Objective C, not Go (It’s even named after the company, for crying out loud!
Yes it is. Don’t try to claim otherwise).

I’ve used Basic, I’ve used Pascal, I’ve used C, I’ve used Python, I’ve used
Lisp, and so on and so on. Those were open platforms, with different companies
in the “lead” position in any one time (Microsoft Basic, Turbo Pascal, Borland
C, GNU C Compiler, CPython, PyPy, etc.), but the language was not “owned” by a
single company which would _loom_ in everyone’s mind, always the unspoken fear
being “what if _< company>_ doesn’t like it?”.

I will not use tools which make me afraid. I will not live a life in fear.

~~~
bodyfour
I'm generally in agreement, but it's hard to say what languages will be
considered "company-specific" in the future.

Go back in time 35 years and C could have been called that "AT&T specific
language" Or the opposite: Objective C looked like a hopeful contender to be a
widely-used language but it just never caught much traction outside the
NeXT/Apple (and NeXT ended up buying the developer) and today it's almost
completely associated with a single company's ecosystem.

Maybe in 4 years we'll be talking about the new features coming in "ISO Go19"
and complaining that VisualGo still doesn't support all of Go18 yet. Who
knows?

~~~
teddyh
True, but _today_ Go is still specific to Google. If it really catches on in
the way you describe, then it _will be_ a viable language. But not today.

