5 ms·

A long post that gives two arguments near the end in favor of Go over their old language of choice (Python): 1. No dependency issues. 2. Compiles with no issu

A long post that gives two arguments near the end in favor of Go over their old language of choice (Python): 1. No dependency issues. 2. Compiles with no issues on different platforms. And one sort of argument in between: 3. Some of the tools that they use were written in Go. While (1) is true for deployment, dependency handing is not a solved problem in Go. Since import statements do not allow you to specify versions, you have to keep track of which commits of a particular project you trust. I am pretty sure that this problem will be solved, but it currently isn't. (3) is perhaps an argument in favor of being able to read Go, but not to switch to Go. By those standards, everyone on Unix should be writing C ;).

cmccabe 13y ago
One thing that annoyed me about both Python and Rubyis that the way things in the standard library worked changed from release to release in subtle, incompatible ways. I remember getting burned by a change in how iterating over characters in a string worked in Ruby in the 1.8.x versions. Sorry-- I don't remember the details, it's been a few years. The point is that if you want to run in on a different PC than you developed the code on, or upgrade, these are buried landmines which are going to blow your leg off sooner or later. If you're working on an open source project, often the first sign you get that your Python code doesn't work on older or newer versions is a user reporting a mysterious RuntimeException. virtualenv can sort of solve a lot of these issues, if you have complete control of all computers running your software, and if you can find a Python version that works for all the packages you need. But for a lot of open source projects, these assumptions may not be true. And then you have the issue of stagnation. It sucks to be stuck on Python 2.4.x in 2013. But how do you make a business case for a potentially very risky upgrade? This is the real reason why initiatives like Python 3.x and Perl 6.x have been DOA, in my opinion.
- philsnow 13y ago
  > One thing that annoyed me about both Python and Rubyis that the way things in the standard library worked changed from release to release in subtle, incompatible ways. I got bitten by one such implementation detail changing in between releases in python. It had something to do with the pickle machinery, like the 'set' builtin changing from using __reduce__ to __reduce_ex__ or vice versa, or something like that, and all the pickles that were serialized in 2.4 were deserializing incorrectly in 2.6. I can't remember the details now :\
- copx 13y ago
  I think with Python and Ruby the assumption is that the typical code base is either in a state of permanent change or dead and thus the advantages of improved code / improved API outweigh the advantages of backwards compatibility. It's a tradeoff, there is no universally right solution there. If you want to write code which is meant to last for decades unchanged you want ISO C or C++, backwards compatibility is a primary virtue there. My ANSI C89 code from 20 years ago still builds and works as expected when compiled as ISO C11 with the newest compilers. Of course there are also languages between these extremes.
dsymonds 13y ago
His reference to a lack of dependency issues is a runtime aspect: A Python program requires the right Python interpreter and all the right Python modules to be set up correctly on the target system. For Go, you can build a single binary in a different place where you control the packages you use, and deployment is as simple as using scp. I think you realised that, but versioning imports in Go is at exactly the same state as versioning imports in Python. I can't write an import statement in Python that describes what version I need, nor can I in Go.
- JshWright 13y ago
  You can't specify it when you import it, but pip/virtualenv solve that issue for the vast majority of use cases.
  - dsymonds 13y ago
    If you're including external tools, there's a bunch of tools that do it for Go too, such as rx (http://godoc.org/kylelemons.net/go/rx http://godoc.org/kylelemons.net/go/rx).
    - danieldk 13y ago
      They are not standard. setuptools, cabal, Maven, et al. are. I have two Go libraries, and I do (and cannot) specify its version dependencies in a standardized manner.
      - cmccabe 13y ago
        Maven isn't standardized. There are still a lot of projects that use Ant + Grail or Gradle. There's also OSGI, which is sort of yet another way to manage dependencies in Java. Maven doesn't prevent versioning issues from cropping up, either. One common example is where dependency A pulls in library C 1.0, but dependency B pulls in library C 2.0. They often conflict, and then your software fails at runtime (fun fun!) There are a bunch of hadoop bugs where exactly this happened, although I'm too lazy to look up the JIRAs right now. I feel like if you want a stable version of something, you should use yum, apt-get, or your package manager of choice. I don't think the programming language should try to do the package manager's job. It never seems to end well. So far, I haven't seen actual harm caused by a lack of library version numbers, and there seems to have been a lot of good done (people using and testing latest versions, green master policy, etc).
chaotic-good 13y ago
Since import statements do not allow you to specify versions, you have to keep track of which commits of a particular project you trust. I am pretty sure that this problem will be solved, but it currently isn't. Go forces everybody to use green master policy. Every library is expected to have green master and stable API. If you need to change API of your Go library, you must create new repository.
- Argorak 13y ago
  Thats sounds alot like the policy in the TeX world, where forks of libraries with breaking changes need a new name. Quite frankly, it's even harder to follow than the occasional breakage at version changes, especially when you try to find out what the "modern version" of what you are using is.
- thechriswalker 13y ago
  That's not entirely true. Go allows you to tag with the Go version you are aiming for and imports will use that. You do not have to keep your master clean. If you clone explicitly into your GOPATH then you can develop on any branch you like. Similarly, if you use git for version control and so does your library then you can always submodule your dep into your GOPATH and submodules allow you to specific the exact commit you wish to use.
  - cmccabe 13y ago
    Yes, you do have to keep your master clean. The version tagging thing is only intended to be used when you start depending on a new language feature not available in older versions of Go. For example, if your new code needs something that's only in Go 1.1, you could create a 1.0 tag right before making that change. But people using new versions of Go will get whatever is in master, not whatever is at that tag. Yes, you can always clone explicitly into a path, but then we're not talking about the module system any more, are we? We're just talking about you copying around files locally. It's misleading to state this like it's the recommended or usual way to do things.
oakaz 13y ago
Yeah it's much better than Python but not good enough also. We should still talk about a better and safer module system in Go community. People do their own versioning by forking repos - this is pain in the ass. We need a good module system with versions; like NPM.
kaib 13y ago
My impression is that static linking is undervalued by developers who have not been responsible for the production deployment of binaries to larger (hundreds or hundreds of thousands of systems). When debugging production systems at that scale you want to minimize the number of moving parts given the problem is so hard to begin with. ABI compatibility just postulates that the bytes entering and leaving the interface will be marshalled the same way. However, the semantics of the function must by definition always change when you change the implementation. You are arguing that these semantic changes are sometimes inconsequential, like for security updates. Based on my personal experience I think a more conservative view is appropriate and any changes to the dependencies of a program should be tested before large scale deployment.

cmccabe 13y ago

One thing that annoyed me about both Python and Rubyis that the way things in the standard library worked changed from release to release in subtle, incompatible ways. I remember getting burned by a change in how iterating over characters in a string worked in Ruby in the 1.8.x versions. Sorry-- I don't remember the details, it's been a few years. The point is that if you want to run in on a different PC than you developed the code on, or upgrade, these are buried landmines which are going to blow your leg off sooner or later. If you're working on an open source project, often the first sign you get that your Python code doesn't work on older or newer versions is a user reporting a mysterious RuntimeException. virtualenv can sort of solve a lot of these issues, if you have complete control of all computers running your software, and if you can find a Python version that works for all the packages you need. But for a lot of open source projects, these assumptions may not be true. And then you have the issue of stagnation. It sucks to be stuck on Python 2.4.x in 2013. But how do you make a business case for a potentially very risky upgrade? This is the real reason why initiatives like Python 3.x and Perl 6.x have been DOA, in my opinion.

philsnow 13y ago
> One thing that annoyed me about both Python and Rubyis that the way things in the standard library worked changed from release to release in subtle, incompatible ways. I got bitten by one such implementation detail changing in between releases in python. It had something to do with the pickle machinery, like the 'set' builtin changing from using __reduce__ to __reduce_ex__ or vice versa, or something like that, and all the pickles that were serialized in 2.4 were deserializing incorrectly in 2.6. I can't remember the details now :\
copx 13y ago
I think with Python and Ruby the assumption is that the typical code base is either in a state of permanent change or dead and thus the advantages of improved code / improved API outweigh the advantages of backwards compatibility. It's a tradeoff, there is no universally right solution there. If you want to write code which is meant to last for decades unchanged you want ISO C or C++, backwards compatibility is a primary virtue there. My ANSI C89 code from 20 years ago still builds and works as expected when compiled as ISO C11 with the newest compilers. Of course there are also languages between these extremes.

dsymonds 13y ago

His reference to a lack of dependency issues is a runtime aspect: A Python program requires the right Python interpreter and all the right Python modules to be set up correctly on the target system. For Go, you can build a single binary in a different place where you control the packages you use, and deployment is as simple as using scp. I think you realised that, but versioning imports in Go is at exactly the same state as versioning imports in Python. I can't write an import statement in Python that describes what version I need, nor can I in Go.

JshWright 13y ago
You can't specify it when you import it, but pip/virtualenv solve that issue for the vast majority of use cases.
- dsymonds 13y ago
  If you're including external tools, there's a bunch of tools that do it for Go too, such as rx (http://godoc.org/kylelemons.net/go/rx http://godoc.org/kylelemons.net/go/rx).
  - danieldk 13y ago
    They are not standard. setuptools, cabal, Maven, et al. are. I have two Go libraries, and I do (and cannot) specify its version dependencies in a standardized manner.
    - cmccabe 13y ago
      Maven isn't standardized. There are still a lot of projects that use Ant + Grail or Gradle. There's also OSGI, which is sort of yet another way to manage dependencies in Java. Maven doesn't prevent versioning issues from cropping up, either. One common example is where dependency A pulls in library C 1.0, but dependency B pulls in library C 2.0. They often conflict, and then your software fails at runtime (fun fun!) There are a bunch of hadoop bugs where exactly this happened, although I'm too lazy to look up the JIRAs right now. I feel like if you want a stable version of something, you should use yum, apt-get, or your package manager of choice. I don't think the programming language should try to do the package manager's job. It never seems to end well. So far, I haven't seen actual harm caused by a lack of library version numbers, and there seems to have been a lot of good done (people using and testing latest versions, green master policy, etc).

chaotic-good 13y ago

Since import statements do not allow you to specify versions, you have to keep track of which commits of a particular project you trust. I am pretty sure that this problem will be solved, but it currently isn't. Go forces everybody to use green master policy. Every library is expected to have green master and stable API. If you need to change API of your Go library, you must create new repository.

Argorak 13y ago
Thats sounds alot like the policy in the TeX world, where forks of libraries with breaking changes need a new name. Quite frankly, it's even harder to follow than the occasional breakage at version changes, especially when you try to find out what the "modern version" of what you are using is.
thechriswalker 13y ago
That's not entirely true. Go allows you to tag with the Go version you are aiming for and imports will use that. You do not have to keep your master clean. If you clone explicitly into your GOPATH then you can develop on any branch you like. Similarly, if you use git for version control and so does your library then you can always submodule your dep into your GOPATH and submodules allow you to specific the exact commit you wish to use.
- cmccabe 13y ago
  Yes, you do have to keep your master clean. The version tagging thing is only intended to be used when you start depending on a new language feature not available in older versions of Go. For example, if your new code needs something that's only in Go 1.1, you could create a 1.0 tag right before making that change. But people using new versions of Go will get whatever is in master, not whatever is at that tag. Yes, you can always clone explicitly into a path, but then we're not talking about the module system any more, are we? We're just talking about you copying around files locally. It's misleading to state this like it's the recommended or usual way to do things.

oakaz 13y ago

Yeah it's much better than Python but not good enough also. We should still talk about a better and safer module system in Go community. People do their own versioning by forking repos - this is pain in the ass. We need a good module system with versions; like NPM.

kaib 13y ago

My impression is that static linking is undervalued by developers who have not been responsible for the production deployment of binaries to larger (hundreds or hundreds of thousands of systems). When debugging production systems at that scale you want to minimize the number of moving parts given the problem is so hard to begin with. ABI compatibility just postulates that the bytes entering and leaving the interface will be marshalled the same way. However, the semantics of the function must by definition always change when you change the implementation. You are arguing that these semantic changes are sometimes inconsequential, like for security updates. Based on my personal experience I think a more conservative view is appropriate and any changes to the dependencies of a program should be tested before large scale deployment.