<story><title>The State of Go: Where we are in February 2016</title><url>https://talks.golang.org/2016/state-of-go.slide#1</url></story><parent_chain><item><author>kasey_junk</author><text>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&amp;#x27;d say it was &lt;i&gt;more&lt;/i&gt; stable than Go.</text></item><item><author>schmichael</author><text>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:&lt;p&gt;&amp;gt; Changes to the language: None&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;talks.golang.org&amp;#x2F;2016&amp;#x2F;state-of-go.slide#6&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;talks.golang.org&amp;#x2F;2016&amp;#x2F;state-of-go.slide#6&lt;/a&gt;&lt;p&gt;We generally get our entire stack upgraded to the latest release within 1-3 months with little effort. It wouldn&amp;#x27;t be much more work to be ready to upgrade on release day, but we haven&amp;#x27;t found a reason to worry about it.&lt;p&gt;Go is such a breath of fresh air compared to past Java and Python jobs where production was usually at least a major release version behind the latest and there was extra effort spent getting everyone using the same implementation (Oracle Java v OpenJDK or Ubuntu&amp;#x27;s Python v CentOS&amp;#x27;s -- there are differences!).&lt;p&gt;Conservative releases aren&amp;#x27;t a must-have for a language, but I do appreciate having one less operational headache to consider.</text></item></parent_chain><comment><author>colin_mccabe</author><text>While I agree that Java has been one of the most stable and backwards-compatible languages out there (especially compared to things like Scala, which regularly breaks source and binary backwards compat), there are still rough edges.  I am not the original poster, but I can speak for why JVM deployments take time on Hadoop (which I work on).&lt;p&gt;* In order to upgrade the JVM, &lt;i&gt;all&lt;/i&gt; the software you run has to work with the new JVM.  If there&amp;#x27;s even one minor library that doesn&amp;#x27;t work or is suboptimal, you can&amp;#x27;t cut over.  This is not an issue with Go because everything is compiled to an x86_64 binary there, whereas in Java everything is a jar file that must be run under (almost always a single) JVM.&lt;p&gt;* During a JVM version change, often Oracle removes or modifies non-public APIs that you need to achieve acceptable performance.  For example, there is still no public way to free a DirectByteBuffer or create a FileChannel from a FileDescriptor, so you have to use the non-public APIs.  Go almost never has this sort of problem since they tend to provide public APIs for everything you need, including platform-specific things.&lt;p&gt;* We run really big JVM heaps (&amp;gt;100 GB), and so minor changes in the GC behavior or default settings can cause major issues.  For example, JDK8 changed the defaults for many GC tunables.  It takes weeks of work at least for us to validate that there are no significant regressions.  This is an issue that I would expect Go to have as well since they are changing the GC.&lt;p&gt;* Enterprise customers are extremely risk-averse, and they&amp;#x27;re not enthusiastic about deploying a new JVM.  Operationally, they don&amp;#x27;t see any upside, only downsides.  Of course JVM upgrades have to happen eventually, but they usually happen when new software is rolling out as well.  Oracle&amp;#x27;s decision to stop shipping security updates for older JVM versions has &amp;quot;helped&amp;quot; in a sense by making the issue seem more urgent.&lt;p&gt;* Open source projects don&amp;#x27;t like dropping support for users running older software.  There is usually someone around to argue against dropping support for anything that rolled out within the last 5 years.</text></comment>
<story><title>The State of Go: Where we are in February 2016</title><url>https://talks.golang.org/2016/state-of-go.slide#1</url></story><parent_chain><item><author>kasey_junk</author><text>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&amp;#x27;d say it was &lt;i&gt;more&lt;/i&gt; stable than Go.</text></item><item><author>schmichael</author><text>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:&lt;p&gt;&amp;gt; Changes to the language: None&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;talks.golang.org&amp;#x2F;2016&amp;#x2F;state-of-go.slide#6&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;talks.golang.org&amp;#x2F;2016&amp;#x2F;state-of-go.slide#6&lt;/a&gt;&lt;p&gt;We generally get our entire stack upgraded to the latest release within 1-3 months with little effort. It wouldn&amp;#x27;t be much more work to be ready to upgrade on release day, but we haven&amp;#x27;t found a reason to worry about it.&lt;p&gt;Go is such a breath of fresh air compared to past Java and Python jobs where production was usually at least a major release version behind the latest and there was extra effort spent getting everyone using the same implementation (Oracle Java v OpenJDK or Ubuntu&amp;#x27;s Python v CentOS&amp;#x27;s -- there are differences!).&lt;p&gt;Conservative releases aren&amp;#x27;t a must-have for a language, but I do appreciate having one less operational headache to consider.</text></item></parent_chain><comment><author>kyrra</author><text>Issues I&amp;#x27;ve seen with JDK upgrades over the years (that I can think of right now):&lt;p&gt;* when &amp;quot;enum&amp;quot; keyword was added, if you had a variable named enum you had to rename it.&lt;p&gt;* If you use any of the sun.* packages you always ask for trouble on major upgrades.&lt;p&gt;* GC changes over the years can change how your program runs (latency changes, OOM issues).  This probably applies to Go as well.</text></comment>