12 ms·

Binary builds are one advantage. Compile your go application and deploy it. No need to also install Ruby, gems etc. You can cross compile as well. IE compil

by jweir 14y ago

Binary builds are one advantage. Compile your go application and deploy it. No need to also install Ruby, gems etc. You can cross compile as well. IE compile for Linux from OS X. http://dave.cheney.net/2012/09/08/an-introduction-to-cross-compilation-with-go http://dave.cheney.net/2012/09/08/an-introduction-to-cross-c...

icebraining 14y ago
That's not necessarily an advantage. E.g. PyInstaller can create stand-alone executables from Python packages. That said, it's certainly much cleaner to just build static binary executables like Go does.
danieldk 14y ago
Imagine that Go were used to write most components on a system. One security vulnerability in one package and you don't replace just one library, you'll have to reroll every binary (or package if you are maintaining a Linux distribution). Also, since there is no version management in Go packaging, you better hope that every program uses the API of the latest or fixed version.
- burntsushi 14y ago
  > Imagine that Go were used to write most components on a system. One security vulnerability in one package and you don't replace just one library, you'll have to reroll every binary (or package if you are maintaining a Linux distribution). Imagine that a shared library were upgraded, and it contained a new vulnerability. This vulnerability now automatically exposes any program that uses said said library. Trade offs :-) (Compiling Go is fast. Re-rolling a binary isn't a Big Deal.) > Also, since there is no version management in Go packaging, you better hope that every program uses the API of the latest or fixed version. Simplicity has a price. But there's no reason why an external tool cannot be made to handle versioning.
  - danieldk 14y ago
    Imagine that a shared library were upgraded, and it contained a new vulnerability. This vulnerability now automatically exposes any program that uses said said library. Production systems normally only replace shared libraries to fix vulnerabilities. So, that's a non-argument. On non-production systems, it's far easier to replace one vulnerable library, than tens of vulnerable Go programs. That is, if you know which Go program was using what version of that package again.
    - dscrd 14y ago
      "far easier" only because there's a huge infrastructure in the package manager that has been built over several years. And it does not always work, even though these days it most often does.
    - burntsushi 14y ago
      > Production systems normally only replace shared libraries to fix vulnerabilities. So, that's a non-argument. Vulnerabilities are usually unforeseen. Which means that upgrading a shared library---for any reason whatsoever---could introduce a new vulnerability to all programs using that library. > On non-production systems, it's far easier to replace one vulnerable library, than tens of vulnerable Go programs. That is, if you know which Go program was using what version of that package again. It's easier, but it comes with aforementioned cost. Also, relative difficulty matters here. Maybe you haven't used Go before, but that all seems pretty simple. Particularly given the tools to analyze Go programs built right into the standard library. Also, FYI, shared Go libraries are on the roadmap. That doesn't really help, but it's certainly better than "we refuse to add it."
    - cmccabe 14y ago
      Do you feel comfortable ripping out a shared library used by many different binaries on a production system and replacing it with a new one? I would be pretty scared to do that. I would rather replace all the binaries separately. If one of the new binaries didn't work, I could go back to the old version. I do agree that the shared library approach uses less network bandwidth, but is that really a big problem these days? Unless you're sysadminning over dialup, chances are you don't really care. The size of binaries has plateaued at a meg or two even as networks have continued to improve.
- TheCoelacanth 14y ago
  This isn't a big problem for Google because they are mostly focused on a tightly controlled server environment where they control everything and created most of the software themselves. For general purpose use, this is a huge deficiency in Go.
- cmccabe 14y ago
  Honestly, I expect there to be far fewer security vulnerabilities in Go than in C/C++ code, simply because it's a managed language. I'm sure there will be some at some point, but it should be at least an order of magnitude less. I also don't really agree with the "fire-fighting" approach to security. Developers are constantly removing security bugs, but they're also constantly adding them. Result: the system is always vulnerable. Why should we copy a failed approach to security, when there are other approaches like sandboxing and process isolation? (By the way, these other approaches are a good idea in C/C++ as well.) Shared libraries are also on the roadmap for Go so at some point that will be a possibility.

by jweir 14y ago

icebraining 14y ago

That's not necessarily an advantage. E.g. PyInstaller can create stand-alone executables from Python packages. That said, it's certainly much cleaner to just build static binary executables like Go does.

danieldk 14y ago

Imagine that Go were used to write most components on a system. One security vulnerability in one package and you don't replace just one library, you'll have to reroll every binary (or package if you are maintaining a Linux distribution). Also, since there is no version management in Go packaging, you better hope that every program uses the API of the latest or fixed version.

burntsushi 14y ago
> Imagine that Go were used to write most components on a system. One security vulnerability in one package and you don't replace just one library, you'll have to reroll every binary (or package if you are maintaining a Linux distribution). Imagine that a shared library were upgraded, and it contained a new vulnerability. This vulnerability now automatically exposes any program that uses said said library. Trade offs :-) (Compiling Go is fast. Re-rolling a binary isn't a Big Deal.) > Also, since there is no version management in Go packaging, you better hope that every program uses the API of the latest or fixed version. Simplicity has a price. But there's no reason why an external tool cannot be made to handle versioning.
- danieldk 14y ago
  Imagine that a shared library were upgraded, and it contained a new vulnerability. This vulnerability now automatically exposes any program that uses said said library. Production systems normally only replace shared libraries to fix vulnerabilities. So, that's a non-argument. On non-production systems, it's far easier to replace one vulnerable library, than tens of vulnerable Go programs. That is, if you know which Go program was using what version of that package again.
  - dscrd 14y ago
    "far easier" only because there's a huge infrastructure in the package manager that has been built over several years. And it does not always work, even though these days it most often does.
  - burntsushi 14y ago
    > Production systems normally only replace shared libraries to fix vulnerabilities. So, that's a non-argument. Vulnerabilities are usually unforeseen. Which means that upgrading a shared library---for any reason whatsoever---could introduce a new vulnerability to all programs using that library. > On non-production systems, it's far easier to replace one vulnerable library, than tens of vulnerable Go programs. That is, if you know which Go program was using what version of that package again. It's easier, but it comes with aforementioned cost. Also, relative difficulty matters here. Maybe you haven't used Go before, but that all seems pretty simple. Particularly given the tools to analyze Go programs built right into the standard library. Also, FYI, shared Go libraries are on the roadmap. That doesn't really help, but it's certainly better than "we refuse to add it."
  - cmccabe 14y ago
    Do you feel comfortable ripping out a shared library used by many different binaries on a production system and replacing it with a new one? I would be pretty scared to do that. I would rather replace all the binaries separately. If one of the new binaries didn't work, I could go back to the old version. I do agree that the shared library approach uses less network bandwidth, but is that really a big problem these days? Unless you're sysadminning over dialup, chances are you don't really care. The size of binaries has plateaued at a meg or two even as networks have continued to improve.
TheCoelacanth 14y ago
This isn't a big problem for Google because they are mostly focused on a tightly controlled server environment where they control everything and created most of the software themselves. For general purpose use, this is a huge deficiency in Go.
cmccabe 14y ago
Honestly, I expect there to be far fewer security vulnerabilities in Go than in C/C++ code, simply because it's a managed language. I'm sure there will be some at some point, but it should be at least an order of magnitude less. I also don't really agree with the "fire-fighting" approach to security. Developers are constantly removing security bugs, but they're also constantly adding them. Result: the system is always vulnerable. Why should we copy a failed approach to security, when there are other approaches like sandboxing and process isolation? (By the way, these other approaches are a good idea in C/C++ as well.) Shared libraries are also on the roadmap for Go so at some point that will be a possibility.