News for hackers. Stuff that matters.
Re:Go performance from version 1.2 to 1.18 by pjmlp on Friday February 04, 2022 @02:16AM (#30203749)
In what concerns .NET is wasn't really better,

https://devblogs.microsoft.com/dotnet/grpc-performance-impro...

Re:Go performance from version 1.2 to 1.18 by jmnicolas on Friday February 04, 2022 @02:24AM (#30203808)
The difference is meaningless, it's just gRPC and it's a MS blog... so nothing to call home about.

And I'm saying this as a C# dev that never wrote anything in Go.

Re:Go performance from version 1.2 to 1.18 by tgtweak on Friday February 04, 2022 @12:50PM (#30210105)
.net 5 (and former .net core) was pretty fast. The issue was in serverless there is a pretty long cold start since the interpreter is still invoked which is like a mini virtual machine. If you're sticking to azure, they have a highly customized environment for it that I'm pretty sure saves interpreted output vs source code.

I would highly recommend golang to old school C# devs who are very comfortable with threading, thread safety, and mix of high and low level code in the same codebase.

edit: Best go devs I know are seasoned C or C# backgrounds.

Re:Go performance from version 1.2 to 1.18 by pjmlp on Friday February 04, 2022 @02:38AM (#30203885)
Ok, here is another one, then.

https://www.techempower.com/benchmarks/

You should learn to write some Go code then.

Re:Go performance from version 1.2 to 1.18 by jmnicolas on Saturday February 05, 2022 @04:47PM (#30226514)
> You should learn to write some Go code then.

Why? C# fits the bill for everything I want to do. It's fast enough, it has great IDEs, it runs almost everywhere and there are more UI frameworks than there are JS frameworks /jk ;).

I have almost 15 years experience in it, why would I slow down my next projects by using a language I'm not familiar with (as long as C# fits the bill ofc). Learning a new language isn't a hobby for me, it has to be useful to me (I learned Flutter because MS Ui frameworks aren't a panacea).

Re:Go performance from version 1.2 to 1.18 by throwaway894345 on Friday February 04, 2022 @12:19PM (#30209648)
Maybe I'm not following the thread (I'm not sure what "In what concerns .NET is wasn't really better" means), but what's the issue here? C#'s fastest framework beats Go's fastest by a marginal amount (60.1% vs 59.1%). That's probably within the error margin. Anyway, drawing sweeping performance conclusions from microbenchmarks is perilous--a high ceiling for an HTTP framework doesn't indicate anything about real-world performance for web applications (which are almost never bottlenecked on the HTTP framework).
Re:Go performance from version 1.2 to 1.18 by pjmlp on Saturday February 05, 2022 @05:15AM (#30219703)
The issue here is how many in the Go community like to boost themselves about how fast Go is, only because it is the very first AOT compiled language that they ever used, usually come form scripting language backgrounds and are influenced by the traditional Java/.NET hate, without ever using them in anger, including their AOT tooling.

So then we come these kind of assertions like Go compiles faster than any other AOT language, it doesn't have a runtime, its performance beats Java/.NET and so on.

Re:Go performance from version 1.2 to 1.18 by throwaway894345 on Saturday February 05, 2022 @10:32AM (#30222036)
I’m sure if you searched hard you could find a few people in the Go community who say silly things like that, but (1) you could find these kinds of people in any community and (2) in the Go community these people are quickly corrected and (3) no one in this thread is making these sorts of arguments (as far as I can tell) so your comment seems wildly off-topic.

Note the difference between “Go is better for certain cloud applications than Python, NodeJS, etc” and “Go is better than all other languages, full stop”.

Re:Go performance from version 1.2 to 1.18 by morelisp on Friday February 04, 2022 @02:57AM (#30204031)
This says a lot more about the quality of C# vs. Go's protobuf code generator (which was already poor and now even worse - you're going to the trouble of codegen but then implement it using reflection?) than either language itself.
Re:Go performance from version 1.2 to 1.18 by pjmlp on Friday February 04, 2022 @03:46AM (#30204349)
There are plenty of other examples one can reach for.

Go would lose in performace benchmarks that make heavy use of generics or SIMD code in .NET, because:

1) We all know the current state of generics in Go

2) Currently most of the SIMD support in Go is basically "write your own Assembly code in hex", because many of the opcodes aren't even supported by the Go assembler

Then there are other factors like since .NET 6 there is the possibility to use a JIT cache with PGO, and there is only so much a single AOT compilation can bring into the picture, specially since Go tooling isn't that big into making use of PGO data.

Or the fact that .NET was designed to support languages like C++, so there are enough knobs to turn if one really wants to go full speed.

Naturaly because hating Microsoft and their technologies is fashionable, few bother to actually learn the extent of ecosystems like .NET actually offer in detail.

Re:Go performance from version 1.2 to 1.18 by morelisp on Friday February 04, 2022 @06:48AM (#30205612)
> Naturaly because hating Microsoft and their technologies is fashionable, few bother to actually learn the extent of ecosystems like .NET actually offer in detail.

You're definitely projecting something here.

[dead]
Re:Go performance from version 1.2 to 1.18 by morelisp on Friday February 04, 2022 @07:34AM (#30205980)
I didn't say anything bad at all about .NET.