I think if you look into Zing or Shenandoah you’ll find a different experience. Literally zero tuning required.
> On Feb 7, 2020, at 3:29 PM, Marcin Romaszewicz <marc...@gmail.com> wrote: > > > > >> On Fri, Feb 7, 2020 at 11:43 AM Robert Engels <reng...@ix.netcom.com> wrote: >> I didn’t look into the project but reading between the lines here I am >> betting that Java would perform as well as Rust in this case. This is an >> example of where not having generational GC hurts badly - since it appears >> that most of their heap would be very long lived objects. >> > > I've been running Go, Java, C++ and Python code in wide scale production for > years, so have some background for comparison here. Java's garbage collector > is not great either. Pretty much the biggest challenge of running Java > services is constantly tuning JVM args to keep it from either taking down > your machine, or sabotaging its own performance. It's a never ending battle. > A non-GC language app can have a memory leak, but it's obvious, and it's a > bug, while with Java's GC, and to a much lesser extent Go, you can have > runaway memory usage which isn't necessarily the result of a bug, but a > language behavior. Currently, I'm predominantly running services in Java, > which interact with Hadoop, and Go, which make REST API's backed by databases > and some limited interaction with Hadoop. With the Go services, most of our > engineers time is spent writing the initial code and tests. With Java, most > of their time is spent chasing Java memory allocation issues. I think the > place the effort goes speaks volumes about how well the GC works in both > languages. > >>>> On Feb 7, 2020, at 12:57 PM, Marcin Romaszewicz <marc...@gmail.com> wrote: >>>> >>> >>> You're not oversimplifying. GC incurs a price, and that's performance. If >>> you have a program which manages its own memory optimally for its usage >>> pattern, it will be more efficient than a generic GC that has to handle all >>> usage patterns. I use Go everywhere I can, since the tradeoff between >>> programmer work and performance is phenomenal, but where latency or >>> throughput really matter, it's still a compiled language without generic >>> garbage collection. I'm sure there are many things that Rust will perform >>> at better than Go, but that's not a statement about one language being in >>> any way better than the other, just different. >>> >>>> On Fri, Feb 7, 2020 at 10:40 AM Tyler Compton <xavi...@gmail.com> wrote: >>>> It would have been nice to see performance measurements from a more recent >>>> Go version. That said, it makes sense to me that Rust would be a better >>>> choice for this kind of application, where the main performance bottleneck >>>> is the sheer number of objects in memory. A language where you get to >>>> express more about the life-cycle of these objects should perform better. >>>> I say this as someone that knows very little about Rust, so I'm probably >>>> greatly oversimplifying. >>>> >>>>> On Fri, Feb 7, 2020 at 4:25 AM Everton Marques >>>>> <everton.marq...@gmail.com> wrote: >>>>> I think Go is way better than Rust, but it is amusing to see why people >>>>> pick one over another. >>>>> >>>>> "Remarkably, we had only put very basic thought into optimization as the >>>>> Rust version was written. Even with just basic optimization, Rust was >>>>> able to outperform the hyper hand-tuned Go version. This is a huge >>>>> testament to how easy it is to write efficient programs with Rust >>>>> compared to the deep dive we had to do with Go." >>>>> >>>>> https://blog.discordapp.com/why-discord-is-switching-from-go-to-rust-a190bbca2b1f >>>>> >>>>> -- >>>>> 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. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/golang-nuts/c3d9fc18-b750-48d7-b0b8-fd78afdbbf29%40googlegroups.com. >>>> >>>> -- >>>> 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. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2wEHsC0fo32srrrJnXnLA2-s%2BzJ82JF7T96NqtQBkUVQ%40mail.gmail.com. >>> >>> -- >>> 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. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29Lu6RNc8XssP58y3EVk8idGo%3D%3D3YdOToOVdzH--AkknGbg%40mail.gmail.com. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/71C8DBCA-C12C-4108-95F1-39862ACC769F%40ix.netcom.com.
