
The State of Go - crawshaw
http://talks.golang.org/2015/state-of-go-may.slide#1
======
melling
Nice little change in syntax.

    
    
        m := map[Point]string{
            Point{29.935523, 52.891566}:   "Persepolis",
            Point{-25.352594, 131.034361}: "Uluru",
            Point{37.422455, -122.084306}: "Googleplex",
        }

may now be written as:

    
    
        m := map[Point]string{
            {29.935523, 52.891566}:   "Persepolis",
            {-25.352594, 131.034361}: "Uluru",
           {37.422455, -122.084306}: "Googleplex",
        }

~~~
nickysielicki
I came into the comments to say that I very much dislike this change. I much
prefer the extra syntax to not really knowing what '{29.935523, 52.891566}'
actually means.

~~~
iokevins
They seem to say you may choose to continue specifying it, as you prefer (?)

~~~
nickysielicki
Sure, I can write code the way I like. But the readability of code affects
everyone, not just me.

Still, 4ad's comment above mine changed my mind. I didn't consider that you
can do this with structs already (in spite of the fact that I already do that
in my code), and I prefer the consistency to the lack of verbosity.

------
acomjean
Pretty neat, go is now written in go "Go 1.5 has no C code in the tool chain
or runtime.", go shared libraries interoperable with c.

I'm really a go tinkerer, but I like the langauge.

I didn't realize Garbage Collection was so expensive that the goal is to only
have it run 20% of the time. But its a good goal.

"Run Go application code for at least 40ms out of every 50ms."

~~~
danieldk
_go shared libraries interoperable with c._

How does this work? As far as I understand Go is moving to a copying
collector, so any pointers passed to C may become wild pointers when garbage
collection is performed.

On go-nuts, Go's developers have been warning that passing arrays to C by
getting the address of the first element of the slice will be unsafe for this
reason.

~~~
Daemon404
Dang, I always figured that would be unsafe eventually.

I wonder, does this make stuff like this unsafe:

var thing C.thing; C.somefunc(&thing)

i.e. can stack address change now?

~~~
danieldk
The Go spec does not contain the stack or heap, so I guess that in principle
it's fair game for the collector to relocate it in memory. In some future
version it's only safe to use memory in C-land that was allocated in C-land.

~~~
AnimalMuppet
Wouldn't it be safe to use in C-land as long as you kept a reference to it in
Go-land? Something like:

    
    
      Create memory in Go-land
      Use memory in C-land
      Dispose of reference to memory in Go-land
    

That becomes a bit problematic if the C-land use is for a long-running process
- you need a go object that owns the memory that has a lifetime that (at
least) matches the lifetime of the C code execution.

~~~
danieldk
Currently, yes. Once Go has a moving garbage collector (soon-ish), no. A
moving garbage collector can move objects around. This would invalidate
pointers in C, since the GC can run concurrently with C code (even if it
didn't, it would invalidate pointers to object allocated in Go in C structs).

To make things work, you have to allocate date used in C in C and pass Go
variables only by value.

------
est
I always have this question:

Since a large project like Golang has so many auto-build tools and test OSes,
how hard is it to provide a binary download for e.g. Ubuntu 14.04 LTS? You
know, not tarballs, but actual static binaries as deb packages installable via
apt-get.

Good examples:

[http://wiki.nginx.org/Install](http://wiki.nginx.org/Install)

[https://www.percona.com/doc/percona-
server/5.6/installation/...](https://www.percona.com/doc/percona-
server/5.6/installation/apt_repo.html)

I root for open source movement, but to install something on a popular arch/OS
by compiling from source everytime is just meaningless power consumption and
adding CO2 emissions.

~~~
insertnickname
golang.org offers two types of downloads for Linux: a source tarball and a
pre-compiled tarball. If you download the pre-compiled tarball, you just have
to extract it somewhere and set some environment variables (all explained in
detail on golang.org).

If you really want to install Go via your package manager, you can install the
golang package from the Ubuntu repositories. However, this package is
naturally on an outdated version of Go. Also worth mentioning is godeb[1]
which can generate and install a .deb of any version of Go for you.

[1]: [http://blog.labix.org/2013/06/15/in-flight-deb-packages-
of-g...](http://blog.labix.org/2013/06/15/in-flight-deb-packages-of-go)

~~~
rattray
> If you really want to install Go via your package manager,

Don't most people want to install X via their package manager?

> However, this package is naturally on an outdated version of Go

I can't tell if you're being sarcastic or not here - why would a package such
as this be outdated?

~~~
insertnickname
>I can't tell if you're being sarcastic or not here - why would a package such
as this be outdated?

Because of the way software is packaged in most Linux distributions. The
upstream version is frozen in that particular release.

~~~
ForHackernews
One would hope that being six to ten months behind the development branch
wouldn't make very much difference. If it does, I'd argue Go isn't mature
enough for general use yet.

~~~
enneff
The Go project makes stable releases every 6 months. They are extensively
tested and fully compatible with all previous major releases. But we do
introduce new tools, libraries, and minor language features. Developers almost
always want to be using the latest stable release of Go. (There's seldom a
reason not to.)

------
amelius
Slide 10 shows the benchmark differences, and I found them a little suspect.
The "binary tree" benchmark is the only one that is 25% worse than the old
version, but in my opinion it is an important benchmark, because I suppose
that this benchmark actually creates a lot of objects that need to be garbage
collected. At least that is what I suppose, based on the fact that this holds
for binary tree algorithms. The other benchmarks are mostly about formatting
and regexping, which require much less objects to be created on the heap, and
these are making the benchmarks look better.

~~~
masklinn
> Slide 10 shows the benchmark differences, and I found them a little suspect.

To be fair, they follow a slide about general performance, 4 slides after the
GC slides.

And from the concurrent GC slide it looks (as one would expect) that the GC
burns significantly more resources overall (it's not just longer wallclock),
though it rarely completely stops the world anymore: on the right-hand side,
where the old GC would burn 1 unit of CPU for 240ms (3 * 80ms), the new one
burns half a unit of CPU for 900ms (plus a unit for 2ms), which mean it's
using 452ms of CPU, close to twice as much as the old one. Though the
application pauses significantly less (which is good for responsivity), that's
CPU time it doesn't get to use anymore. The concurrent GC also "leaves off"
more work for later, the left-hand side graphs show relatively low CGC use for
the first 7s, followed by a spike and then much, much longer GC runs (though
at progressively lower CPU%).

I don't know about others, but it was my expectation that overall performance
would take quite a hit for GC-heavy applications in 1.5.

------
giaour
Shared libraries? I thought "no DLLs" was one of the major design philosophies
of Go.

~~~
NateDad
There was a big push from the linux distros as the maintainers had anneurisms
thinking they'll need to rebuild hundreds of Go applications when/if a big bug
is found in the Go standard library. They also don't like the idea of having N
copies of the code for the standard library in N Go applications.

Personally, I find that kind of thinking to be a relic of the past when memory
and disk space were expensive and compilation took a long time.

Sure, if you're running on a raspberry pi, a few megs here and there might
actually matter... but even my phone has 2gigs of RAM and 32gigs of disk
space.

~~~
groks
> ...a relic of the past when memory and disk space were expensive ... a few
> megs here and there might actually matter...

The nature of the modern computer is that cpu speed has increased more than
memory speed, so if your data doesn't fit into cache your cpu will be do
nothing quickly.

Even with shared libraries, this phenomena has such an impact that the Linux
kernel now has a memory de-duplication feature (mostly for VMs):

[https://lwn.net/Articles/306704/](https://lwn.net/Articles/306704/)

~~~
4ad
This has _NOTHING_ to do with shared libraries vs. statically-linked code.

The size of the binary is completely irrelevant when considering if the code
fits in the CPU cache. What's important is the size of code that actually
executes. Dynamic linking changes nothing.

~~~
twoodfin
I'm not sure what you mean. Absent some deduplication wizardry by the OS, if I
have 60 processes using the "same" statically linked copy of libfoo, that's 60
copies of libfoo's instructions and static data fighting for cache and real
memory. Dynamic linking & decades-old virtual memory technology cull that to a
single copy.

------
rifung
"Go 1.5 provides support for Android and experimental support for iOS."

I thought this day would never come.

~~~
namelezz
I wonder how Go can be better than Swift for iOS development.

~~~
kainosnoema
It may not _always_ be better since you'll likely never be able to call from
Go into Cocoa libs, but if you can write a shared library and use it on the
server, iOS and Android, then it's a big win. Linking a Swift app against the
shared Go library and calling directly from Swift into Go sounds pretty great
to me.

~~~
fit2rule
>call from Go into Cocoa libs

It can be done, thus:

    
    
        #cgo LDFLAGS: -Wl,-U,_iosmain,-U,_PopUpDialogBox
    
    
    

Any developer who wants to do this needs only to create these #cgo statements
for whatever Cocoa API they want to use, and they become available from the Go
context ..

------
sergiotapia
Not that I'm complaining but it this a coordinated effort to push Go to the
front page? There are literally 6 submissions on the front page related to Go
- what gives?

~~~
castell
The same was true during the Microsoft Build event, the difference was that a
lot of Microsoft employees registered a new (green) HN account. Not that I'm
complaining but it looked more like a coordinated effort than Go language
which has minimal PR from Google but is used by many devs around the world and
is very big in Asia.

~~~
seanmcdirmid
There are a lot of MS employees on HN normally, no need for green accounts.
Also, where is Go popular in Asia? I haven't heard much about it in China (it
isn't a resume point yet).

~~~
AYBABTME
That's odd, from within the Go community it's understood that there's a rather
large followership in China. At least, speaking for myself.

~~~
seanmcdirmid
I've heard this to, but haven't observed it in my part of the industry
(systems/PL research with lots of undergrad and grad interns from top ranked
schools, who are usually the PL early adopters). Scala has been getting more
interest lately, and there is growing interest in Rust.

~~~
sacado2
The thing is, Go is particularly not interesting for PL researchers and geeks
seeking novelty. It's more of a boring, pragmatic language. Elixir, rust et
al. are much more funny, IMHO. That might be the explanation.

~~~
seanmcdirmid
Yea, but isn't Go supposed to be a systems language? You might expect it to
pop up more with systems candidates.

------
dvirsky
Oh man, dynamic loading of Go libraries is going to be awesome. I'm in the
process of developing an http API framework/server (yes, yet another one, but
why is a different topic). This will allow me to compile the actual APIs
running on the server (multiple APIs can run on one server) as shared
libraries and have the server automatically start them.

~~~
abetusk
As far as I know there is still no easy facility to dynamically load libraries
at runtime (like the analogous 'dlopen' in C). There are shared libraries and
they can be linked at compile time so it's a step in the right direction.

~~~
dvirsky
The spec that's linked from the presentation says that it should be possible
(and has an example API usage). Unless they didn't implement it fully, of
course, or it's due for a later Go version.

> to support Go packages that want to use plugins, a new package will be added
> to the standard library: plugin. It will define a function and a type.

[https://docs.google.com/document/d/1nr-
TQHw_er6GOQRsF6T43GGh...](https://docs.google.com/document/d/1nr-
TQHw_er6GOQRsF6T43GGhFDelrAP0NqSS_00RgZQ/edit?pli=1)

[EDIT] I looked at the commits and it looks like it's not in the works, at
least on the main repo.

------
fitzwatermellow
From the penultimate slide, a list of upcoming Golang community conferences:

GoCon - Tokyo, Japan - June 21
[http://gocon.connpass.com/event/14063/](http://gocon.connpass.com/event/14063/)

GopherCon - Denver, Colorado - July 7-10
[http://www.gophercon.com/](http://www.gophercon.com/)

GolangUK - London, UK - August 21
[http://www.golanguk.com/](http://www.golanguk.com/)

GothamGo - New York, NY - October 2
[http://gothamgo.com/](http://gothamgo.com/)

dotGo - Paris, France - November 9
[http://www.dotgo.eu/](http://www.dotgo.eu/)

------
petesoder
If you're interested in the full talk, we'll have the vid posted at
[https://www.hakkalabs.co/meetups/gosf](https://www.hakkalabs.co/meetups/gosf)
within a few days or so.

------
ubercore
At the risk of lazy-web, I just came off an attempt at writing a small service
in Go. I liked the language, but found vendoring and package/dependency
management sucked most of my time, and I never reached a workable conclusion.
I'd really like to give Go another, heh, go.

I know it's an open topic, and there's no true "one way", but I'm wondering
how people here would handle this situation. And perhaps it's my Python-addled
brain that's the problem, since GOPATH is kinda sorta like PYTHONPATH, maybe
enough to confuse me.

I have a repo at github.com/user/repo. It consists of independent but related
applications, most in Python, one in Go. The Go project would be rooted in a
"service" subdirectory.

I feel like I'm really missing some critical piece of a Go workflow, because I
could never get that to build reliably when I started adding external
libraries as a dependancy. It seems like I'd have to put the project in
github.com/user/repo/service/src/github.com/repo/service, which is what makes
me think I don't understand what I'm talking about!

To bring this rambling lazyweb back on topic, I guess I was a little
disappointed that vendoring/packaging wasn't mentioned in this state-of-Go
talk. I was really hoping I could easily give Go another shot, but in the
absence of that, anyone have a suggestion for my setup above?

~~~
virulent
I have a similar feeling. I don't really like GOPATH, but I'm trying to come
to terms with it.

Your Go "project" goes in $GOPATH/src, i.e. your git repo would be in
$GOPATH/src/github.com/user/repo

If you have your main pkg in $REPO/service, then you can build like so: go
build github.com/user/repo/service (this can be ran from anywhere as it uses
$GOPATH)

If you need to add a dependency, use: go get github.com/.... and go get will
add it to $GOPATH/src/ which you can then import.

~~~
ubercore
Hmm, ok. I think I get that -- I'll have to see if I can symlink into the
GOPATH; I feel like I read somewhere you can't. I'd like to avoid making my
GOPATH be a subdir in the containing repo.

Thanks!

------
lake99
I was surprised to see Plan 9 still supported. Are there any core Go
developers who still use Plan 9 as one of their primary work machines? Is Plan
9's userbase growing?

~~~
rsc
What's the rationale for not supporting it, given that the work is done and
the maintenance burden is minimal?

~~~
lake99
I can't offer a rationale, because I have no say in the matter, or even a
preference, one way or another. I asked out of mere curiosity. But if you were
to tell me that the Go team dropped support for Plan 9, for the same reason
they dropped support for dragonfly/386 and OSX 10.6, that explanation would
have a very low entropy for me, because apparently, the last release of Plan 9
was in 2002.

~~~
rsc
Plan 9 is still updated incrementally; there just hasn't been a formal new
numbered release. Dropping Dragonfly/386 and OS X 10.6 would be more like
dropping the 3rd edition of Plan 9 (except we never supported it).

~~~
lake99
I see. Thank you for the clarification. I was hoping you'd tell me that there
are quite a few active users who are developing cool stuff for Plan 9.

~~~
4ad
There are.

------
nkozyra
"Go 1.5 provides support for Android and experimental support for iOS."

Tell me more ...

~~~
HaseebR7
[https://github.com/golang/mobile](https://github.com/golang/mobile)

------
advanderveer
Was hoping for some news on vendoring, the discussion on the mailing list
didn't really end with any actionable conclusions.

------
sanderjd
The analysis and tracing tools look really wonderful. Have those been in the
works / maturing for awhile, or is that all new tooling for 1.5?

~~~
jdoliner
I think the tracing tool [0] isn't go specific but rather just a general
tracing tool that's been maturing for a while. The support for outputting
compatible traces is new to 1.5 AFAIK but that would explain how they have
such a nice looking interface already :)

[0] [https://github.com/google/trace-viewer](https://github.com/google/trace-
viewer)

~~~
4ad
The trace _viewer_ is not Go specific, it comes from the chrome browser, but
of course the technology that makes it possible to trace Go is very Go-
specific.

------
tracker1
With go 1.5 able to build to static/dynamic C libraries, I wonder how long it
will be until there is a bridge to be able to easily write binary modules for
Node.js ... Which may seem a bit crazy.

------
ori_b
How does shared object support interact with cross-module inlining?

------
olov
Live stream recording here:
[https://youtu.be/Fx304EfqtMo?t=395](https://youtu.be/Fx304EfqtMo?t=395)

------
frik
Shared library support, thanks!

------
rajeemcariazo
please tell me how to make such slide presentation

~~~
mseepgood
Use Go's "present" tool:
[https://godoc.org/golang.org/x/tools/present](https://godoc.org/golang.org/x/tools/present)

------
nogostill
Still no generics, nor real type inference.

~~~
melling
You created a burn account just to complain about this?

As you know, generics won't appear before 2.0, if ever. It's fine if that's a
nonstarter for you. Perhaps you'll like Rust instead. It needs a big community
too.

~~~
chowells
Why Rust? It doesn't really compete with Go anywhere. Haskell is a much
stronger player in the space of high-level, garbage-collected languages. The
only thing Rust and Haskell really have in common is not willfully ignoring
the last 50 years of programming language design research.

~~~
aplummer
Doesn't it? Why do people seem to compare them all the time...

~~~
learc83
Go gets compared to Rust because go was originally labeled a "systems"
language. But the designers had a different older view of what "systems" meant
than what is commonly used to day. People heard systems and thought they meant
low level/operating system/embedded systems. That is not what Go is good for
because it's garbage collected.

They also planned to attract C++ programmers, but they've basically been
attracting dynamic language programmers instead. Why that was a surprise is
beyond me--I can't imagine that anyone currently using C++ would be OK
switching to a garbage collected language.

Rust on the other hand, is shaping up to be a C++ replacement.

~~~
mcgirr
Yeah, additionally it would be unwise to use Go in embedded systems because it
is so reliant on heap memory for dynamic allocation. In certain situations
where things could fail if an operation takes too long - rocketry and robots -
it would be difficult to tell how long something would take in Go with any
degree of certainty because allocating and freeing memory on the heap is
highly non-deterministic.

~~~
nindalf
This particular link has some info about that situation. GC pauses are
deterministic starting Go1.5. Application code will run for at least 40ms out
of every 50ms. The upper limit for the GC pause is 10ms and its typically
lower.

~~~
mkpankov
It's not "deterministic". It has limits on time consumption of GC defined. But
you still can't tell when, and if, at any given moment you'll have a pause.

