8 ms·

.NET is faster than Go for gRPC so I often wonder if it’s worth my time learning Go for performance when it seems same same.

quixoticelixer- 4y ago
Yeah i really don't understand the advantage of go over c#. Async maybe?
- kjeetgill 4y ago
  I'd argue goroutines are a mostly better alternative to async. Maybe a bit less optimal for a vast improvement of ergonomics and applicability.
  - quixoticelixer- 4y ago
    Yeah goroutines is what i meant by better async. I've used the clojure async stuff a fair bit which was heavily inspired by goroutines and it is quite nice.
  - jpgvm 4y ago
    Goroutines are better than C# async/await but C# is still a better language than Go. When Java 19 lands you can have best of both worlds. Virtual Threads are equivalent to goroutines but you have access to better languages like Java, Kotlin and Clojure.
    - deleted 4y ago
      [deleted]
    - morelisp 4y ago
      I don't think virtual threads will be fully baked in time for production use at Java 19. IMO we'll be waiting at least one and probably two more releases. Valhalla has also produced an amount of language machinery that results in most of the same issues as Go. (E.g. "is this function receiving an interface or concrete value?" becomes "do I have a class, value class, or primitive class?") The performance ripples of requiring value objects to be immutable also remains to be seen.
      - jpgvm 4y ago
        True. I intend to start using them the moment they land in preview but there is still some caveats (namely how they interact with synchronized). I think by Java 21 they will be rock solid though which isn't really that far away in Java timescales.
        kaba0 4y ago
        Aren’t they in preview in 19 already?
        jpgvm 4y ago
        Yes technically as they have been merged but 19 isn't out until September, you can download early-access builds today but we won't see a release build until the official release date.
        morelisp 4y ago
        Sure, but by Java 21 we'll have Go 1.21 with a couple release cycles to push generics into stdlib, and we're back to more or less useless debates about aesthetic preferences and tooling priorities again.
      - kaba0 4y ago
        > The performance ripples of requiring value objects to be immutable also remains to be seen Immutability is trivial to optimize away.
    - zija 4y ago
      C# team began experimenting with green threads: https://twitter.com/davidfowl/status/1532880744732758018?t=PxcziaKHh84Ig5y3PP-45g&s=19 https://twitter.com/davidfowl/status/1532880744732758018?t=P...
      - jpgvm 4y ago
        Well that is very cool!
- deleted 4y ago
  [deleted]
morelisp 4y ago
Stock gRPC is not a great demonstration of Go’s possible performance. The code is neither clean nor fast nor idiomatic. I have no idea why it’s so messed up. (That said, C# and Java are no performance slouches and I expect they’d all be roughly comparable in the end if the Go code didn’t suck so much.)
- jpgvm 4y ago
  C# and Java are almost always faster than Go. Go isn't fast, it's decent but nothing special for AOT native code. (atleast the standard gc compiler, llgo, gccgo etc could end up being a different story). It can show good overall performance in I/O bound workloads because of native M:N green threading though. I imagine even that is no longer a point in Go's favor when Java's Virtual Threads land and become widespread however. Go's only real interesting runtime feature was their emphasis on having a very low latency GC. This was somewhat special for a few years but between improvements made to .NET and Java's new GCs (Shanandoah and ZGC) that gap has been eliminated while these runtimes still provide better throughput on top of their now low latency. There really isn't a good performance or resource usage reason to pick Go over C#/Java anymore, all of its advantages have been eroded.
  - erik_seaberg 4y ago
    Go’s GC throughput isn’t great, but they’re pretty good at keeping values off the heap. Java’s GC is amazing, but we’ll have big working sets and boxing overhead until value types land.
    - kaba0 4y ago
      I would go as far to say that Go’s performance is good only because of value types. Their GC is known to slow down allocation when under big pressure.
      - Groxx 4y ago
        I was poking into a 7-10 second test a couple years ago out of curiosity, and pulled a tracing profile. Garbage collection accounted for over 95% of the run-time. It was a perfect pathological case where it continually thrashed below/above a GC threshold, without hitting the point where it would make more room. Adding just a couple kilobytes of ballast[1] pushed it over the limit to where it reliably took about 200ms. (and then I rewrote the test to stop allocating so much junk) Go's GC is mostly pretty good in practice, but yeah. It's definitely not something you can rely on blindly. Also I wish they'd stop claiming that its pause times are tiny - the stop-the-world pauses are indeed consistently very short, but it hardly matters when it can pause goroutines for far, far longer[2]. And e.g. when you're allocating, your goroutine may be paused to "help" the GC, which can take a substantial amount of time (as happened in that^ test), which frequently leads to very large tail-latency. Most people don't care about stop-the-world times, they care about tail-latency, and Go is just leaning on people's misunderstanding that one is the cause of the other. It can be, but it's not the only source. [1]: https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap/ https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i... [2]: http://big-elephants.com/2018-09/unexpected-gc-pauses/ http://big-elephants.com/2018-09/unexpected-gc-pauses/ among other sources of individual goroutine pauses.

quixoticelixer- 4y ago

Yeah i really don't understand the advantage of go over c#. Async maybe?

kjeetgill 4y ago
I'd argue goroutines are a mostly better alternative to async. Maybe a bit less optimal for a vast improvement of ergonomics and applicability.
- quixoticelixer- 4y ago
  Yeah goroutines is what i meant by better async. I've used the clojure async stuff a fair bit which was heavily inspired by goroutines and it is quite nice.
- jpgvm 4y ago
  Goroutines are better than C# async/await but C# is still a better language than Go. When Java 19 lands you can have best of both worlds. Virtual Threads are equivalent to goroutines but you have access to better languages like Java, Kotlin and Clojure.
  - deleted 4y ago
    [deleted]
  - morelisp 4y ago
    I don't think virtual threads will be fully baked in time for production use at Java 19. IMO we'll be waiting at least one and probably two more releases. Valhalla has also produced an amount of language machinery that results in most of the same issues as Go. (E.g. "is this function receiving an interface or concrete value?" becomes "do I have a class, value class, or primitive class?") The performance ripples of requiring value objects to be immutable also remains to be seen.
    - jpgvm 4y ago
      True. I intend to start using them the moment they land in preview but there is still some caveats (namely how they interact with synchronized). I think by Java 21 they will be rock solid though which isn't really that far away in Java timescales.
      - kaba0 4y ago
        Aren’t they in preview in 19 already?
        jpgvm 4y ago
        Yes technically as they have been merged but 19 isn't out until September, you can download early-access builds today but we won't see a release build until the official release date.
      - morelisp 4y ago
        Sure, but by Java 21 we'll have Go 1.21 with a couple release cycles to push generics into stdlib, and we're back to more or less useless debates about aesthetic preferences and tooling priorities again.
    - kaba0 4y ago
      > The performance ripples of requiring value objects to be immutable also remains to be seen Immutability is trivial to optimize away.
  - zija 4y ago
    C# team began experimenting with green threads: https://twitter.com/davidfowl/status/1532880744732758018?t=PxcziaKHh84Ig5y3PP-45g&s=19 https://twitter.com/davidfowl/status/1532880744732758018?t=P...
    - jpgvm 4y ago
      Well that is very cool!
deleted 4y ago
[deleted]

morelisp 4y ago

Stock gRPC is not a great demonstration of Go’s possible performance. The code is neither clean nor fast nor idiomatic. I have no idea why it’s so messed up. (That said, C# and Java are no performance slouches and I expect they’d all be roughly comparable in the end if the Go code didn’t suck so much.)

jpgvm 4y ago
C# and Java are almost always faster than Go. Go isn't fast, it's decent but nothing special for AOT native code. (atleast the standard gc compiler, llgo, gccgo etc could end up being a different story). It can show good overall performance in I/O bound workloads because of native M:N green threading though. I imagine even that is no longer a point in Go's favor when Java's Virtual Threads land and become widespread however. Go's only real interesting runtime feature was their emphasis on having a very low latency GC. This was somewhat special for a few years but between improvements made to .NET and Java's new GCs (Shanandoah and ZGC) that gap has been eliminated while these runtimes still provide better throughput on top of their now low latency. There really isn't a good performance or resource usage reason to pick Go over C#/Java anymore, all of its advantages have been eroded.
- erik_seaberg 4y ago
  Go’s GC throughput isn’t great, but they’re pretty good at keeping values off the heap. Java’s GC is amazing, but we’ll have big working sets and boxing overhead until value types land.
  - kaba0 4y ago
    I would go as far to say that Go’s performance is good only because of value types. Their GC is known to slow down allocation when under big pressure.
    - Groxx 4y ago
      I was poking into a 7-10 second test a couple years ago out of curiosity, and pulled a tracing profile. Garbage collection accounted for over 95% of the run-time. It was a perfect pathological case where it continually thrashed below/above a GC threshold, without hitting the point where it would make more room. Adding just a couple kilobytes of ballast[1] pushed it over the limit to where it reliably took about 200ms. (and then I rewrote the test to stop allocating so much junk) Go's GC is mostly pretty good in practice, but yeah. It's definitely not something you can rely on blindly. Also I wish they'd stop claiming that its pause times are tiny - the stop-the-world pauses are indeed consistently very short, but it hardly matters when it can pause goroutines for far, far longer[2]. And e.g. when you're allocating, your goroutine may be paused to "help" the GC, which can take a substantial amount of time (as happened in that^ test), which frequently leads to very large tail-latency. Most people don't care about stop-the-world times, they care about tail-latency, and Go is just leaning on people's misunderstanding that one is the cause of the other. It can be, but it's not the only source. [1]: https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap/ https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i... [2]: http://big-elephants.com/2018-09/unexpected-gc-pauses/ http://big-elephants.com/2018-09/unexpected-gc-pauses/ among other sources of individual goroutine pauses.