That is nonsense. There are more scattered Go modules duplicating functionality in Go than just about anything other than JS. Nats may not use them, but everyone else does. There are probably 3 competing libraries just for error handling...
> On Oct 30, 2018, at 8:03 AM, T L <tapir....@gmail.com> wrote: > > OP really should compare the memory consumptions of the Java version and Go > version. > > On Monday, October 29, 2018 at 4:53:52 PM UTC-4, robert engels wrote: >> >> Hello Gophers, >> >> I’ve been chastised in the past regarding some of my Go performance tests - >> using Java as a baseline. In most of these micro-benchmarks Go has performed >> more poorly than expected. >> >> So, I ported nats (https://nats.io) message broker (which is written in Go) >> to Java. It is available at github.com/robaho/jnatsd >> >> This was an ideal test case, as only the server broker was ported, and all >> of the client tools and benchmarks could be run unmodified. >> >> So, using the Java based broker (under OpenJDK11 with Shenandoah) and the >> nats bench with defaults: >> >> without SSL, 3200k msgs per second >> with SSL, 900k msgs per second >> >> using the Go based server (under Go 1.11) and the same test parameters: >> >> without SSL, 5400k msgs per second >> with SSL, 2600k msgs per second >> >> The latency numbers are much closer, but notice the much higher max in Java >> (attributed to larger GC pauses). It is expected that in the above >> throughput tests, more GC cycles, thus a much larger penalty. >> >> Java: >> latency avg 191214 min 167079 max 936848 ns >> Go: >> latency avg 188338 min 158997 max 588876 ns >> >> So, Go shows VERY, VERY impressive performance numbers in a real-world >> application, and aligns with my thoughts that Go is ideally suited to >> replacing systems level software currently written in C/C++. >> >> Some notes, the Java implementation uses some custom string processing >> classes to improve performance, but does not use async IO (mainly since >> doing so with SSL is a huge PITA). The Go server is also FAR more robust in >> terms of ‘handling slow consumers, handling lots of clients, etc.” >> >> I might try modifying the Java to use NIO direct buffers and channels to >> observe any improved performance. >> >> >> >> >> >> > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
