code review 146780043: go.talks/2014/droidcon: slides

go.talks/2014/droidcon: slides

[Sameer Ajmani, 2014-09-17 21:00:02]

LGTM

https://codereview.appspot.com/146780043/diff/20001/2014/droidcon.slide
File 2014/droidcon.slide (right):

https://codereview.appspot.com/146780043/diff/20001/2014/droidcon.slide#newco...
2014/droidcon.slide:81: 1. Write libraries in Go, use them from Java apps. Or
Objective-C apps.
Or Swift...

https://codereview.appspot.com/146780043/diff/20001/2014/droidcon.slide#newco...
2014/droidcon.slide:155: With enough programmer hours, there will be a few
percent more performance possible in C.
I cannot parse the end of this sentence.

[cmang, 2014-09-17 21:05:34]

https://codereview.appspot.com/146780043/diff/20001/2014/droidcon.slide
File 2014/droidcon.slide (right):

https://codereview.appspot.com/146780043/diff/20001/2014/droidcon.slide#newco...
2014/droidcon.slide:147: The general guiding principle is, if you can do it with
the Android NDK, you can do it from Go. Importantly, it has to be possible to
create an interface that does the right thing on both Android and iOS, so Go may
lag the NDK for a while.
I think this is worded weirdly. Is it supposed to be "Go may lag on the NDK for
a while," meaning the full set of NDK features will not implemented for a while,
or is it supposed to mean that gobind will in some way slow down the C/C++ NDK?

[bcmills, 2014-09-17 21:36:47]

LGTM.

Overall quite good - nice focus on the practical design decisions and the
strengths of Go that make it suitable to the task.

https://codereview.appspot.com/146780043/diff/20001/2014/droidcon.slide
File 2014/droidcon.slide (right):

https://codereview.appspot.com/146780043/diff/20001/2014/droidcon.slide#newco...
2014/droidcon.slide:153: It is unlikely that high-budget 3D engines will move to
Go. The garbage collector story is much better in Go than it is in Java (because
you have better control over when you allocate), but there is still a GC.
Replace the second sentence.  The Go collector still has some latency issues
compared to, say, the Java CMS collector, so claiming the overall "story is much
better" may come across as disingenuous,

Instead, focus on what Go actually delivers.  Perhaps:

Go has a garbage collector, but it provides more control (as compared to Java)
over when allocation occurs.
It is possible to write event loops that generate little to no garbage in the
steady state.

https://codereview.appspot.com/146780043/diff/20001/2014/droidcon.slide#newco...
2014/droidcon.slide:191: - pointers
Maybe also mention unboxed slices and maps?  They're more than just garbage -
also space and (importantly!) cache.

[adg, 2014-09-17 22:27:16]

LGTM

https://codereview.appspot.com/146780043/diff/20001/2014/droidcon.slide
File 2014/droidcon.slide (right):

https://codereview.appspot.com/146780043/diff/20001/2014/droidcon.slide#newco...
2014/droidcon.slide:20: slow builds, slow programs, and too much complexity.
slow programs? c++ and java are pretty fast
"awkward ecosystem" maybe?

[crawshaw, 2014-09-18 13:02:16]

Thanks,

https://codereview.appspot.com/146780043/diff/20001/2014/droidcon.slide
File 2014/droidcon.slide (right):

https://codereview.appspot.com/146780043/diff/20001/2014/droidcon.slide#newco...
2014/droidcon.slide:20: slow builds, slow programs, and too much complexity.
On 2014/09/17 22:27:15, adg wrote:
> slow programs? c++ and java are pretty fast
> "awkward ecosystem" maybe?

Done. (I've been thinking too much about Android Java recently.)

https://codereview.appspot.com/146780043/diff/20001/2014/droidcon.slide#newco...
2014/droidcon.slide:81: 1. Write libraries in Go, use them from Java apps. Or
Objective-C apps.
On 2014/09/17 21:00:02, Sameer Ajmani wrote:
> Or Swift...

I was avoiding mentioning it because I didn't want to place Go as Android's
answer to Swift (it's not). But I believe I have enough supporting slides before
this that I don't need to worry about that. Done.

https://codereview.appspot.com/146780043/diff/20001/2014/droidcon.slide#newco...
2014/droidcon.slide:147: The general guiding principle is, if you can do it with
the Android NDK, you can do it from Go. Importantly, it has to be possible to
create an interface that does the right thing on both Android and iOS, so Go may
lag the NDK for a while.
On 2014/09/17 21:05:34, cmang wrote:
> I think this is worded weirdly. Is it supposed to be "Go may lag on the NDK
for
> a while," meaning the full set of NDK features will not implemented for a
while,
> or is it supposed to mean that gobind will in some way slow down the C/C++
NDK?

Done.

https://codereview.appspot.com/146780043/diff/20001/2014/droidcon.slide#newco...
2014/droidcon.slide:153: It is unlikely that high-budget 3D engines will move to
Go. The garbage collector story is much better in Go than it is in Java (because
you have better control over when you allocate), but there is still a GC.
On 2014/09/17 21:36:47, bcmills wrote:
> Replace the second sentence.  The Go collector still has some latency issues
> compared to, say, the Java CMS collector, so claiming the overall "story is
much
> better" may come across as disingenuous,
> 
> Instead, focus on what Go actually delivers.  Perhaps:
> 
> Go has a garbage collector, but it provides more control (as compared to Java)
> over when allocation occurs.
> It is possible to write event loops that generate little to no garbage in the
> steady state.

There is no CMS collector on Android. (In fact it's even rarely used in Java
servers, we have some great internal docs on this.) The current Dalvik collector
needs to do a double pause to fully collect, the result of which is serious
problems achieving consistent framerates in any kind of program. There's a
Google IO talk on ART with details.

The coming ART collector is better, but it's not anything like CMS. It does some
parallel work, on roughly the same level as Go's current GC. Without careful
comparison, I would probably claim the two are equivalent.

However, the Go GC ships in your binary. The Android GC ships with the OS, and
Android has a long fat tail of old installs. It will be years before you can
rely on the Android GC to deliver consistent results. You can rely on the Go one
today, and roll out a new version to everyone every six months.

In general I say to people who ask: Java has a better GC latency story than Go
today, because for a large amount of money you can purchase Azul's (effectively)
pauseless collector. You can't on Android.

(This slide is a cue for me to explain that in the talk.)

https://codereview.appspot.com/146780043/diff/20001/2014/droidcon.slide#newco...
2014/droidcon.slide:155: With enough programmer hours, there will be a few
percent more performance possible in C.
On 2014/09/17 21:00:02, Sameer Ajmani wrote:
> I cannot parse the end of this sentence.

Done.

https://codereview.appspot.com/146780043/diff/20001/2014/droidcon.slide#newco...
2014/droidcon.slide:191: - pointers
On 2014/09/17 21:36:47, bcmills wrote:
> Maybe also mention unboxed slices and maps?  They're more than just garbage -
> also space and (importantly!) cache.

Done.

[bcmills, 2014-09-18 15:18:24]

https://codereview.appspot.com/146780043/diff/20001/2014/droidcon.slide
File 2014/droidcon.slide (right):

https://codereview.appspot.com/146780043/diff/20001/2014/droidcon.slide#newco...
2014/droidcon.slide:153: It is unlikely that high-budget 3D engines will move to
Go. The garbage collector story is much better in Go than it is in Java (because
you have better control over when you allocate), but there is still a GC.
On 2014/09/18 13:02:15, crawshaw wrote:
> On 2014/09/17 21:36:47, bcmills wrote:
> > Replace the second sentence.  The Go collector still has some latency issues
> > compared to, say, the Java CMS collector, so claiming the overall "story is
> much
> > better" may come across as disingenuous,
> > 
> > Instead, focus on what Go actually delivers.  Perhaps:
> > 
> > Go has a garbage collector, but it provides more control (as compared to
Java)
> > over when allocation occurs.
> > It is possible to write event loops that generate little to no garbage in
the
> > steady state.
> 
> There is no CMS collector on Android. (In fact it's even rarely used in Java
> servers, we have some great internal docs on this.) The current Dalvik
collector
> needs to do a double pause to fully collect, the result of which is serious
> problems achieving consistent framerates in any kind of program. There's a
> Google IO talk on ART with details.
> 
> The coming ART collector is better, but it's not anything like CMS. It does
some
> parallel work, on roughly the same level as Go's current GC. Without careful
> comparison, I would probably claim the two are equivalent.
> 
> However, the Go GC ships in your binary. The Android GC ships with the OS, and
> Android has a long fat tail of old installs. It will be years before you can
> rely on the Android GC to deliver consistent results. You can rely on the Go
one
> today, and roll out a new version to everyone every six months.
> 
> In general I say to people who ask: Java has a better GC latency story than Go
> today, because for a large amount of money you can purchase Azul's
(effectively)
> pauseless collector. You can't on Android.
> 
> (This slide is a cue for me to explain that in the talk.)

Ah, that makes sense!  But you may want to add an adjective or two to cue that
for folks reading the slides out of context after the fact (because there will
probably be many of them).

Perhaps a smaller edit: s/story is/story on Android is/

[crawshaw, 2014-09-20 19:28:31]

Thanks for the reviews.

https://codereview.appspot.com/146780043/diff/20001/2014/droidcon.slide
File 2014/droidcon.slide (right):

https://codereview.appspot.com/146780043/diff/20001/2014/droidcon.slide#newco...
2014/droidcon.slide:153: It is unlikely that high-budget 3D engines will move to
Go. The garbage collector story is much better in Go than it is in Java (because
you have better control over when you allocate), but there is still a GC.
On 2014/09/18 15:18:23, bcmills wrote:
> On 2014/09/18 13:02:15, crawshaw wrote:
> > On 2014/09/17 21:36:47, bcmills wrote:
> > > Replace the second sentence.  The Go collector still has some latency
issues
> > > compared to, say, the Java CMS collector, so claiming the overall "story
is
> > much
> > > better" may come across as disingenuous,
> > > 
> > > Instead, focus on what Go actually delivers.  Perhaps:
> > > 
> > > Go has a garbage collector, but it provides more control (as compared to
> Java)
> > > over when allocation occurs.
> > > It is possible to write event loops that generate little to no garbage in
> the
> > > steady state.
> > 
> > There is no CMS collector on Android. (In fact it's even rarely used in Java
> > servers, we have some great internal docs on this.) The current Dalvik
> collector
> > needs to do a double pause to fully collect, the result of which is serious
> > problems achieving consistent framerates in any kind of program. There's a
> > Google IO talk on ART with details.
> > 
> > The coming ART collector is better, but it's not anything like CMS. It does
> some
> > parallel work, on roughly the same level as Go's current GC. Without careful
> > comparison, I would probably claim the two are equivalent.
> > 
> > However, the Go GC ships in your binary. The Android GC ships with the OS,
and
> > Android has a long fat tail of old installs. It will be years before you can
> > rely on the Android GC to deliver consistent results. You can rely on the Go
> one
> > today, and roll out a new version to everyone every six months.
> > 
> > In general I say to people who ask: Java has a better GC latency story than
Go
> > today, because for a large amount of money you can purchase Azul's
> (effectively)
> > pauseless collector. You can't on Android.
> > 
> > (This slide is a cue for me to explain that in the talk.)
> 
> Ah, that makes sense!  But you may want to add an adjective or two to cue that
> for folks reading the slides out of context after the fact (because there will
> probably be many of them).
> 
> Perhaps a smaller edit: s/story is/story on Android is/

Done (and shortened).

[crawshaw, 2014-09-20 19:28:44]

Hello sameer@golang.org, cmang@golang.org, bcmills@google.com, adg@golang.org
(cc: golang-codereviews@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go.talks

[crawshaw, 2014-09-20 19:28:56]

*** Submitted as
https://code.google.com/p/go/source/detail?r=6657bf4f0413&repo=talks ***

go.talks/2014/droidcon: slides

LGTM=sameer, bcmills, adg
R=sameer, cmang, bcmills, adg
CC=golang-codereviews
https://codereview.appspot.com/146780043

[jscrockett01, 2014-09-22 16:40:03]

Typo

https://codereview.appspot.com/146780043/diff/90001/2014/droidcon.slide
File 2014/droidcon.slide (right):

https://codereview.appspot.com/146780043/diff/90001/2014/droidcon.slide#newco...
2014/droidcon.slide:128: Go's simplicity makes langauge bindings simple.
language

[crawshaw, 2014-09-22 20:22:48]

https://codereview.appspot.com/146780043/diff/90001/2014/droidcon.slide
File 2014/droidcon.slide (right):

https://codereview.appspot.com/146780043/diff/90001/2014/droidcon.slide#newco...
2014/droidcon.slide:128: Go's simplicity makes langauge bindings simple.
On 2014/09/22 16:40:03, jscrockett01 wrote:
> language

Thanks, fixed in https://codereview.appspot.com/146110043