Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of Go: Where we are in February 2016

talks.golang.org

Post reply on HN
Print view View original

101–110 of 224 posts

Re: The State of Go: Where we are in February 2016

#101

Post by kyrra »

kasey_junk wrote: post #89
schmichael wrote: post #79

At work (Lytics) 100% of our backend code has been in Go since the beginning over 3 years ago, so slide #6 highlights one of the most things with nearly every Go release: > Changes to the language: None https://talks.golang.org/2016/state-of-go.slide#6 We generally get our entire stack upgraded to the latest release within 1-3 months with little effort. It wouldn't be much more work to be ready to upgrade on release…

Can you speak to why you were behind latest on the JVM? I can think of less than a handful of breaking changes over the last 15 years. I'd say it was more stable than Go.

Issues I've seen with JDK upgrades over the years (that I can think of right now):

* when "enum" keyword was added, if you had a variable named enum you had to rename it.

* If you use any of the sun.* packages you always ask for trouble on major upgrades.

* GC changes over the years can change how your program runs (latency changes, OOM issues). This probably applies to Go as well.

Re: The State of Go: Where we are in February 2016

#102

Post by kasey_junk »

voidlogic wrote: post #97
kasey_junk wrote: post #92

Earlier quoted context omitted.

But not using a pool is not the alternative we are talking about. Rather its hand rolling your own every time. Something the JVM doesn't require.

>Rather its hand rolling your own every time. So your had rolled one will not have the typing overhead we are discussing, but it will have 2 much worse issues. 1. sync.Pool's have thread local storage, something your own pools will not have. 2. sync.Pool's are GC aware; meaning if the allocator is having trouble it can drain "free" pool objects to gain memory. Your custom pool will not have this integration. I have a…

I think you are missing my point. So I'll restate it. sync.Pool does not help with GC issues compared to the JVM because the JVM also has object pools, further those object pools are actually better for the low latency case because the language does not force them to make a choice between dynamic type checks and specific use abstractions.

[edit] As pcwalton points out. My whole argument is actually null and void due to type erasure...doh.

Re: The State of Go: Where we are in February 2016

#103

Post by pcwalton »

kasey_junk wrote: post #102
voidlogic wrote: post #97

Earlier quoted context omitted.

>Rather its hand rolling your own every time. So your had rolled one will not have the typing overhead we are discussing, but it will have 2 much worse issues. 1. sync.Pool's have thread local storage, something your own pools will not have. 2. sync.Pool's are GC aware; meaning if the allocator is having trouble it can drain "free" pool objects to gain memory. Your custom pool will not have this integration. I have a…

I think you are missing my point. So I'll restate it. sync.Pool does not help with GC issues compared to the JVM because the JVM also has object pools, further those object pools are actually better for the low latency case because the language does not force them to make a choice between dynamic type checks and specific use abstractions. [edit] As pcwalton points out. My whole argument is actually null and void due…

To be fair, though, aren't generics on the JVM type-erased? So you're going to have a type assertion at the JIT level either way.

Re: The State of Go: Where we are in February 2016

#104

Post by schmichael »

kasey_junk wrote: post #89
schmichael wrote: post #79

At work (Lytics) 100% of our backend code has been in Go since the beginning over 3 years ago, so slide #6 highlights one of the most things with nearly every Go release: > Changes to the language: None https://talks.golang.org/2016/state-of-go.slide#6 We generally get our entire stack upgraded to the latest release within 1-3 months with little effort. It wouldn't be much more work to be ready to upgrade on release…

Can you speak to why you were behind latest on the JVM? I can think of less than a handful of breaking changes over the last 15 years. I'd say it was more stable than Go.

Hm, it's been over 2 years, so I don't remember many details. I do remember having a couple projects (Kafka, maybe more?) using Scala which required specific JDK versions. Also some databases would recommend certain JDK versions.

So that means you either run different JDKs for different services or you stick with the lowest common denominator.

Re: The State of Go: Where we are in February 2016

#105

Post by schmichael »

kyrra wrote: post #101
kasey_junk wrote: post #89

Earlier quoted context omitted.

Can you speak to why you were behind latest on the JVM? I can think of less than a handful of breaking changes over the last 15 years. I'd say it was more stable than Go.

Issues I've seen with JDK upgrades over the years (that I can think of right now): * when "enum" keyword was added, if you had a variable named enum you had to rename it. * If you use any of the sun.* packages you always ask for trouble on major upgrades. * GC changes over the years can change how your program runs (latency changes, OOM issues). This probably applies to Go as well.

GC changes is a big one in the JVM, but not so much in Go (so far) as Go offers basically no GC tunables.

So while your awesome CMS tweaks from JDK7 become worthless once you switch to G1 on JDK8, with Go all you can do to optimize the GC is to create less garbage to begin with.

Not trying to say one approach is better than the other: Go's approach is operationally simpler but far less sophisticated than the JVM's.

Re: The State of Go: Where we are in February 2016

#106

Post by kasey_junk »

schmichael wrote: post #105
kyrra wrote: post #101

Earlier quoted context omitted.

Issues I've seen with JDK upgrades over the years (that I can think of right now): * when "enum" keyword was added, if you had a variable named enum you had to rename it. * If you use any of the sun.* packages you always ask for trouble on major upgrades. * GC changes over the years can change how your program runs (latency changes, OOM issues). This probably applies to Go as well.

GC changes is a big one in the JVM, but not so much in Go (so far) as Go offers basically no GC tunables. So while your awesome CMS tweaks from JDK7 become worthless once you switch to G1 on JDK8, with Go all you can do to optimize the GC is to create less garbage to begin with. Not trying to say one approach is better than the other: Go's approach is operationally simpler but far less sophisticated than the JVM's.

I don't disagree with the simplicity argument, but as it relates to backwards compatibility, we've already had 1 major change to the GC that caused performance differences that needed to be investigated. With Java typically they'd have left the option to use the old GC (again which increases operational complexity) so that in that case the backwards compatibility argument seems to favor Java.

Re: The State of Go: Where we are in February 2016

#107

Post by daakus »

kasey_junk wrote: post #89
schmichael wrote: post #79

At work (Lytics) 100% of our backend code has been in Go since the beginning over 3 years ago, so slide #6 highlights one of the most things with nearly every Go release: > Changes to the language: None https://talks.golang.org/2016/state-of-go.slide#6 We generally get our entire stack upgraded to the latest release within 1-3 months with little effort. It wouldn't be much more work to be ready to upgrade on release…

Can you speak to why you were behind latest on the JVM? I can think of less than a handful of breaking changes over the last 15 years. I'd say it was more stable than Go.

One aspect is that upgrading Go only requires upgrading it on the build infrastructure rather than a deployment of a new JVM. The "next build" will simply be a binary built with a new compiler version.

Re: The State of Go: Where we are in February 2016

#108

Post by geodel »

pcwalton wrote: post #94
leaveyou wrote: post #56

Earlier quoted context omitted.

From this "work being done in the OpenJDK project for a GC that can collect > 100GB heaps in https://talks.golang.org/2016/state-of-go.slide#37 https://github.com/golang/proposal/blob/master/design/12800-...

Latency isn't the only concern; you also have to look at throughput. The JVM's GC has been carefully tuned to strike a balance here. In particular, Go's GC is not yet generational from the talks I've seen, which is a large throughput loss compared to the GC of the JVM.

If it is carefully tuned why it needs such a big GC tuning guide and 100s of JVM flags to tune runtime. Any Java product of consequence comes with custom GC settings meaning they do not find default ones suitable.

https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gc...

Re: The State of Go: Where we are in February 2016

#109

Post by pcwalton »

geodel wrote: post #108
pcwalton wrote: post #94

Earlier quoted context omitted.

Latency isn't the only concern; you also have to look at throughput. The JVM's GC has been carefully tuned to strike a balance here. In particular, Go's GC is not yet generational from the talks I've seen, which is a large throughput loss compared to the GC of the JVM.

If it is carefully tuned why it needs such a big GC tuning guide and 100s of JVM flags to tune runtime. Any Java product of consequence comes with custom GC settings meaning they do not find default ones suitable. https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gc...

Because the JVM developers had customers who asked for the ability to tune the GC for their particular application.

Go will receive those feature requests too. The Go developers may not be as willing to provide so many knobs (which is a position I'm entirely sympathetic to, don't get me wrong). But the settings always exist, regardless of whether Google hammers in values for them or leaves them adjustable. GC is full of tradeoffs; they're fundamental to the problem.

Re: The State of Go: Where we are in February 2016

#110

Post by pjmlp »

kyrra wrote: post #101
kasey_junk wrote: post #89

Earlier quoted context omitted.

Can you speak to why you were behind latest on the JVM? I can think of less than a handful of breaking changes over the last 15 years. I'd say it was more stable than Go.

Issues I've seen with JDK upgrades over the years (that I can think of right now): * when "enum" keyword was added, if you had a variable named enum you had to rename it. * If you use any of the sun.* packages you always ask for trouble on major upgrades. * GC changes over the years can change how your program runs (latency changes, OOM issues). This probably applies to Go as well.

From that list I would only consider the first one.

Using sun.* packages or relying in GC behaviour is a way to make Java code not portable across certified JVMs.

For example I took part in some projects that were married to IBM JVM, because they were relying on its features.

Post reply on HN