The State of Go

http://talks.golang.org/2015/state-of-go-may.slide#1

by crawshaw • 11 years ago

318 167 11 years ago

talks.golang.org

melling2• 11 years ago

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",
    }

nickysielicki2• 11 years ago

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.

zachberger• 11 years ago

It's in the declaration of the map. Rewriting it over and over is redundant encoding

axaxs• 11 years ago

Much agreed. Call me a masochist, but I prefer extra typing if it means readability, to me. And while subjective, retyping Point{} is much clearer to me than {}. It just looks...wrong.

iokevins• 11 years ago

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

zak_mc_kracken• 11 years ago

I'm puzzled about the asymmetry of the syntax. What's the reason behind

    map[Point]string

as opposed to something more symmetrical?

DrJokepu• 11 years ago

It makes sense if you're used to Go. In Go, in function declarations return types come after the argument list, e.g:

    func doSomething(input string) string { ... }

The go map declaration syntax is analogous to the function declaration syntax: the keyword (map, analogous to the func keyword) followed by the type of the keys in brackets (analogous to the argument type in parentheses) followed by the type of the values (analogous to the return type).

aikah• 11 years ago

makes little sense but since go doesn't have user defined parametric types, it makes no difference.

Now I wish I had 1 million dollars and a better brain to work full time on a proper language that would fix go's issues. What a missed opportunity to create something everybody would be comfortable with. It could have been the biggest language of the next 20 years in webdev, CSP is a great concurrency model. At least it will inspire some people in the future I hope. Rust is cool but doesn't have CSP builtin.

4ad5• 11 years ago

This worked for structs since a very long time, the change makes maps consistent too.

giaour3• 11 years ago

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

vezzy-fnord• 11 years ago

I was surprised too given the Plan 9 culture's rejection of dynamic linking.

However, this will probably deprecate or diminish the RPC and code generation techniques for implementing plugin architectures.

pjmlp11• 11 years ago

Yet Limbo uses it everywhere.

ecnahc515• 11 years ago

One of the major design philosophies was ease of deployment, DLLs generally complicate that process, but for many purposes, they're a necessary tool.

Interop with existing libraries is certainly a worthy enough feature to add to the Go toolchain, and it's an optional feature, so ease of deployment is still a primary concern, but if you need DLLs, this is available.

pcwalton2• 11 years ago

In particular, you've gotta have DLLs if you want to deploy on Android.

chadzawistowski2• 11 years ago

Furthermore, the years they spent where dynamic linking were not allowed incubated the culture -- even though dynamic linking is now allowed, it really will be a special case!

chenzhekl• 11 years ago

This feature may be prepared for building shared libraries for C. After all, Using shared libraries is popular in C world.

giaour3• 11 years ago

It might also make it possible to write Node/PHP/Ruby/Python libraries in Go instead of C++. I've been looking at Rust for that use but the ability to compile Go to a C archive throws in back in the running.

russell_h• 11 years ago

That has generally been true as far as Go packages are concerned, but by default the binaries that Go generates still dynamically link against any C libraries - in particular just about any Go binary will break in the absence of a compatible libc.

I don't know the background on this choice, but I've spoken to a few Go shops that have complained about memory usage when running a bunch of different Go binaries on the same machine, so hopefully this will help there.

NateDad2• 11 years ago

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• 11 years ago

...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/

mappu• 11 years ago

The debian snapshot archive is over 30TB. Some single packages take up to 10 hours to build (although all other packages can be built in parallel if you have enough EC2 credit).

sacado25• 11 years ago

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.

OTOH, it does well with the culture of making a lot of small, specialized executables rather than a single, monolithic application.

acomjean• 11 years ago

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."

dbaupp2• 11 years ago

That goal is referring to latency spikes. GC is usually much less than 20% of the time on average, but it may take, say, 200ms in one go and then run for 2 seconds without another collection. It seems their goal is to ensure there's no large pauses like that, so the 200ms would be spread across the 2 seconds as smaller time slices instead.

microtonal6• 11 years ago

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• 11 years ago

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?

blt• 11 years ago

some GC languages pause garbage collection while calling out to native code. under this scheme it's no problem to call C to do something like multiply matrices or compute hash functions. the problems come when you want the C code to call back into GC code, for example an event loop or a huge computation that wants to report its progress.

it's hard. mixing manual and automatic memory management is tricky.

Kurtz79• 11 years ago

I actually was expecting it to have a greater hit on performance.

After all, a go executable can be 2x - 8x slower than a C one (which is still good enough for many uses).

nkozyra• 11 years ago

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

Tell me more ...

HaseebR7• 11 years ago

https://github.com/golang/mobile

mholt• 11 years ago

`gomobile install` to build an APK and install it on a device. Cool.

nogostill• 11 years ago

Still no generics, nor real type inference.

melling2• 11 years ago

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• 11 years ago

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.

sanderjd• 11 years ago

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• 11 years ago

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

4ad5• 11 years ago

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.

frik2• 11 years ago

Shared library support, thanks!

petesoder• 11 years ago

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

ori_b• 11 years ago

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

rajeemcariazo• 11 years ago

please tell me how to make such slide presentation

mseepgood2• 11 years ago

Use Go's "present" tool: https://godoc.org/golang.org/x/tools/present

rifung• 11 years ago

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

I thought this day would never come.

Yuioup• 11 years ago

I seriously was wondering if Go would ever replace Java on Android because of legal troubles. I'm still wondering.

izacus• 11 years ago

That will happen as soon as Android team decides to scrap all development of Android and rewrite it in Go.

namelezz• 11 years ago

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

microtonal6• 11 years ago

I think the attractiveness is that you can share Go code between applications on different platforms, which is not possible with Swift as long as the compiler and standard library is not open source (or generally available).

kainosnoema• 11 years ago

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.

pjmlp11• 11 years ago

I would never exchange the power of a ML based language with first class support from the OS vendor, by Go.

pjmlp11• 11 years ago

It will not come unless Android team changes their mind.

What the Go team is doing is providing the same level of access that C and C++ enjoy.

Which means that outside developing games or writing pure business logic, is all about JNI fun.

fit2rule2• 11 years ago

I've been using Go 1.4 for iOS development and it works fine. This is just mainstream'ing the support for iOS, which is needed now because things seem to be quite settled.

In fact, I really like using Go on iOS - the ease with which it can be done was astonishing!

auto• 11 years ago

As a professional iOS dev and a golang tickerer, I've heard nothing about this, but I'm curious; any projects you can point me at?

amelius• 11 years ago

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.

pcwalton2• 11 years ago

Yes, if it's referring to Boehm's binary-trees benchmark (as seen on the benchmarks game, for example), it is explicitly designed to be a benchmark of garbage collection. I believe the Boehm GC was tuned using it.

masklinn• 11 years ago

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.

enneff4• 11 years ago

Of course, as with whenever you change something fundamental like this, some programs will get slower while others get faster. That's the nature of trade offs.

It's not really suspect. The benchmarks reflect execution speed. The new GC trades a little raw throughput for lower GC latency. So you would expect a GC-heavy benchmark to show the greatest speed loss. What matters for go users, though, is the behaviour of real programs. Real programs benefit from the reduced latency of the GC and other compiler optimisations we have made since 1.4. The outcome, in our measurements, is roughly equivalent performance for most programs but with significantly shorter GC pauses.

sergiotapia• 11 years ago

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?

barsonme• 11 years ago

Go's SF meetup just finished.

https://news.ycombinator.com/item?id=9609427

castell2• 11 years ago

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.

seanmcdirmid3• 11 years ago

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

est2• 11 years ago

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

https://www.percona.com/doc/percona-server/5.6/installation/...

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.

favadi• 11 years ago

If you don't have experience with packaging, https://github.com/jordansissel/fpm is probably your best bet. And it is super easy to use.

moondowner• 11 years ago

Try this https://github.com/geosoft1/tools (related blog post: http://www.webupd8.org/2014/09/easily-install-latest-golang-...)

insertnickname5• 11 years ago

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

est2• 11 years ago

extract it somewhere and set some environment variables

That's exactly the problems package would solve, well, plus easy update capabilities.

rattray• 11 years ago

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?

jerf• 11 years ago

For debian-esque, I use https://github.com/niemeyer/godeb .

pokstad• 11 years ago

You can download and install the binaries on Ubuntu: http://pokstad.com/2015/02/03/installing-go-binaries-on-ubun...

tracker13• 11 years ago

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.

advanderveer• 11 years ago

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

dvirsky2• 11 years ago

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• 11 years ago

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.

dvirsky2• 11 years ago

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

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

olov• 11 years ago

Live stream recording here: https://youtu.be/Fx304EfqtMo?t=395

lake993• 11 years ago

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?

marktangotango• 11 years ago

Go uses ports of the Plan 9 system libraries extensively, so Plan 9 support is probably a freebie, or implicit.

bshimmin2• 11 years ago

Rob Pike, maybe?

bshimmin2• 11 years ago

I take that back: http://rob.pike.usesthis.com/

rsc2• 11 years ago

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

lake993• 11 years ago

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.

ubercore2• 11 years ago

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• 11 years ago

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.

ubercore2• 11 years ago

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!

kzvezdarov• 11 years ago

There are some good dependency managers out there. I personally like gb: http://getgb.io/, but there is GoDep and GPM as well (which are more similar to Rust's Cargo in the way they work).

fitzwatermellow• 11 years ago

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

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

GopherCon - Denver, Colorado - July 7-10 http://www.gophercon.com/

GolangUK - London, UK - August 21 http://www.golanguk.com/

GothamGo - New York, NY - October 2 http://gothamgo.com/

dotGo - Paris, France - November 9 http://www.dotgo.eu/

The State of Go

Related Stories