4 ms·

Re: pause times, Go's garbage collector is actually really good here; you're looking at 10s of microseconds. I'm convinced the term "systems language" doesn't

Re: pause times, Go's garbage collector is actually really good here; you're looking at 10s of microseconds. I'm convinced the term "systems language" doesn't have a coherent meaning at this point. See: https://zenhack.net/2018/07/14/three-funerals-in-the-name-of-clarity-3-systems.html https://zenhack.net/2018/07/14/three-funerals-in-the-name-of...

pleasecalllater 7y ago
I always thought the GC pause depends on the heap size... a little searching... http://big-elephants.com/2018-09/unexpected-gc-pauses/ http://big-elephants.com/2018-09/unexpected-gc-pauses/.
- naikrovek 7y ago
  It depends on how many things need to be collected, which is often a function of heap size.
__d 7y ago
Right, so when I’m trying to process a network packet in about a microsecond (a reasonable target for financial trading software), Go’s GC rules it out. Many low-level, high-performance systems language tasks aren’t feasible in Go for similar reasons. That doesn’t make it a bad language, but it’s not universally applicable either.
- crematoria 7y ago
  Strange. I know OCaml is used in HFT (thanks to all those Jane Street ads) and OCaml is also GC'd. What does OCaml have here that Go doesn't?
- zenhack 7y ago
  > but it’s not universally applicable either. Nothing is universally applicable. But yeah, I certainly wouldn't use it for hard real-time tasks. If you can't tolerate missing deadlines ever, there is a very short list of acceptable tools. But (and correct me if I'm wrong; it's not my area) HFT doesn't strike me as hard real-time? See also a sibling comment that asks about Jane Street's OCaml use. It's not like GC pauses are happening constantly; Go programs don't allocate that much, and a well tuned program can go a long time between collections. It likely is appropriate for many soft or firm real time systems. And you can shut the GC off if there are sections where GC really must not happen: https://golang.org/pkg/runtime/debug/#SetGCPercent https://golang.org/pkg/runtime/debug/#SetGCPercent
  - __d 7y ago
    That's how those who use Java do it: write their code to minimize allocations, and then configure the JVM with a GC threshold that's bigger than their whole day's allocations, and manually GC at a suitable time. Last I looked (a while ago) it seemed like there wasn't quite enough control on the Go GC to do this effectively. It's very likely that's been fixed by now.
- pjmlp 7y ago
  Just like in hard real time systems using malloc() rules C out, and its use is explicitly forbidden in certification processes. I guess C isn't universally applicable either.
  - Gibbon1 7y ago
    The difference is, you can write perfectly usable programs in C without littering the codebase with malloc() and free().
    - pjmlp 7y ago
      Just like you can in Go, as proven by TinyGo. Or in dozen of other GC enabled systems programming languages for that matter.
      - Gibbon1 7y ago
        Tip: Give up dude.
        pjmlp 7y ago
        Exactly my tip to the anti-GC luddites. The difference being evolution, takes care of sorting that out, like in all anti-technology groups throughout mankind history.
        Gibbon1 7y ago
        Seem seem to have a personal issue with this.
        pjmlp 7y ago
        To the extent that my work is open to memory corruption security exploits, with possible high monetary costs, caused by anti-GC luddites. https://googleprojectzero.blogspot.com/2019/11/bad-binder-android-in-wild-exploit.html https://googleprojectzero.blogspot.com/2019/11/bad-binder-an...

pleasecalllater 7y ago

I always thought the GC pause depends on the heap size... a little searching... http://big-elephants.com/2018-09/unexpected-gc-pauses/ http://big-elephants.com/2018-09/unexpected-gc-pauses/.

naikrovek 7y ago
It depends on how many things need to be collected, which is often a function of heap size.

__d 7y ago

Right, so when I’m trying to process a network packet in about a microsecond (a reasonable target for financial trading software), Go’s GC rules it out. Many low-level, high-performance systems language tasks aren’t feasible in Go for similar reasons. That doesn’t make it a bad language, but it’s not universally applicable either.

crematoria 7y ago
Strange. I know OCaml is used in HFT (thanks to all those Jane Street ads) and OCaml is also GC'd. What does OCaml have here that Go doesn't?
zenhack 7y ago
> but it’s not universally applicable either. Nothing is universally applicable. But yeah, I certainly wouldn't use it for hard real-time tasks. If you can't tolerate missing deadlines ever, there is a very short list of acceptable tools. But (and correct me if I'm wrong; it's not my area) HFT doesn't strike me as hard real-time? See also a sibling comment that asks about Jane Street's OCaml use. It's not like GC pauses are happening constantly; Go programs don't allocate that much, and a well tuned program can go a long time between collections. It likely is appropriate for many soft or firm real time systems. And you can shut the GC off if there are sections where GC really must not happen: https://golang.org/pkg/runtime/debug/#SetGCPercent https://golang.org/pkg/runtime/debug/#SetGCPercent
- __d 7y ago
  That's how those who use Java do it: write their code to minimize allocations, and then configure the JVM with a GC threshold that's bigger than their whole day's allocations, and manually GC at a suitable time. Last I looked (a while ago) it seemed like there wasn't quite enough control on the Go GC to do this effectively. It's very likely that's been fixed by now.
pjmlp 7y ago
Just like in hard real time systems using malloc() rules C out, and its use is explicitly forbidden in certification processes. I guess C isn't universally applicable either.
- Gibbon1 7y ago
  The difference is, you can write perfectly usable programs in C without littering the codebase with malloc() and free().
  - pjmlp 7y ago
    Just like you can in Go, as proven by TinyGo. Or in dozen of other GC enabled systems programming languages for that matter.
    - Gibbon1 7y ago
      Tip: Give up dude.
      - pjmlp 7y ago
        Exactly my tip to the anti-GC luddites. The difference being evolution, takes care of sorting that out, like in all anti-technology groups throughout mankind history.
        Gibbon1 7y ago
        Seem seem to have a personal issue with this.
        pjmlp 7y ago
        To the extent that my work is open to memory corruption security exploits, with possible high monetary costs, caused by anti-GC luddites. https://googleprojectzero.blogspot.com/2019/11/bad-binder-android-in-wild-exploit.html https://googleprojectzero.blogspot.com/2019/11/bad-binder-an...