3 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. Real

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. Really, things like concurrency primitives as a point in Go's favor? Running code on several processors at once is where it's good to have a library because there are tons of knobs like priority and scheduling policy for instance; it's been trivial to deadlock or arbitrarily delay an entire Go program just by having GOMAXPROCS busy loops and there's no scheduling control at all last time I checked. Meanwhile shared data locking isn't even in the language despite being at a very fine level where using libraries can be cumbersome. And Go comments as good documentation is another mind-boggling claim. It's a mostly free-format with few machine-readable parts. Most functions don't even explain what types of errors can be returned, just "err Error". It's so bad it isn't even comparable to JavaDoc or C#. How can you have "safe" programming when you have to dig through sources to even find out what the error conditions are? There is a good reason to use Go and that's to feel like a pioneer. But few technical reasons.

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 ago
  On 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.

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 ago
On 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.