5 ms·

I love Go for many of the same reasons as the author. Go's fantastic performance doesn’t' hurt either. :) These micro-benchmarks match what I have seen in the

I love Go for many of the same reasons as the author. Go's fantastic performance doesn’t' hurt either. :) These micro-benchmarks match what I have seen in the real world: http://benchmarksgame.alioth.debian.org/u64q/which-programs-are-best.php?calc=chart&go=on&ghc=on&sbcl=on&java=on&scala=on&csharp=on&fsharp=on&php=on&hipe=on&python3=on&erlang=on&clojure=on&yarv=on&perl=on&jruby=on&xfullcpu=1&xmem=1&xloc=1&nbody=1&fannkuchredux=1&meteor=1&fasta=1&fastaredux=1&spectralnorm=1&revcomp=1&mandelbrot=1&knucleotide=1&regexdna=1&pidigits=1&chameneosredux=1&threadring=1&binarytreesredux=1&binarytrees=1 http://benchmarksgame.alioth.debian.org/u64q/which-programs-...

pron 14y ago
They sure do. Slower than Scala and requiring more code and lacking the awesome power of the JVM. Great choice, indeed.
- voidlogic 14y ago
  Yeah- that is great as long as you don't care about using 30x times more memory.... The awesome bloat cough I mean power of the JVM in action. Go vs Scala: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=scala http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... It will be interesting to re-visit this when Go 1.1 is out as well. Go being even younger than Scala has a lot of low hanging optimization fruit. :) P.S. If Go didn't exist I would still be using Java/C#/C/C++ for everything. (I still use Haskell/Prolog where needed)
  - pron 14y ago
    The memory consumption is probably mostly due to the JVM's GC implementation that can be very finely tuned (although large RAM footprint surely is a feature of the JVM). Some of the bloat is, true, baggage that's been accumulated through the years, but that's being taken care of in Java 9. And the rest of the "bloat" is there for a reason. Let me put it this way: if you have a program that absolutely requires JVM performance, it probably requires the "bloat" as well, as it gives you runtime instrumentation, advanced debugging hooks and other sorts of invaluable monitoring tools.
    - voidlogic 14y ago
      I agree about the great tools, I have used them. But for being so simple Go gives you a lot of tools as well: http://golang.org/pkg/runtime/pprof/ http://golang.org/pkg/runtime/pprof/ http://golang.org/pkg/net/http/pprof/ http://golang.org/pkg/net/http/pprof/ http://blog.golang.org/2011/06/profiling-go-programs.html http://blog.golang.org/2011/06/profiling-go-programs.html Go also has gdb support I used from my IDE (http://golang.org/doc/gdb http://golang.org/doc/gdb)
  - jlgreco 14y ago
    Not to mention the frankly idiotic JVM startup time that becomes a nightmare if you are just trying to make a commandline tool. And no, don't bother mentioning nailgun or the like. Those cures are worse than the illness.
    - igouy 14y ago
      When your commandline tool needs several seconds CPU to complete the task, JVM startup time is irrelevant. The benchmarks game measurements posted by voidlogic include JVM startup time and yet many of the Scala programs are faster than the corresponding Go programs, when the programs run for seconds. So a Go n-body program can be faster than a Scala n-body program at 0.33secs over a small workload, but then over a larger workload take 32.1secs compared to 23.5secs for the Scala program. http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&lang=go&id=1 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=nbody&lang=scala http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
      - jlgreco 14y ago
        > When your commandline tool needs several seconds CPU to complete the task And mine do not. Furthermore, when you program is but one of many steps in a pipeline, but is not the bottleneck, startup time can have a very noticeable effect. I've heard a million reasons why JVM startup times do not matter. You are telling me nothing new.
        igouy 14y ago
        Now you are telling us -- it depends :-)
  - crypto5 14y ago
    > Yeah- that is great as long as you don't care about using 30x times more memory.... > Go vs Scala: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t.. http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t.... There is no such thing on that page. You see 30x times win for go only where program uses very small amount of memory. When memory consumption is big(regex-dna and binary trees), memory footprint is very similar for both scala and go(+-10%).
    - lazyjones 14y ago
      Makes me wonder why people don't use Free Pascal more ... It shares many of Go's advantages described here (simple language, powerful libraries) and is frequently faster and uses less memory (8KB memory in 4 cases where Go uses 700-1200KB!) on the Benchmark Game programs. It's probably the C-like syntax that tips the scales every time ...
      - igouy 14y ago
        Nothing complicated -- Pascal has been out-of-fashion for many decades.
  - igouy 14y ago
    These measurements show Go programs using more memory than the corresponding Java programs, please explain how that fits with your "awesome bloat" remark. k-nucleotide 260,908KB vs Java program 167,924KB regex-dna 679,836KB vs Java program 621,712KB binary-trees 565,076KB vs Java program 528,364KB and not much difference for this reverse-complement 249,304KB vs Java program 298,904KB http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=java#faster-programs-measurements http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... For tiny tiny programs that only allocate a few KB, the default JVM allocation swamps what the programs use -- that changes when programs need to allocate memory.

pron 14y ago

They sure do. Slower than Scala and requiring more code and lacking the awesome power of the JVM. Great choice, indeed.

voidlogic 14y ago
Yeah- that is great as long as you don't care about using 30x times more memory.... The awesome bloat cough I mean power of the JVM in action. Go vs Scala: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=scala http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... It will be interesting to re-visit this when Go 1.1 is out as well. Go being even younger than Scala has a lot of low hanging optimization fruit. :) P.S. If Go didn't exist I would still be using Java/C#/C/C++ for everything. (I still use Haskell/Prolog where needed)
- pron 14y ago
  The memory consumption is probably mostly due to the JVM's GC implementation that can be very finely tuned (although large RAM footprint surely is a feature of the JVM). Some of the bloat is, true, baggage that's been accumulated through the years, but that's being taken care of in Java 9. And the rest of the "bloat" is there for a reason. Let me put it this way: if you have a program that absolutely requires JVM performance, it probably requires the "bloat" as well, as it gives you runtime instrumentation, advanced debugging hooks and other sorts of invaluable monitoring tools.
  - voidlogic 14y ago
    I agree about the great tools, I have used them. But for being so simple Go gives you a lot of tools as well: http://golang.org/pkg/runtime/pprof/ http://golang.org/pkg/runtime/pprof/ http://golang.org/pkg/net/http/pprof/ http://golang.org/pkg/net/http/pprof/ http://blog.golang.org/2011/06/profiling-go-programs.html http://blog.golang.org/2011/06/profiling-go-programs.html Go also has gdb support I used from my IDE (http://golang.org/doc/gdb http://golang.org/doc/gdb)
- jlgreco 14y ago
  Not to mention the frankly idiotic JVM startup time that becomes a nightmare if you are just trying to make a commandline tool. And no, don't bother mentioning nailgun or the like. Those cures are worse than the illness.
  - igouy 14y ago
    When your commandline tool needs several seconds CPU to complete the task, JVM startup time is irrelevant. The benchmarks game measurements posted by voidlogic include JVM startup time and yet many of the Scala programs are faster than the corresponding Go programs, when the programs run for seconds. So a Go n-body program can be faster than a Scala n-body program at 0.33secs over a small workload, but then over a larger workload take 32.1secs compared to 23.5secs for the Scala program. http://benchmarksgame.alioth.debian.org/u64q/program.php?test=nbody&lang=go&id=1 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=nbody&lang=scala http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
    - jlgreco 14y ago
      > When your commandline tool needs several seconds CPU to complete the task And mine do not. Furthermore, when you program is but one of many steps in a pipeline, but is not the bottleneck, startup time can have a very noticeable effect. I've heard a million reasons why JVM startup times do not matter. You are telling me nothing new.
      - igouy 14y ago
        Now you are telling us -- it depends :-)
- crypto5 14y ago
  > Yeah- that is great as long as you don't care about using 30x times more memory.... > Go vs Scala: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t.. http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t.... There is no such thing on that page. You see 30x times win for go only where program uses very small amount of memory. When memory consumption is big(regex-dna and binary trees), memory footprint is very similar for both scala and go(+-10%).
  - lazyjones 14y ago
    Makes me wonder why people don't use Free Pascal more ... It shares many of Go's advantages described here (simple language, powerful libraries) and is frequently faster and uses less memory (8KB memory in 4 cases where Go uses 700-1200KB!) on the Benchmark Game programs. It's probably the C-like syntax that tips the scales every time ...
    - igouy 14y ago
      Nothing complicated -- Pascal has been out-of-fashion for many decades.
- igouy 14y ago
  These measurements show Go programs using more memory than the corresponding Java programs, please explain how that fits with your "awesome bloat" remark. k-nucleotide 260,908KB vs Java program 167,924KB regex-dna 679,836KB vs Java program 621,712KB binary-trees 565,076KB vs Java program 528,364KB and not much difference for this reverse-complement 249,304KB vs Java program 298,904KB http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=java#faster-programs-measurements http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t... For tiny tiny programs that only allocate a few KB, the default JVM allocation swamps what the programs use -- that changes when programs need to allocate memory.