7 ms·

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 G

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 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 day, but we haven't found a reason to worry about it. 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's Python v CentOS's -- there are differences!). Conservative releases aren't a must-have for a language, but I do appreciate having one less operational headache to consider.

jvehent 11y ago
This is my experience as well. The only thing that somewhat breaks between Go project is vendoring (or lack thereof). But in comparison to the pain of supporting python applications that must run on everything from 2.6.6 to 3.5, Go is a walk in the park.
- Cyph0n 11y ago
  Python is entirely different; the two languages cannot be compared with regards to backwards compatibility. Python has been around since the early 90s, while Go was conceived very recently. Sooner or later, the quirks that resulted from designing the language so long ago had to be addressed, and that's why there's Python 3. The same can be seen in Java and Ruby. Once Go is used actively for ~9 years (Python 2.0 to 3.0) and suffers no changes that break backwards compatibility, we can compare it with Python.
kasey_junk 11y ago
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.
- kyrra 11y ago
  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.
  - schmichael 11y ago
    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.
    - kasey_junk 11y ago
      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.
    - voidlogic 11y ago
      >as Go offers basically no GC tunables. This isn't actually true, Go has a single tunable: "GOGC" https://golang.org/pkg/runtime/ https://golang.org/pkg/runtime/
      - schmichael 11y ago
        I consider that "basically no" compared to Java's daunting array of options.
  - 11y ago
stcredzero 11y ago
> Conservative releases aren't a must-have for a language, but I do appreciate having one less operational headache to consider. Considering the nature of the work, the programming field seems to be particularly rife with "common wisdom" that's not supported by data. This especially goes towards language design. (In the Chris Granger talk that was recently posted here, he noted that programmers who said they "never" used the mouse, only the keyboard, actually used the mouse 50% of the time.) The reality of the programming field is that it's "almost a field" [1] -- struggling just as much with empiricism as alchemy was before it evolved into the science of chemistry. Language features definitely suffer from the irrationality of the almost-a-field of programming. Golang seems to be led by good empiricists who are targeting a specific set of use cases for programming in the large. [1] - https://news.ycombinator.com/item?id=9812487

jvehent 11y ago

This is my experience as well. The only thing that somewhat breaks between Go project is vendoring (or lack thereof). But in comparison to the pain of supporting python applications that must run on everything from 2.6.6 to 3.5, Go is a walk in the park.

Cyph0n 11y ago
Python is entirely different; the two languages cannot be compared with regards to backwards compatibility. Python has been around since the early 90s, while Go was conceived very recently. Sooner or later, the quirks that resulted from designing the language so long ago had to be addressed, and that's why there's Python 3. The same can be seen in Java and Ruby. Once Go is used actively for ~9 years (Python 2.0 to 3.0) and suffers no changes that break backwards compatibility, we can compare it with Python.

kasey_junk 11y ago

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.

kyrra 11y ago
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.
- schmichael 11y ago
  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.
  - kasey_junk 11y ago
    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.
  - voidlogic 11y ago
    >as Go offers basically no GC tunables. This isn't actually true, Go has a single tunable: "GOGC" https://golang.org/pkg/runtime/ https://golang.org/pkg/runtime/
    - schmichael 11y ago
      I consider that "basically no" compared to Java's daunting array of options.
- 11y ago

stcredzero 11y ago

> Conservative releases aren't a must-have for a language, but I do appreciate having one less operational headache to consider. Considering the nature of the work, the programming field seems to be particularly rife with "common wisdom" that's not supported by data. This especially goes towards language design. (In the Chris Granger talk that was recently posted here, he noted that programmers who said they "never" used the mouse, only the keyboard, actually used the mouse 50% of the time.) The reality of the programming field is that it's "almost a field" [1] -- struggling just as much with empiricism as alchemy was before it evolved into the science of chemistry. Language features definitely suffer from the irrationality of the almost-a-field of programming. Golang seems to be led by good empiricists who are targeting a specific set of use cases for programming in the large. [1] - https://news.ycombinator.com/item?id=9812487