For data processing, you often want to just load as much of the data in memory as you can, easily 10s of GB. I'm sure there's some theoretical answer from GC folks about how to handle every situation, but in practice it doesn't usually work out well. GC languages target good performance on "normal" applications, where parameter passing and short-term heap allocations are the biggest memory problems you need to deal with.
For data processing, you often want to just load as much of the data in memory as you can, easily 10s of GB.
In Go, you can write your system, such that the GC doesn't have to get so involved with your objects on the heap. Simply use arrays and slices and avoid using pointers otherwise. Slices contain pointers, but if they are pointing to structs in an array that themselves contain no pointers, then you will greatly minimize GC pressure. I suspect you can use the "unsafe" package in Go to do allocations outside of the GC heap, in which case, the GC will not bother traversing there. However, there is the question of whether you would want to do this, as you are giving up type safety and GC and Go has no other facilities like RAII.
Apparently, programmers at Twitter do tasks of the size you describe with Scala on the Hotspot JVM.
We have large processes like that in the JVM as well, so it's not like we're allergic to garbage collectors. But we do see problems that are not a problem in our C code.
It's possible that Go might have ways of avoiding this, but it would take a while to evaluate and it doesn't offer much in the way of guarantees (i.e. it may change in the future). Unsafe code would be pointless... Might as well use C.
Rust seems to offer memory control, safety, and strong guarantees. That seems more appealing for the problems I work on.
For data processing, you often want to just load as much of the data in memory as you can, easily 10s of GB. I'm sure there's some theoretical answer from GC folks about how to handle every situation, but in practice it doesn't usually work out well. GC languages target good performance on "normal" applications, where parameter passing and short-term heap allocations are the biggest memory problems you need to deal with.