Playing with Go1.1beta2, it's much faster

I am sure if Go wasn't being done at Google, most hackers would actually ignore it.

Just check how successful the Go like predecessors from the authors were, when working at other companies.

I think the language suffers from an hallo effect.

http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

That said, Java still beats Go quite readily in this benchmark spread, particularly in regex and binary-trees where Go does extremely poor. It should be noted that lots of languages implement their regex libraries in C for speed, while Go's implementation is written in Go. Still, I think it should do better than this.

That Java beats Go overall is not particularly surprising, Java is very mature and it's jit-compiler has very advanced optimizations, Perhaps by Go 2.0 we'll see where Go 'lands' in terms of performance, there's obviously alot more to be had.

The programs in the shootout are nothing like the programs people typically run and write. For instance, most of the programs I write do a lot of I/O. The shootout programs do none.

> Startup time doesn't matter at all

It certainly does in cluster environments where you regularly spin up new server instances. It's also important for command-line tools.

rather than this: https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...

(not to mention the 2 other Java files to setup the server).

Here's Go 1.1 vs 1.0.3 on a bit beefier machine: https://gist.github.com/errnoh/5320784

Next benchmark will have Go 1.1 running, can't promise that it'll scale as well as on this server but it'll be significant change anyways.

And most of all, main part of the language is that it's intuitive to write and comes with a clear and readable spec and standard library.

edit: updated gist with Netty using the same configuration

The difference between 50 MB and 500 MB is that the former is more likely to fit in L3 cache than the latter. Ignore that difference at your peril.

Tell that to the folks that have to pay for cloud or VPS servers... Also, less memory usage means higher CPU cache hit rates and fewer page faults.

are you _really_ sure it is not just your bias that is preventing you from "expressing" what you want? ie. you want to write python/java in Go?

That's what the original designers of Java thought too. It turns out that this thinking is wrong, though. Main memory may be big, but CPU caches are still small. For example, the laptop I am typing this on has 64 kilobytes of L1 cache, 256 kilobytes of L2 cache, and 3072 kilobytes of L3 cache. That is not a lot. Turns out, when you're spending all your time waiting for main memory, you are not "processing more requests per second." Main memory is at least two orders of magnitude slower than CPU cache.

Ideally, yes. But in practice a language and its implementation (whichever one you choose) is a tool. If you're comparing tools, you've got to compare a language with its implementation.

There are advantages to the way Java does things. You can distribute a single binary for multiple architectures, for example. However, it does have costs, and one of those is slow startup time.