The "Go is performant" gospel seems to be coming from people who came from Python and JavaScript to Go. I don't think Go prioritizes performance more than most other popular statically-typed language Java[1], Haskell or Swift (or less popular ones like Ocaml).
And Go obviously doesn't prioritize performance as much as C++ or Rust. Case in point is with very same error handling proposal discussed here. You're going to have to pay a performance price for using a handler since the Go compiler not only avoids inlining defer blocks (if I understand correctly), but even allocates dynamic memory for each block. Meanwhile, equivalent RAII in C++ has no overhead over manual code.
Yes, the Go compiler team is now working on working on fixing this issue, but defer is not a new language construct and they should have started fixing that long ago, considered how often it's being used. What's worse, they still didn't make it a stated goal to eliminate the overhead of using defer completely, but only talk about reducing overhead in common cases.
This approach makes me sad, because Go does have the engineering power and stated design goals to be more serious about performance. Yeah, I feel confident Go will keep improving, but just the same as Java does (without the same hype).
[1] Although until recently they did have radically different choices about which kind of performance to optimize, e.g. Java went up with throughput (Throughput-optimized, JIT tricks for fastest execution after warmup), while Go went for low worst-case latency and faster startup time.
I don't think anybody argues that Go is the most performant language available.
If performance is your main requirement, at the expense of everything else, then Go is definitely not a good choice.
Many consider it a good compromies between performance, readability, syntax, ecosystem, concurrency support etc..., and I believe it is what their designers aimed for originally.
And I'm not saying that other languages do not offer similar compromises, it's nice to have options.
I'm not GP, but I like Go because it prioritizes performance in addition to compile times, ease of use, safety, etc.
I don't think anyone is claiming that Go will outperform well-optimized C++, if you're willing to write your server software in it.
Of the languages you mentioned Java would be the most typically considered alternative for server software. You mentioned Go's low latency but there's also some other strengths like more control of memory layout, slices make it easy to avoid copying in APIs, Goroutines can be lighter weight than Java threads, etc. But as long as Go is roughly comparable I think it's fair to consider Go performant, since Java itself is one of the most mature and optimized languages for server software.
An interesting question is how the compile times in Go compares to those of Java and C#. If the language is somewhat easier, but not very easy, and compiles faster but not really that much faster, it might not be a good way forward for Java and C# developers.
I've always assumed that the compile time comparisons were made against C++ since Google had a lot of large systems written in C++ that they said took a long, long time to compile.
Today I think C# using .NET Core is a good general language. It is easy to learn, fast and compilles pretty fast. It also handles concurrency with async/await or threads. It still has longer start up time than Go, like Java, and might use a bit more memory but should work for most systems.
I totally agree with you on C#, I don't think there's a really strong reason to chose Go over C# for a lot of applications.
Some of the core advantages of Go over Java are less pronounced with C# since C# has async/await, value types, easier C interop, unsafe, etc. The tooling for C# is great too.
C# also has bindings through Xamarin/Mono for iOS/Android/Windows/Mac development that the Go ecosystem doesn't really have an equivalent for. And of course there's Unity for 3D stuff.
There's some minor things like Go being a little less verbose or having a little easier learning curve, but I didn't really find those to be significant problems when using C#.
The main reason I'm using Go right now is mostly the GC properties. It's easier to avoid allocating memory but also the pause times are much lower than most other GC languages including C# [1]. For anything where latency is important Go is an interesting choice these days since it's hard to go any lower without adopting some form non-GC memory management.
Defer already allocates on stack, in the case where it is only ever called once in a function, in HEAD I believe.
Anyway, cherrypicking a single feature of Go and claiming it's an example of why Go doesn't care about performance feels unfair. There's definitely been a huge amount of engineering effort spent on Go performance, especially latency in the GC. Defer is "slow" but it is probably rarely a bottleneck for anyone's use case. Try/catch are pretty slow in many languages.
> Yes, the Go compiler team is now working on working on fixing this issue, but defer is not a new language construct and they should have started fixing that long ago, considered how often it's being used. What's worse, they still didn't make it a stated goal to eliminate the overhead of using defer completely, but only talk about reducing overhead in common cases.
They constantly improve defer's performance. If it's all you have against go, then I guess it's good enough for you.
And Go obviously doesn't prioritize performance as much as C++ or Rust. Case in point is with very same error handling proposal discussed here. You're going to have to pay a performance price for using a handler since the Go compiler not only avoids inlining defer blocks (if I understand correctly), but even allocates dynamic memory for each block. Meanwhile, equivalent RAII in C++ has no overhead over manual code.
Yes, the Go compiler team is now working on working on fixing this issue, but defer is not a new language construct and they should have started fixing that long ago, considered how often it's being used. What's worse, they still didn't make it a stated goal to eliminate the overhead of using defer completely, but only talk about reducing overhead in common cases.
This approach makes me sad, because Go does have the engineering power and stated design goals to be more serious about performance. Yeah, I feel confident Go will keep improving, but just the same as Java does (without the same hype).
[1] Although until recently they did have radically different choices about which kind of performance to optimize, e.g. Java went up with throughput (Throughput-optimized, JIT tricks for fastest execution after warmup), while Go went for low worst-case latency and faster startup time.