8 ms·

Reading this causes me to experience déjà vu; years and years of reading stories and watching presentations about someone struggling with GC in the JVM. It's h

by topspin 10y ago

Reading this causes me to experience déjà vu; years and years of reading stories and watching presentations about someone struggling with GC in the JVM. It's happening all over again with Go. The same 'discoveries', the same trade-offs, the same discussions about hardware resources, the same 'concurrent mark and sweep', the same 'more to do' conclusions. You could replace every occurrence of 'Go' with 'Java' and it would probably go undiscovered. Maybe it's all worth it and this is how developers are supposed to spend their time, but it's no longer interesting to me.

BinaryIdiot 10y ago
I completely agree and with so much tuning required in past frameworks for their GC it makes me wonder why more don't simply adopt the C++ / Rust models of resource management. I remember way back when people said you couldn't use the JVM for real time applications because of the GC pauses but it's been improved significantly since then and now all the same topics are coming up with GO.
- Skinney 10y ago
  Because the C++/Rust way of memory management is better for some things, but worse for others. I've worked with several different projects during my career, and not once did we require manual memory management. A GC based language was simpler for us to use, and the few times we had problems with GC, they were possible to overcome by writing better code, as is the case with any language. This is not to say that no project benefits heavily form C++/Rust. But I would argue that for many, GC is the best trade off.
  - BinaryIdiot 10y ago
    I'm not sure where you got manual memory management from. I was strictly referring to RAII. Manual memory management is such a pain but the C++ and Rust ways are very similar with RAII.
    - Skinney 10y ago
      I usually refer to everything that isn't GC as 'manual'. RAII is an abstraction on top of manual management, you still need to decide what type of pointer/lifetime the allocated object should have, making it manually managed, IMHO. RAII of course deals with more than just memory, but in a thread about GC I assumed it was memory management you referred to.
  - unscaled 10y ago
    I completely agree that explicit memory management (I wouldn't call it manual) in the C++/Rust way is a cognitive overhead you don't want for a great deal of the software work - perhaps most of it. But there are definitely projects that require explicit memory management, and it's not just games and realtime software. Often high-performance backend code in Java and Go just end up using object pools instead of reallocating objects, just as the OP described. With Go specifically we've seen the rise of fasthttp, which just adds completely manual memory management in the 90's C++ fashion. Want to create a new request object? req := AcquireRequest() req.DoSomething() ReleaseRequest(req) Compare to C++98: Request* req = new Request(); req->DoSomething(); delete req; And now you're back at the same manual memory management problem modern C++ and Rust are striving to solve.
    - kasey_junk 10y ago
      I'd argue that one of the biggest differences between golang and java is not technical but cultural. That is, the golang idioms and thus the std libs are quicker to reach for things like object pools and other performance "hacks". Even the std http library uses an arena in golang. Similarly, high performance Java libraries like the Disruptor, SBE or Chronicle look very much like C code. Personally, that doesn't bother me, as it allows you to write your hot path and your non-optimized path in the same language with the same tooling. says the guy who has split JVMs across processes for performance and contemplated doing it per core
    - Skinney 10y ago
      For what, I would assume, is a minor portion of your total lines of code.
pcwalton 10y ago
> Reading this causes me to experience déjà vu; years and years of reading stories and watching presentations about someone struggling with GC in the JVM. It's happening all over again with Go. It's because GC is an area full of tradeoffs, and despite popular belief, the HotSpot GC is really good. In fact, I honestly don't know of any way to improve on the HotSpot GC for general-purpose use (i.e. throughput/latency balancing). HotSpot has a generational, concurrent, compacting GC; allocation takes 4 or 5 instructions (really!); the compiler has SROA to aggressively optimize out allocations where unneeded.
- SEJeff 10y ago
  Look up the Azul Systems pgc. That is more or less the holy grail, but it is patented out the wazoo, and is a commercial implementation only. Also, the jrockit jvm (which was from BEA and was purchased by Oracle) is actually quite a bit faster than hotspot and easier to introspect (lookup jrockit mission control) than hotspot. I suspect eventually they'll merge however.
  - sievebrain 10y ago
    It's not perfect. Azul's C4 does a lot of work in read barriers, so code that looks intuitively like it should be fast can end up causing "read storms" that bog the code down. C4 never pauses, and that's impressive. But there's no free lunch. The work the GC would do when the app is paused is sometimes being simply done by the app threads instead.
    - jdmichal 10y ago
      There's a certain amount of work that has to be done for GC, and that work is going to be done somewhere. The question is just what trade-offs you want. Don't want compacting? You'll pay for it in allocation. Don't want pausing? You'll pay for it in application threads.
      - pcwalton 10y ago
        Precisely, and this is what is so often missed in these discussions. Most of the time, when you see claims of GC silver bullets, there's some hidden downside that's being papered over. Latency wins (i.e. "max pause time" or whatnot) tend to be throughput losses. Less copying results in more fragmentation. Value types can result in more copying, reducing performance over pointer indirections through nursery allocations. And so forth.
loeg 10y ago
Go is Java 2.0, but from Google instead of Sun. At least the syntax is a little nicer and less boilerplated.
- buddhu 10y ago
  So does that mean Go will finally have generics somewhere around version 5?
  - fishnchips 10y ago
    Fingers crossed for the Hindley–Milner type system.
  - egeozcan 10y ago
    Even maybe algebraic data types? One can keep dreaming.
- fishnchips 10y ago
  I sincerely hope Go does not go in that direction. The 'less is more' approach is so far very strong among the Go steering committee.
  - spriggan3 10y ago
    > I sincerely hope Go does not go in that direction. The 'less is more' approach is so far very strong among the Go steering committee. There is no "less is more" approach in Go. It's more like you can't write something really complex in Go so people use it for trivial things like servers that do almost nothing aside from de-serializing JSON. Try write a large LOB app in pure Go or a fully featured CRM. And see if you can get away with "less is more" when you need to reason about complex business rules, data validation, complex routing, mapping RDBMS data to values, and what not. "less is more" is a mirage. Go short comings will show up pretty fast.
    - fishnchips 10y ago
      All you're really saying is that Go is not great for web apps. I admit, it is not. So is C. I would not write a CRM in either of these languages. At codebeat (codebeat.co) we use Go for our backend - very CPU-heavy, complex static analysis workflows. Our frontend is in Rails which is not ideal but probably the best bang for the buck for an early stage startup. This is the beauty of having many tools to choose from.
vardump 10y ago
Are the number of garbage objects generated by idiomatic Go and idiomatic Java comparable? My guess is Go implementation will produce an order of magnitude less garbage. In Go, an array of structs (= objects) is just one object. In Java, an array of objects is array object itself plus one object for each value in the array. Except for elementary types, like bool, int, long, etc.
arcticbull 10y ago
It's because GC is a bad idea that's had 30 years of good research thrown after it. Advancing GC is building a faster horse instead of stepping back and building a car. It's time to move on, and I'm thrilled to see modern languages (Swift, Rust) abandoning it and focusing on building more intelligent compilers. The goal shouldn't ever be to make the world's best GC, it should be to create the world's best way to elide lifetimes so that developers don't have to think about memory management. GC shouldn't be a goal, it's a technique for solving a problem, one of many that we should explore.
- aserafini 10y ago
  Seems like the opposite surely? We should be developing languages that more succinctly address the problems we humans are trying to solve not book keeping for the computer's hardware (that should be the computers job!).
  - weberc2 10y ago
    I think you missed the bit where he said "more intelligent compiler". The compiler is the bit that does the bookkeeping, only in Rust (and evidently Swift--I haven't played with it much) it's done statically, ahead of time rather than at runtime. That said, I think Go is a much more practical language than Rust for most problems. That said, I'm still very excited about Rust.
    - arcticbull 10y ago
      Yeah, that's exactly what I was trying to say. Rust does all the bookkeeping at compile time, Swift keeps a lot of it at run-time although the compiler can easily optimize away a lot of lifecycle stuff too when it's in scope, so I assume it either does or will. I agree that Rust likely does not have the be-all answer to automatic memory management, though what I love about it is that they're pushing the boundaries and getting people thinking differently about memory management.
      - weberc2 10y ago
coldtea 10y ago
>Maybe it's all worth it and this is how developers are supposed to spend their time, but it's no longer interesting to me. Unless you design and implement GCs yourself, it's not supposed to be interesting to you anyway. It's just something that will benefit users of the language, not something to excite them.
- topspin 10y ago
  If it's not supposed to be interesting, why do so many that have found themselves running up against the limits of GC in their chosen language/platform/implementation end up writing epic blog posts that represent months or years of work and/or presenting their hard one solutions at conferences? There certainly seems to be a lot of people that end up having to be very interested in solving their GC problems once their systems grow to non-trivial size, and they all seem to be relearning and resolving the same set of problems.
  - coldtea 10y ago
    >If it's not supposed to be interesting, why do so many that have found themselves running up against the limits of GC in their chosen language/platform/implementation end up writing epic blog posts that represent months or years of work and/or presenting their hard one solutions at conferences? Because they care about improving actual, existing, languages, with actual, existing, ecosystems, not doing cutting edge academic memory management research. >and they all seem to be relearning and resolving the same set of problems. So like architects relearn and resolve the same problems, about building bridges, skyscrapers, condos etc -- instead of designing some new structures to replace them?

by topspin 10y ago

BinaryIdiot 10y ago

I completely agree and with so much tuning required in past frameworks for their GC it makes me wonder why more don't simply adopt the C++ / Rust models of resource management. I remember way back when people said you couldn't use the JVM for real time applications because of the GC pauses but it's been improved significantly since then and now all the same topics are coming up with GO.

Skinney 10y ago
Because the C++/Rust way of memory management is better for some things, but worse for others. I've worked with several different projects during my career, and not once did we require manual memory management. A GC based language was simpler for us to use, and the few times we had problems with GC, they were possible to overcome by writing better code, as is the case with any language. This is not to say that no project benefits heavily form C++/Rust. But I would argue that for many, GC is the best trade off.
- BinaryIdiot 10y ago
  I'm not sure where you got manual memory management from. I was strictly referring to RAII. Manual memory management is such a pain but the C++ and Rust ways are very similar with RAII.
  - Skinney 10y ago
    I usually refer to everything that isn't GC as 'manual'. RAII is an abstraction on top of manual management, you still need to decide what type of pointer/lifetime the allocated object should have, making it manually managed, IMHO. RAII of course deals with more than just memory, but in a thread about GC I assumed it was memory management you referred to.
- unscaled 10y ago
  I completely agree that explicit memory management (I wouldn't call it manual) in the C++/Rust way is a cognitive overhead you don't want for a great deal of the software work - perhaps most of it. But there are definitely projects that require explicit memory management, and it's not just games and realtime software. Often high-performance backend code in Java and Go just end up using object pools instead of reallocating objects, just as the OP described. With Go specifically we've seen the rise of fasthttp, which just adds completely manual memory management in the 90's C++ fashion. Want to create a new request object? req := AcquireRequest() req.DoSomething() ReleaseRequest(req) Compare to C++98: Request* req = new Request(); req->DoSomething(); delete req; And now you're back at the same manual memory management problem modern C++ and Rust are striving to solve.
  - kasey_junk 10y ago
    I'd argue that one of the biggest differences between golang and java is not technical but cultural. That is, the golang idioms and thus the std libs are quicker to reach for things like object pools and other performance "hacks". Even the std http library uses an arena in golang. Similarly, high performance Java libraries like the Disruptor, SBE or Chronicle look very much like C code. Personally, that doesn't bother me, as it allows you to write your hot path and your non-optimized path in the same language with the same tooling. says the guy who has split JVMs across processes for performance and contemplated doing it per core
  - Skinney 10y ago
    For what, I would assume, is a minor portion of your total lines of code.

pcwalton 10y ago

> Reading this causes me to experience déjà vu; years and years of reading stories and watching presentations about someone struggling with GC in the JVM. It's happening all over again with Go. It's because GC is an area full of tradeoffs, and despite popular belief, the HotSpot GC is really good. In fact, I honestly don't know of any way to improve on the HotSpot GC for general-purpose use (i.e. throughput/latency balancing). HotSpot has a generational, concurrent, compacting GC; allocation takes 4 or 5 instructions (really!); the compiler has SROA to aggressively optimize out allocations where unneeded.

SEJeff 10y ago
Look up the Azul Systems pgc. That is more or less the holy grail, but it is patented out the wazoo, and is a commercial implementation only. Also, the jrockit jvm (which was from BEA and was purchased by Oracle) is actually quite a bit faster than hotspot and easier to introspect (lookup jrockit mission control) than hotspot. I suspect eventually they'll merge however.
- sievebrain 10y ago
  It's not perfect. Azul's C4 does a lot of work in read barriers, so code that looks intuitively like it should be fast can end up causing "read storms" that bog the code down. C4 never pauses, and that's impressive. But there's no free lunch. The work the GC would do when the app is paused is sometimes being simply done by the app threads instead.
  - jdmichal 10y ago
    There's a certain amount of work that has to be done for GC, and that work is going to be done somewhere. The question is just what trade-offs you want. Don't want compacting? You'll pay for it in allocation. Don't want pausing? You'll pay for it in application threads.
    - pcwalton 10y ago
      Precisely, and this is what is so often missed in these discussions. Most of the time, when you see claims of GC silver bullets, there's some hidden downside that's being papered over. Latency wins (i.e. "max pause time" or whatnot) tend to be throughput losses. Less copying results in more fragmentation. Value types can result in more copying, reducing performance over pointer indirections through nursery allocations. And so forth.

loeg 10y ago

Go is Java 2.0, but from Google instead of Sun. At least the syntax is a little nicer and less boilerplated.

buddhu 10y ago
So does that mean Go will finally have generics somewhere around version 5?
- fishnchips 10y ago
  Fingers crossed for the Hindley–Milner type system.
- egeozcan 10y ago
  Even maybe algebraic data types? One can keep dreaming.
fishnchips 10y ago
I sincerely hope Go does not go in that direction. The 'less is more' approach is so far very strong among the Go steering committee.
- spriggan3 10y ago
  > I sincerely hope Go does not go in that direction. The 'less is more' approach is so far very strong among the Go steering committee. There is no "less is more" approach in Go. It's more like you can't write something really complex in Go so people use it for trivial things like servers that do almost nothing aside from de-serializing JSON. Try write a large LOB app in pure Go or a fully featured CRM. And see if you can get away with "less is more" when you need to reason about complex business rules, data validation, complex routing, mapping RDBMS data to values, and what not. "less is more" is a mirage. Go short comings will show up pretty fast.
  - fishnchips 10y ago
    All you're really saying is that Go is not great for web apps. I admit, it is not. So is C. I would not write a CRM in either of these languages. At codebeat (codebeat.co) we use Go for our backend - very CPU-heavy, complex static analysis workflows. Our frontend is in Rails which is not ideal but probably the best bang for the buck for an early stage startup. This is the beauty of having many tools to choose from.

vardump 10y ago

Are the number of garbage objects generated by idiomatic Go and idiomatic Java comparable? My guess is Go implementation will produce an order of magnitude less garbage. In Go, an array of structs (= objects) is just one object. In Java, an array of objects is array object itself plus one object for each value in the array. Except for elementary types, like bool, int, long, etc.

arcticbull 10y ago

It's because GC is a bad idea that's had 30 years of good research thrown after it. Advancing GC is building a faster horse instead of stepping back and building a car. It's time to move on, and I'm thrilled to see modern languages (Swift, Rust) abandoning it and focusing on building more intelligent compilers. The goal shouldn't ever be to make the world's best GC, it should be to create the world's best way to elide lifetimes so that developers don't have to think about memory management. GC shouldn't be a goal, it's a technique for solving a problem, one of many that we should explore.

aserafini 10y ago
Seems like the opposite surely? We should be developing languages that more succinctly address the problems we humans are trying to solve not book keeping for the computer's hardware (that should be the computers job!).
- weberc2 10y ago
  I think you missed the bit where he said "more intelligent compiler". The compiler is the bit that does the bookkeeping, only in Rust (and evidently Swift--I haven't played with it much) it's done statically, ahead of time rather than at runtime. That said, I think Go is a much more practical language than Rust for most problems. That said, I'm still very excited about Rust.
  - arcticbull 10y ago
    Yeah, that's exactly what I was trying to say. Rust does all the bookkeeping at compile time, Swift keeps a lot of it at run-time although the compiler can easily optimize away a lot of lifecycle stuff too when it's in scope, so I assume it either does or will. I agree that Rust likely does not have the be-all answer to automatic memory management, though what I love about it is that they're pushing the boundaries and getting people thinking differently about memory management.
    - weberc2 10y ago

coldtea 10y ago

>Maybe it's all worth it and this is how developers are supposed to spend their time, but it's no longer interesting to me. Unless you design and implement GCs yourself, it's not supposed to be interesting to you anyway. It's just something that will benefit users of the language, not something to excite them.

topspin 10y ago
If it's not supposed to be interesting, why do so many that have found themselves running up against the limits of GC in their chosen language/platform/implementation end up writing epic blog posts that represent months or years of work and/or presenting their hard one solutions at conferences? There certainly seems to be a lot of people that end up having to be very interested in solving their GC problems once their systems grow to non-trivial size, and they all seem to be relearning and resolving the same set of problems.
- coldtea 10y ago
  >If it's not supposed to be interesting, why do so many that have found themselves running up against the limits of GC in their chosen language/platform/implementation end up writing epic blog posts that represent months or years of work and/or presenting their hard one solutions at conferences? Because they care about improving actual, existing, languages, with actual, existing, ecosystems, not doing cutting edge academic memory management research. >and they all seem to be relearning and resolving the same set of problems. So like architects relearn and resolve the same problems, about building bridges, skyscrapers, condos etc -- instead of designing some new structures to replace them?