5 ms·

I've been testing out Go for a while now and outside of deployment, the CPU performance and GC tuning that has come with new versions has been a really, really

I've been testing out Go for a while now and outside of deployment, the CPU performance and GC tuning that has come with new versions has been a really, really great perk over time. No code change, no breakage, just constant free performance.

iends 11y ago
This is one of the reasons I'm looking forward to 1.7 and new SSA (which was cut from 1.6). (see branch dev.ssa and the proposal here: https://docs.google.com/document/d/1szwabPJJc4J-igUZU4ZKprOrNRNJug2JPD8OYi3i1K0/edit#heading=h.ywtmh4qacfis https://docs.google.com/document/d/1szwabPJJc4J-igUZU4ZKprOr...). It should give a nice speed increase and binary size decrease in your programs for free!
thewhitetulip 11y ago
We can see the way Go solves this problem without breaking your code, a way not taken these days where not so well designed solutions break when we have to upgrade. Python 2 and python 3, angular 1 and angular 2. I guess this is the difference between a pet project gone wild and a well thought and well designed programming language designed to make the process of building applications faster and better!
- jzelinskie 11y ago
  You are conflating major and minor versions of software. Python 2 & 3 and Angular 1 & 2 are major versions that have forward declared breaking changes. If/When Go 2 is released, it will contain language breaking changes.
- cryptos 11y ago
  One could see it from the other side: code sticks to its design weaknesses (at least for now).
- sriram_malhar 11y ago
  Go is too young, and has extremely small adoption compared to Python, C, C++, Java. When a language has been around for so long that entire idioms have changed (functional in, object out, reactive in, iteration out etc.), the usage landscape has changed (from desktop scripts up to cloud-scale and down to mobile-app scale), it is natural for the language to have to adapt. The hope is that Go will have enough adoption to require breaking changes!

iends 11y ago

This is one of the reasons I'm looking forward to 1.7 and new SSA (which was cut from 1.6). (see branch dev.ssa and the proposal here: https://docs.google.com/document/d/1szwabPJJc4J-igUZU4ZKprOrNRNJug2JPD8OYi3i1K0/edit#heading=h.ywtmh4qacfis https://docs.google.com/document/d/1szwabPJJc4J-igUZU4ZKprOr...). It should give a nice speed increase and binary size decrease in your programs for free!

thewhitetulip 11y ago

We can see the way Go solves this problem without breaking your code, a way not taken these days where not so well designed solutions break when we have to upgrade. Python 2 and python 3, angular 1 and angular 2. I guess this is the difference between a pet project gone wild and a well thought and well designed programming language designed to make the process of building applications faster and better!

jzelinskie 11y ago
You are conflating major and minor versions of software. Python 2 & 3 and Angular 1 & 2 are major versions that have forward declared breaking changes. If/When Go 2 is released, it will contain language breaking changes.
cryptos 11y ago
One could see it from the other side: code sticks to its design weaknesses (at least for now).
sriram_malhar 11y ago
Go is too young, and has extremely small adoption compared to Python, C, C++, Java. When a language has been around for so long that entire idioms have changed (functional in, object out, reactive in, iteration out etc.), the usage landscape has changed (from desktop scripts up to cloud-scale and down to mobile-app scale), it is natural for the language to have to adapt. The hope is that Go will have enough adoption to require breaking changes!