8 ms·

Do you actually follow Go development? 1.5 is a major improvement to the GC. The only other stable release that had any change to the GC worthy of mention in t

Do you actually follow Go development? 1.5 is a major improvement to the GC. The only other stable release that had any change to the GC worthy of mention in the release notes was 1.3, which was a minor change. The only possible way to interpret your statement as true, would be if "get solved" meant ANY change or bug fix was applied to the GC. Which is a statement that would apply to so much code (not just the GC) that it would make the statement completely meaningless.

AlphaSite 11y ago
It think he means people tout every release as the final solution to their GC issues. Not officially, necessarily, but some vocal group says it.
- rgbrenner 11y ago
  That's not true either though. Seriously go take a look at the release announcements on hackernews.
  - Alphasite_ 11y ago
    I never said it was.
joosters 11y ago
Yeah, I'm being unfair in naming Go & Java specifically. But these stories of 'fixing' garbage collection come up all too often. I wonder when we'll see a further GC update that trades latency for throughput... The problem seems to be that no matter how you tweak GC, you will always have a class of program that it performs terribly for (and it seems to impact a large group of programs, never just some obscure corner case). So I suspect that this latest GC tweak will have unexpected results on some other class of program, leading to another tweak, and so on...
- stcredzero 11y ago
  The problem seems to be that no matter how you tweak GC, you will always have a class of program that it performs terribly for For casual use, most programs can treat GC like magic, but if you are doing serious work in a language with GC, then you should learn about the GC's characteristics. That bit of due diligence and up front design effort is still often going to be tons cheaper than doing the manual memory management. Reducing latency in exchange for throughput is the right decision for the vast majority of programs that will be written in Go. It was already a very attractive language for writing a multiplayer game server, so long as I didn't have very large heaps. (Even so, I can still support 150-250 players and 10's of thousands of entities.) With the "tweak," that limitation is much relaxed.
  - banachtarski 11y ago
    > That bit of due diligence and up front design effort is still often going to be tons cheaper than doing the manual memory management. Calling shenanigans. No it's not, unless the person doing the manual solution is a novice.
    - stcredzero 11y ago
      It's not the writing of manual memory management in the usual case/happy path that's the problem. It's the very occasional mistake and the debugging time involved. (Though to be fair, automated static analysis tools have taken great strides, and this is not as big a problem as it used to be.) What GC often gets you is a program that doesn't crash but instead has performance problems, but these are often more easily profiled and found and less severe than a crash. (Manual memory management isn't immune from the same performance problems in any case.) In other words, GC gets you to "Step 1 -- Get it Correct" faster so you can play with running code faster. The cost/benefit may not fit your situation. In that case, use a different tool.
    - pascal_cuoq 11y ago
      Despite the drastic page limit in the category I was submitting in, I made sure to include a paragraph about how GC enable sharing and how the only reasonable alternative when implementing a similar system in a non-GC language is a lot of gratuitous copying to solve ownership issues in http://frama-c.com/u3cat/download/CuoqICFP09.pdf http://frama-c.com/u3cat/download/CuoqICFP09.pdf (The page limit was 4. Organizers only raised it to 6 after seeing submitted papers.) I can also confirm the “bit of due diligence” part, and the fact that it's cheaper that the aggravation of not having memory management at all. In the example that I can contribute to the discussion, the due diligence amounted to two more short articles: http://cristal.inria.fr/~doligez/publications/cuoq-doligez-mlw-2008.pdf http://cristal.inria.fr/~doligez/publications/cuoq-doligez-m... and http://blog.frama-c.com/public/unmarshal.pdf http://blog.frama-c.com/public/unmarshal.pdf
1wd 11y ago
What about 1.4? "The release focuses primarily on implementation work, improving the garbage collector ..." https://golang.org/doc/go1.4 https://golang.org/doc/go1.4
- jlouis 11y ago
  1.4 focused on getting the GC ready for the changes in 1.5. First, the code was rewritten from C to Go. Second, the GC was made precise, which is a major improvement to a GC. The GC was not made truly concurrent however, and short pause times were not addressed either. These concerns are addressed in the 1.5 release. The trade-off in 1.5 is to eliminate pause times for slightly worse throughput. For the programs Go is written to handle, this trade-off is probably fine.

AlphaSite 11y ago

It think he means people tout every release as the final solution to their GC issues. Not officially, necessarily, but some vocal group says it.

rgbrenner 11y ago
That's not true either though. Seriously go take a look at the release announcements on hackernews.
- Alphasite_ 11y ago
  I never said it was.

joosters 11y ago

Yeah, I'm being unfair in naming Go & Java specifically. But these stories of 'fixing' garbage collection come up all too often. I wonder when we'll see a further GC update that trades latency for throughput... The problem seems to be that no matter how you tweak GC, you will always have a class of program that it performs terribly for (and it seems to impact a large group of programs, never just some obscure corner case). So I suspect that this latest GC tweak will have unexpected results on some other class of program, leading to another tweak, and so on...

stcredzero 11y ago
The problem seems to be that no matter how you tweak GC, you will always have a class of program that it performs terribly for For casual use, most programs can treat GC like magic, but if you are doing serious work in a language with GC, then you should learn about the GC's characteristics. That bit of due diligence and up front design effort is still often going to be tons cheaper than doing the manual memory management. Reducing latency in exchange for throughput is the right decision for the vast majority of programs that will be written in Go. It was already a very attractive language for writing a multiplayer game server, so long as I didn't have very large heaps. (Even so, I can still support 150-250 players and 10's of thousands of entities.) With the "tweak," that limitation is much relaxed.
- banachtarski 11y ago
  > That bit of due diligence and up front design effort is still often going to be tons cheaper than doing the manual memory management. Calling shenanigans. No it's not, unless the person doing the manual solution is a novice.
  - stcredzero 11y ago
    It's not the writing of manual memory management in the usual case/happy path that's the problem. It's the very occasional mistake and the debugging time involved. (Though to be fair, automated static analysis tools have taken great strides, and this is not as big a problem as it used to be.) What GC often gets you is a program that doesn't crash but instead has performance problems, but these are often more easily profiled and found and less severe than a crash. (Manual memory management isn't immune from the same performance problems in any case.) In other words, GC gets you to "Step 1 -- Get it Correct" faster so you can play with running code faster. The cost/benefit may not fit your situation. In that case, use a different tool.
  - pascal_cuoq 11y ago
    Despite the drastic page limit in the category I was submitting in, I made sure to include a paragraph about how GC enable sharing and how the only reasonable alternative when implementing a similar system in a non-GC language is a lot of gratuitous copying to solve ownership issues in http://frama-c.com/u3cat/download/CuoqICFP09.pdf http://frama-c.com/u3cat/download/CuoqICFP09.pdf (The page limit was 4. Organizers only raised it to 6 after seeing submitted papers.) I can also confirm the “bit of due diligence” part, and the fact that it's cheaper that the aggravation of not having memory management at all. In the example that I can contribute to the discussion, the due diligence amounted to two more short articles: http://cristal.inria.fr/~doligez/publications/cuoq-doligez-mlw-2008.pdf http://cristal.inria.fr/~doligez/publications/cuoq-doligez-m... and http://blog.frama-c.com/public/unmarshal.pdf http://blog.frama-c.com/public/unmarshal.pdf

1wd 11y ago

What about 1.4? "The release focuses primarily on implementation work, improving the garbage collector ..." https://golang.org/doc/go1.4 https://golang.org/doc/go1.4

jlouis 11y ago
1.4 focused on getting the GC ready for the changes in 1.5. First, the code was rewritten from C to Go. Second, the GC was made precise, which is a major improvement to a GC. The GC was not made truly concurrent however, and short pause times were not addressed either. These concerns are addressed in the 1.5 release. The trade-off in 1.5 is to eliminate pause times for slightly worse throughput. For the programs Go is written to handle, this trade-off is probably fine.