How does a Go solution compare to a Perl, Python, or Ruby solution? The latter languages offer quick solutions to problems but they don't often scale to large projects built by large teams.
You can cross compile as well. IE compile for Linux from OS X.
http://dave.cheney.net/2012/09/08/an-introduction-to-cross-c...
That said, it's certainly much cleaner to just build static binary executables like Go does.
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.
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.
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.
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."
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.
For general purpose use, this is a huge deficiency in Go.
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.
I do believe the Go code is more maintainable and I like the fact it is statically typed.
Looking at the Benchmark Game Go vs Java7[0], why is Java 2x to 8x faster than Go for many benchmarks? Is the jvm that optimized these days or are those Java7 programs super tweaked for performance?
[0] http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
Go is a very young language so while very fast compared to an interpreted language like Ruby, Python, etc by virtue of being compiled, it going to take some time be be on par (in terms of execution speed) with a Java, a JIT language that has had 18 years to mature.
It says a lot for Go that its execution time is on par with C#: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
What is the basis for your claim? That it's impossible to build large projects without static typing, or what?
I work in enterprise projects done in multi-site context context, usually with teams that encompass more than 30 developers with multiple levels of experience.
Depending on the customer, sometimes it is very hard to force developers to write unit tests. If the customer does not care about them, the product manager will not enforce them.
Additionally given the lack of experiences of the junior developers, always chosen because they are cheaper to the customer, unit tests tend to be badly written.
So with static typing one has at least a guarantee that the product compiles and might eventually even run.
With dynamic typing and lack of tests, you can spend days getting the product back into a runnable state.