4 ms·

Garbage collection makes Java, C#, and Go remarkably more productive for most programs.

by ori_b 7y ago

AstralStorm 7y ago
Until your memory blows up or the GC stalls become a performance issue you have to solve. And by then it's very hard to fix as it got interwoven in the design of your application. Rust forces you to think about memory use and ownership ahead of time, but after some short practice it really gets out of the way and does not become a problem, while avoiding bad code nasties like interlinked singletons, cyclical references or random shared_ptr held forever. Additionally the explicit memory model makes interacting with C (and often C++) code much more straightforward. Source: had to wrangle that performance issue on Android both in Java and C++. Had to help JVM not stall forever in IntelliJ.
- ori_b 7y ago
  I've done a bunch of performance work. For many applications I've had to speed up, the performance issues were either localized with low hanging fruit, or were architectural, where layers of abstraction led to translations between impedance mismatches throughout the whole application -- transforming an image 4 times between different coordinate spaces before drawing it on the screen does not make for a fast application. A language change isn't going to solve that. GC pauses have almost never been an issue: It's irrelevant for servers. For UI, most code just doesn't end up allocating that much in the UI thread. Yeah, for things like games that do a lot of work and need to update at 120fps, GC can be a problem. I generally don't write that kind of code. I'd really rather have a GC for 90% of all code that I ship.
  - smarterclayton 7y ago
    For Kubernetes in general this has been my experience over the last 5 years (and the year preceding on Docker and other "learning Go" projects). For web style apps with moderate to heavy client complexity (Kube APIs, client libraries) I have appreciated about being able to start with the GC, when we hit a scale cliff go and remove a 5-10 stupid allocation patterns (inlining, value types, removing pointers or replacing with internal index references so the collector ignores them), get another 10x scale from that, then go back and do architectural improvements, get another 10x, then trim some fat around the edges and get another 5x. You definitely hit a wall at some point (comparing the best that you can do in Go with protobuf / JSON relative to say Serde) where the remaining 2-10x efficiency is not achievable. That is where I'd be most interested in generic like constructs in Go where I can type and define down. It's hard to beat the clarity and brevity of Serde - no one in Go has done it at anywhere near the performance.
- Const-me 7y ago
  > but after some short practice it really gets out of the way and does not become a problem It's similar in C#. Once you have some experience writing latency-sensitive .NET code like games or realtime multimedia, GC works quite well in practice because you learn how to write code in a way that doesn't stress the GC too much. People who don't care about latency are still able to get their stuff done.
- s17n 7y ago
  Most modern programs are written to be short lived, so memory leaks aren't a showstopper (just kill the instance if it's a server or refresh the page if it's a client)

Garbage collection makes Java, C#, and Go remarkably more productive for most programs.

by ori_b 7y ago

Garbage collection makes Java, C#, and Go remarkably more productive for most programs.

Until your memory blows up or the GC stalls become a performance issue you have to solve. And by then it's very hard to fix as it got interwoven in the design of your application. Rust forces you to think about memory use and ownership ahead of time, but after some short practice it really gets out of the way and does not become a problem, while avoiding bad code nasties like interlinked singletons, cyclical references or random shared_ptr held forever. Additionally the explicit memory model makes interacting with C (and often C++) code much more straightforward. Source: had to wrangle that performance issue on Android both in Java and C++. Had to help JVM not stall forever in IntelliJ.

ori_b 7y ago
I've done a bunch of performance work. For many applications I've had to speed up, the performance issues were either localized with low hanging fruit, or were architectural, where layers of abstraction led to translations between impedance mismatches throughout the whole application -- transforming an image 4 times between different coordinate spaces before drawing it on the screen does not make for a fast application. A language change isn't going to solve that. GC pauses have almost never been an issue: It's irrelevant for servers. For UI, most code just doesn't end up allocating that much in the UI thread. Yeah, for things like games that do a lot of work and need to update at 120fps, GC can be a problem. I generally don't write that kind of code. I'd really rather have a GC for 90% of all code that I ship.
- smarterclayton 7y ago
  For Kubernetes in general this has been my experience over the last 5 years (and the year preceding on Docker and other "learning Go" projects). For web style apps with moderate to heavy client complexity (Kube APIs, client libraries) I have appreciated about being able to start with the GC, when we hit a scale cliff go and remove a 5-10 stupid allocation patterns (inlining, value types, removing pointers or replacing with internal index references so the collector ignores them), get another 10x scale from that, then go back and do architectural improvements, get another 10x, then trim some fat around the edges and get another 5x. You definitely hit a wall at some point (comparing the best that you can do in Go with protobuf / JSON relative to say Serde) where the remaining 2-10x efficiency is not achievable. That is where I'd be most interested in generic like constructs in Go where I can type and define down. It's hard to beat the clarity and brevity of Serde - no one in Go has done it at anywhere near the performance.
Const-me 7y ago
> but after some short practice it really gets out of the way and does not become a problem It's similar in C#. Once you have some experience writing latency-sensitive .NET code like games or realtime multimedia, GC works quite well in practice because you learn how to write code in a way that doesn't stress the GC too much. People who don't care about latency are still able to get their stuff done.
s17n 7y ago
Most modern programs are written to be short lived, so memory leaks aren't a showstopper (just kill the instance if it's a server or refresh the page if it's a client)