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 >> <https://groups.google.com/d/msgid/golang-nuts/CAA%3DXfu2wEHsC0fo32srrrJnXnLA2-s%2BzJ82JF7T96NqtQBkUVQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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 > <https://groups.google.com/d/msgid/golang-nuts/CA%2Bv29Lu6RNc8XssP58y3EVk8idGo%3D%3D3YdOToOVdzH--AkknGbg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- 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%2Bv29Lu3Uhva_Nz3C_ceHPLnYuwqn4twchquv2bLb-yD1dm6wg%40mail.gmail.com.
