4 ms·

Go is also moving very fast and they often make backwards-incompatible changes to the libraries (and sometimes the core language) but upgrading code can be done

by jbarham 15y ago

Go is also moving very fast and they often make backwards-incompatible changes to the libraries (and sometimes the core language) but upgrading code can be done automatically 95% of the time using gofix, which programmatically rewrites code to conform to the latest language and library updates. http://blog.golang.org/2011/04/introducing-gofix.html http://blog.golang.org/2011/04/introducing-gofix.html http://golang.org/cmd/gofix/ http://golang.org/cmd/gofix/

angelbob 15y ago
Wow. So it just rewrites it to the latest version, with (according to what you just said) about 95% accuracy? Does that make other people feel queasy, or just me? Like, that feels like a really bad idea to me. What happens if the result only mostly works?
- dmm 15y ago
  It's a language undergoing rapid development. The developers are planning sometime in early 2012, to release a "Version 1" of go, to which no backwards incompatible changes will be made. http://blog.golang.org/2011/10/preview-of-go-version-1.html http://blog.golang.org/2011/10/preview-of-go-version-1.html
- timclark 15y ago
  Typically gofix just works, well that is my experience of running gofix three times over the six last months. The release notes document when the language has changed and when gofix can help you migrate, and sometimes it can't help and it is documented. Additionally, go exposes the complete AST for the language and a pretty printer as libraries, so you can write your own fixes if you don't trust gofix.
- sausagefeet 15y ago
  Python has been doing this for awhile, hasn't it?
  - DasIch 15y ago
    Python has broken backwards compatibility with Python 3 and tools were written to translate 2.x code to 3.x but that is not at all a regular thing.
    - re 15y ago
      I would say that Python breaks backwards compatibility in small ways for minor releases semi-regularly, such as adding new keywords (with, yield), removing little-used standard library modules, and removing support for raising strings as exceptions, but always provides deprecation warnings for a release first and (for new keywords or syntax) allows early opt-in with "from __future__ import" http://www.python.org/dev/peps/pep-0387/ http://www.python.org/dev/peps/pep-0387/
- rue 15y ago
  > What happens if the result only mostly works? You fix the other parts, or revert to a previous version of your source tree.
- dextorious 15y ago
  You missed the "automatically" part. The other 5% of the time, it can bail out with a message, and you go fix it yourself. Python also has 2to3.
zaphar 15y ago
That is different than the fragile bytecode problem scala appears to have though. Go's issue is that the API's are changing fast so source code has to be modified frequently. Scala's issue seems to be that even when the API's haven't changed and there is no need for a sourcecode change a compiler change could break you. Frankly go's problem seems more manageable.
- luriel 15y ago
  That Go does static linking also helps. And in Go-land source code is pretty much the only way things are distributed because it is so fast to build. For example in Go on AppEngine you upload the source for your app, and it is built on Google's servers. In a way Go's source is its 'bytecode' :)
- nknight 15y ago
  Actually, it sounds like Scala's would be more manageable, if it were handled properly. In fact, you can find a kind of precedent for Scala's problem in C++, which was wildly successful in spite of itself and its many implementation problems that included routine ABI breakage. I can live with having to rebuild my stack for a compiler upgrade, if the ecosystem is setup such that rebuilding the stack is a natural and easy thing to do. The problem seems to be that Scala's ecosystem doesn't work like that. Go, on the other hand, is, in its current stage of development, requiring frequent source-level changes. I consider that much hairier, as it risks altering the actual meaning of the program even without possible compiler bugs (which Go, like every other language, can still have, I don't know why you seem to think Scala's situation there is special). Given their apparent state, I would accept neither Scala nor Go as production ready in a general sense. That said, Go gets points for not pretending to be such.

by jbarham 15y ago

angelbob 15y ago

Wow. So it just rewrites it to the latest version, with (according to what you just said) about 95% accuracy? Does that make other people feel queasy, or just me? Like, that feels like a really bad idea to me. What happens if the result only mostly works?

dmm 15y ago
It's a language undergoing rapid development. The developers are planning sometime in early 2012, to release a "Version 1" of go, to which no backwards incompatible changes will be made. http://blog.golang.org/2011/10/preview-of-go-version-1.html http://blog.golang.org/2011/10/preview-of-go-version-1.html
timclark 15y ago
Typically gofix just works, well that is my experience of running gofix three times over the six last months. The release notes document when the language has changed and when gofix can help you migrate, and sometimes it can't help and it is documented. Additionally, go exposes the complete AST for the language and a pretty printer as libraries, so you can write your own fixes if you don't trust gofix.
sausagefeet 15y ago
Python has been doing this for awhile, hasn't it?
- DasIch 15y ago
  Python has broken backwards compatibility with Python 3 and tools were written to translate 2.x code to 3.x but that is not at all a regular thing.
  - re 15y ago
    I would say that Python breaks backwards compatibility in small ways for minor releases semi-regularly, such as adding new keywords (with, yield), removing little-used standard library modules, and removing support for raising strings as exceptions, but always provides deprecation warnings for a release first and (for new keywords or syntax) allows early opt-in with "from __future__ import" http://www.python.org/dev/peps/pep-0387/ http://www.python.org/dev/peps/pep-0387/
rue 15y ago
> What happens if the result only mostly works? You fix the other parts, or revert to a previous version of your source tree.
dextorious 15y ago
You missed the "automatically" part. The other 5% of the time, it can bail out with a message, and you go fix it yourself. Python also has 2to3.

zaphar 15y ago

That is different than the fragile bytecode problem scala appears to have though. Go's issue is that the API's are changing fast so source code has to be modified frequently. Scala's issue seems to be that even when the API's haven't changed and there is no need for a sourcecode change a compiler change could break you. Frankly go's problem seems more manageable.

luriel 15y ago
That Go does static linking also helps. And in Go-land source code is pretty much the only way things are distributed because it is so fast to build. For example in Go on AppEngine you upload the source for your app, and it is built on Google's servers. In a way Go's source is its 'bytecode' :)
nknight 15y ago
Actually, it sounds like Scala's would be more manageable, if it were handled properly. In fact, you can find a kind of precedent for Scala's problem in C++, which was wildly successful in spite of itself and its many implementation problems that included routine ABI breakage. I can live with having to rebuild my stack for a compiler upgrade, if the ecosystem is setup such that rebuilding the stack is a natural and easy thing to do. The problem seems to be that Scala's ecosystem doesn't work like that. Go, on the other hand, is, in its current stage of development, requiring frequent source-level changes. I consider that much hairier, as it risks altering the actual meaning of the program even without possible compiler bugs (which Go, like every other language, can still have, I don't know why you seem to think Scala's situation there is special). Given their apparent state, I would accept neither Scala nor Go as production ready in a general sense. That said, Go gets points for not pretending to be such.