5 ms·

"Because of that, I'm having trouble persuading myself that Go is much more expressive than competitors" Beauty is in the eye of the beholder. While one program

"Because of that, I'm having trouble persuading myself that Go is much more expressive than competitors" Beauty is in the eye of the beholder. While one programmer might say beautiful code is expressiveness (ex. performing a one liner quick sort), that is not what most Go developers I know see as beauty. Beautiful Go in my opinion is code that (in increasing importance): 1. runs fast 2. uses little memory 3. is easily made (or is) concurrent / parallel 4. is transparent (the intuitive run time complexity of operations is apparent, no hidden O(n..) operations, etc) 5. is easy to maintain If this code happens to be more verbose than say Java, so be it, it is still beautiful. On an anecdotal note, most large C++, Java and node.js projects I have ported to Go have ended up being fewer LOC in Go.

melling 14y ago
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.
- 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."
- pekk 14y ago
  This kind of free-floating opinion, unsupported by evidence or even details, is worse than useless. It's a waste of time masquerading as content. What is the basis for your claim? That it's impossible to build large projects without static typing, or what?
  - pjmlp 14y ago
    Based on my experience yes. 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.
- voidlogic 14y ago
  Pretty much like you would expect, the Go code is a bit longer but much more efficient at runtime; similar to what you see at the benchmark game: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=python3 http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... Note: That graph is using go 1.0.3 not Go tip which is even faster. I do believe the Go code is more maintainable and I like the fact it is statically typed.
  - aleyan 14y ago
    Go is quite a bit faster and memory efficient than Python3? No unexpected. Curious how it stacks up with PyPy. 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?test=all&lang=go&lang2=java http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
    - Ziomislaw 14y ago
      jvm is really fast, it can usually compete with C++ code in terms of speed (if you ignore the startup time ;p )
      - voidlogic 14y ago
        The JVM is really fast- but to be fair note the JVMs memory usage in that comparison. Also version of Go used in that comparison is Go 1.0.3 and Go 1.1 RC (which is much faster and has better garbage collection) is going to be out next month. 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?test=all&lang=go&lang2=csharp http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

melling 14y ago

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.

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."
pekk 14y ago
This kind of free-floating opinion, unsupported by evidence or even details, is worse than useless. It's a waste of time masquerading as content. What is the basis for your claim? That it's impossible to build large projects without static typing, or what?
- pjmlp 14y ago
  Based on my experience yes. 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.
voidlogic 14y ago
Pretty much like you would expect, the Go code is a bit longer but much more efficient at runtime; similar to what you see at the benchmark game: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=python3 http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... Note: That graph is using go 1.0.3 not Go tip which is even faster. I do believe the Go code is more maintainable and I like the fact it is statically typed.
- aleyan 14y ago
  Go is quite a bit faster and memory efficient than Python3? No unexpected. Curious how it stacks up with PyPy. 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?test=all&lang=go&lang2=java http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
  - Ziomislaw 14y ago
    jvm is really fast, it can usually compete with C++ code in terms of speed (if you ignore the startup time ;p )
    - voidlogic 14y ago
      The JVM is really fast- but to be fair note the JVMs memory usage in that comparison. Also version of Go used in that comparison is Go 1.0.3 and Go 1.1 RC (which is much faster and has better garbage collection) is going to be out next month. 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?test=all&lang=go&lang2=csharp http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...