7 ms·

I actually disagree. If you look at the code written in the article, it's hardly unreadable or very code golf-y as you suggest. I think the author is really jus

I actually disagree. If you look at the code written in the article, it's hardly unreadable or very code golf-y as you suggest. I think the author is really just trying to say that programmers shouldn't dismiss Go as a possible systems language in favor of C just because C has a reputation of being faster in all cases.

dijit 7y ago
Are we really saying a garbage collected language should be considered for a systems language? I know the GC is fast but surely memory managed languages are going to have less issues with pausing during execution, no?
- zenhack 7y ago
  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().
- IshKebab 7y ago
  In the sense that the Go authors used "systems language", i.e. for writing things like servers and command line tools, sure why not? Go's GC pauses are extremely short (under 1ms). That shouldn't really affect much.
  - crematoria 7y ago
    Source? People write CLI tools in Ruby and Node.js these days, so I really doubt that anybody would use the term "systems language" to refer to languages well-suited to building CLI tools.
    - IshKebab 7y ago
      https://www.wired.com/2009/11/google-announces-a-new-programming-language-google-go/ https://www.wired.com/2009/11/google-announces-a-new-program... > As a systems language, Go is intended to be used for developer applications like, for example, web servers. Couldn't find a citation for CLI tools, but that should satisfy you (since people write web servers in Ruby and Node.js too).
- weberc2 7y ago
  As others mentioned "systems language" isn't well defined. If you want to define a "systems program" as one with hard real-time requirements, then no, Go isn't a very good choice; however, the article defines it differently (such that `wc` satisfies), and demonstrates that Go satisfies that definition. That said, it's better to use terms that map better to a set of requirements, such as "hard-realtime" or "soft-realtime".
- pjmlp 7y ago
  Yes, as proven multiple times, and being pushed forward by the likes of Apple, Google and Microsoft. Regarding using Go as a real systems language (in the same meaning as C): - gVisor hypervisor on Google Cloud and Linux sandbox on Chromebooks - Android GPGPU debugger - Fuchsia TCP/IP stack and volume management - Baremetal TinyGo on Arduino Nano33 IoT, Adafruit Circuit Playground Express, BBC micro:bit among many others - Coreboot firmware
  - dijit 7y ago
    Coreboot is C/ASM though.
- rurban 7y ago
  Esp. as a systems language. Safety first.
- agumonkey 7y ago
  I think there are already a few gc/jitted components in mainstream kernels (bpf, lua drivers). So in some points, it's not a crazy idea. Now I don't advocate for Java drivers.
saghm 7y ago
I'm not sure this proves that Go is a possible systems language, since it could be equally like that the explanation is just "wc doesn't need to be written in a systems language to be fast". For an executable that runs, processes some stuff, and then terminates in the span of a second or so, you're not going to incur much slowdown due to a GC counting references and cleaning stuff up, but for something long-running, it could make more of a difference.

dijit 7y ago

Are we really saying a garbage collected language should be considered for a systems language? I know the GC is fast but surely memory managed languages are going to have less issues with pausing during execution, no?

zenhack 7y ago
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().
IshKebab 7y ago
In the sense that the Go authors used "systems language", i.e. for writing things like servers and command line tools, sure why not? Go's GC pauses are extremely short (under 1ms). That shouldn't really affect much.
- crematoria 7y ago
  Source? People write CLI tools in Ruby and Node.js these days, so I really doubt that anybody would use the term "systems language" to refer to languages well-suited to building CLI tools.
  - IshKebab 7y ago
    https://www.wired.com/2009/11/google-announces-a-new-programming-language-google-go/ https://www.wired.com/2009/11/google-announces-a-new-program... > As a systems language, Go is intended to be used for developer applications like, for example, web servers. Couldn't find a citation for CLI tools, but that should satisfy you (since people write web servers in Ruby and Node.js too).
weberc2 7y ago
As others mentioned "systems language" isn't well defined. If you want to define a "systems program" as one with hard real-time requirements, then no, Go isn't a very good choice; however, the article defines it differently (such that `wc` satisfies), and demonstrates that Go satisfies that definition. That said, it's better to use terms that map better to a set of requirements, such as "hard-realtime" or "soft-realtime".
pjmlp 7y ago
Yes, as proven multiple times, and being pushed forward by the likes of Apple, Google and Microsoft. Regarding using Go as a real systems language (in the same meaning as C): - gVisor hypervisor on Google Cloud and Linux sandbox on Chromebooks - Android GPGPU debugger - Fuchsia TCP/IP stack and volume management - Baremetal TinyGo on Arduino Nano33 IoT, Adafruit Circuit Playground Express, BBC micro:bit among many others - Coreboot firmware
- dijit 7y ago
  Coreboot is C/ASM though.
rurban 7y ago
Esp. as a systems language. Safety first.
agumonkey 7y ago
I think there are already a few gc/jitted components in mainstream kernels (bpf, lua drivers). So in some points, it's not a crazy idea. Now I don't advocate for Java drivers.

saghm 7y ago

I'm not sure this proves that Go is a possible systems language, since it could be equally like that the explanation is just "wc doesn't need to be written in a systems language to be fast". For an executable that runs, processes some stuff, and then terminates in the span of a second or so, you're not going to incur much slowdown due to a GC counting references and cleaning stuff up, but for something long-running, it could make more of a difference.