4 ms·
>Except Java and C# are significantly better at all of these points except for boilerplate, which I would even dispute whether that is a bad thing overall. C#
by gillianseed 12y ago
>Except Java and C# are significantly better at all of these points except for boilerplate, which I would even dispute whether that is a bad thing overall.
C# on Mono certainly isn't significantly better performing than Go from my experience, which is substantiated by Go winning all but one of the 'Benchmark Game' benches, typically by quite a wide margin:
http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=csharp&data=u64q http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
And Go is not doing that bad against Java either:
http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=java&data=u64q http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
- bsdetector 12y agoOn many of these benchmarks, with no memory allocation, since Go is compiled with zero dynamic loading (not even modules) it should be only slightly less fast than C due to range checking and lack of controls for fine tuning, but instead it is half as fast. Benchmarks using memory are 1/6th as fast. Go should be faster than JVM Java at microbenchmarks due to no dynamic loading and precompilation, instead it's only faster on some really tiny algorithms possibly even due to just fitting in the cache better because the GC runtime is so basic. So if you want to write some simple command line tool Go maybe it'll be slightly faster than Java. On anything that uses much memory JVM destroys Go on performance. So performance is not a reason to write something in Go -- in fact it's just the opposite. Since you can't control the coroutine scheduling you can't do anything about latency spikes or starvation or anything else that can cause performance problems in multithreaded programs.