Hacker News Reader

Hacker News

Comment by microtonal | Hacker News Reader

Full thread

microtonal

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 ;).

View on HN

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.

You can't specify it when you import it, but pip/virtualenv solve that issue for the vast majority of use cases.

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).

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.

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).

Sure, there are a number of similar tools for Go. Over the next couple years, I suspect the community will settle on a "standard." I think it's the lack of a standard that the OP is bemoaning. Go just isn't old enough for that yet.

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.

I know, that's why I said that it is true for deployment. It's an advantage of compilers that compile in packages/modules statically into the binary. E.g. Haskell also has this advantage.

The downside, of course, is that if there is a security vulnerability in some package, you have to recompile and redeploy all your binaries, rather than replacing one dynamic library.

Whether it is an advantage depends on the usage scenario.

Or Haskell or Java or Ruby. But these languages have standard (or nearly standard) tools that allow you to specify versioned dependencies (Cabal, Maven, Gem). Go puts package management more or less in the language, but doesn't do version management.

So, your comparison here is not fair. You should compare Go's package management with Python plus setuptools/easy_install, Java plus Maven, Haskell plus Cabal, etc.

  > So, your comparison here is not fair. You should compare 
  > Go's package management with Python plus 
  > setuptools/easy_install, Java plus Maven, Haskell plus 
  > Cabal, etc.

That makes Go look even worse, doesn't it?

Not from a devops viewpoint. Just deploying a new binary is way simpler than dealing with pip/easy_install/gems/cpan/etc.... and all the headaches those involve.

Hell even the stated "just update the library you link to" advantage of compiled programs tends to be overstated as you end up with some software that works and some that doesn't. So statically linking in dependencies and library dependencies by my mind is less of a issue now.

Hell even the stated "just update the library you link to" advantage of compiled programs tends to be overstated as you end up with some software that works and some that doesn't.

If you don't break ABI compatibility it will work. A security fix very rarely changes the ABI.

True, but I have seen it happen with things that end in racle and start with o.

"rather than replacing one dynamic library"

Library and version management at Integration (and before test) simplifies the question "what version are you on?" There is one answer, which for many environments may be useful.

What's stopping someone making a 'Python linker' that packages all the dependencies a Python program needs into a single file? Wouldn't that solve the dependency problem just as well? Is it simply that someone has done this for Go, but not for Python? That seems like a hell of a big switch to make just for the sake of one tool.

http://www.pyinstaller.org/

So instead of a 5 MB Go binary ("5 MB? Ye gods! Unacceptable!"), you get a 200 MB Python distribution, because you need the correct Python version plus all the correct libraries.

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.

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.

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.

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.

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.

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.

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.

> 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 :\

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.

Reply on news.ycombinator.com