4 ms·

Hoo boy, this article is pretty wild. > Go is faster than Java / C#, more memory-efficient than Java / C# This is probably the worst part of it, because it do

Hoo boy, this article is pretty wild. > Go is faster than Java / C#, more memory-efficient than Java / C# This is probably the worst part of it, because it doesn't substantiate any of these claims. Look up any set of benchmarks online and you'll find this claim to be mixed at best. Suffice to say if performance actually matters for your app, you'll squeeze plenty out of C# and Java just as you can with Go. And all three languages have no shortage of pitfalls for performance if you're not careful. Go is just a different language. And the author liked it more when they wrote this in 2019.

kristoff_it 4y ago
I actually clarify right after that my claim has nothing to do with benchmarks and actual performance of the programming language. > Go is simple so that all of this can hold true when confronting the average Go program with the average Java / C# program. It doesn’t matter whether Go is truly faster than C# or Java in an absolute sense. The average Java / C# application will be very different than the best theoretical program, and the amount of foot guns in those languages is huge compared to Go. Not to say that I knew perfectly well where Go sat vs Java vs C# in terms of raw performance, but mine was a different point based on my experience.
- phillipcarter 4y ago
  What you're highlighting is also unsubstantiated. What is an average Go, C#, or Java program? I've certainly spoken with C# developers who find even moderate combinations of error states too confusing to handle in Go since it lacks abstractions necessary to represent those states. And I've met Go developers who get horribly confused by overabstraction in C# programs where you need to chase down code across many different files just to know that A called B. But I don't think I could make any blanket claim about simplicity and how that impacts performance. The only thing I do know for certain is that performance work is hard, and all three languages come with toolkits to help you manage it.
mtlynch 4y ago
>>Go is faster than Java / C#, more memory-efficient than Java / C# >Look up any set of benchmarks online and you'll find this claim to be mixed at best. I don't know a ton about low level performance, but I'd find it surprising if it's not true. How can interpreted bytecode outperform direct machine instructions? The benchmarks I've found have Go outperforming Java and C# in almost every test. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- phs2501 4y ago
  > I don't know a ton about low level performance, but I'd find it surprising if it's not true. How can interpreted bytecode outperform direct machine instructions? No production Java/.NET runtime directly interprets bytecode, it gets dynamically compiled into machine code. And as a result it can dynamically _recompile_ it if it discovers runtime profiling patterns that mean a different compilation can run faster, it can dynamically inline functions into the compilation if pertinent, etc. This does not mean that Java/.NET code _will_ always run faster than native static compilation (a quick gander at the real world shows that optimized production code is usually pretty close either way), but it explains how it _can_ run faster.
  - mtlynch 4y ago
    >No production Java/.NET runtime directly interprets bytecode, it gets dynamically compiled into machine code. And as a result it can dynamically _recompile_ it if it discovers runtime profiling patterns that mean a different compilation can run faster, it can dynamically inline functions into the compilation if pertinent, etc. Oh, didn't know that. Interesting, thanks!
  - vvanders 4y ago
    To take this even further, it's not the code that matters as much but the data access patterns and being able to have structured access patterns in ways that preserve cache locality. C# actually does really well on this front in that it brings in value types front-and-center, although similar types of capabilities exist in Java(either through ByteBuffers or sun.misc.Unsafe) if a bit harder to use.

kristoff_it 4y ago

I actually clarify right after that my claim has nothing to do with benchmarks and actual performance of the programming language. > Go is simple so that all of this can hold true when confronting the average Go program with the average Java / C# program. It doesn’t matter whether Go is truly faster than C# or Java in an absolute sense. The average Java / C# application will be very different than the best theoretical program, and the amount of foot guns in those languages is huge compared to Go. Not to say that I knew perfectly well where Go sat vs Java vs C# in terms of raw performance, but mine was a different point based on my experience.

phillipcarter 4y ago
What you're highlighting is also unsubstantiated. What is an average Go, C#, or Java program? I've certainly spoken with C# developers who find even moderate combinations of error states too confusing to handle in Go since it lacks abstractions necessary to represent those states. And I've met Go developers who get horribly confused by overabstraction in C# programs where you need to chase down code across many different files just to know that A called B. But I don't think I could make any blanket claim about simplicity and how that impacts performance. The only thing I do know for certain is that performance work is hard, and all three languages come with toolkits to help you manage it.

mtlynch 4y ago

>>Go is faster than Java / C#, more memory-efficient than Java / C# >Look up any set of benchmarks online and you'll find this claim to be mixed at best. I don't know a ton about low level performance, but I'd find it surprising if it's not true. How can interpreted bytecode outperform direct machine instructions? The benchmarks I've found have Go outperforming Java and C# in almost every test. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/go.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

phs2501 4y ago
> I don't know a ton about low level performance, but I'd find it surprising if it's not true. How can interpreted bytecode outperform direct machine instructions? No production Java/.NET runtime directly interprets bytecode, it gets dynamically compiled into machine code. And as a result it can dynamically _recompile_ it if it discovers runtime profiling patterns that mean a different compilation can run faster, it can dynamically inline functions into the compilation if pertinent, etc. This does not mean that Java/.NET code _will_ always run faster than native static compilation (a quick gander at the real world shows that optimized production code is usually pretty close either way), but it explains how it _can_ run faster.
- mtlynch 4y ago
  >No production Java/.NET runtime directly interprets bytecode, it gets dynamically compiled into machine code. And as a result it can dynamically _recompile_ it if it discovers runtime profiling patterns that mean a different compilation can run faster, it can dynamically inline functions into the compilation if pertinent, etc. Oh, didn't know that. Interesting, thanks!
- vvanders 4y ago
  To take this even further, it's not the code that matters as much but the data access patterns and being able to have structured access patterns in ways that preserve cache locality. C# actually does really well on this front in that it brings in value types front-and-center, although similar types of capabilities exist in Java(either through ByteBuffers or sun.misc.Unsafe) if a bit harder to use.