6 ms·

I'm not such a lover of Go, but: non-sarcastically, Go may well have been a good choice.

amalcon 7y ago
> Lennart Poettering and Kay Sievers started the project to develop systemd in 2010. https://en.wikipedia.org/wiki/Systemd#History https://en.wikipedia.org/wiki/Systemd#History > Go was publicly announced in November 2009,[29] and version 1.0 was released in March 2012. https://en.wikipedia.org/wiki/Go_(programming_language)#History https://en.wikipedia.org/wiki/Go_(programming_language)#Hist... The brand-new language that Google just announced last year was probably not considered a serious option here.
- loeg 7y ago
  It's 2019 and Go still has a much weaker toolchain and infrastructure story than C (which has a 30 year head start).
- sanderjd 7y ago
  Ha yeah, I didn't mean "they really should have used Go", I just meant, "Go as it exists today may be a good thing to use for this".
masklinn 7y ago
Given the timeframe, something like OCaml would likely have been a better option.
- szemet 7y ago
  Ocaml parallelism/concurrency story was not that good - but Haskell has just got its fancy new epoll based I/O manager (100000+ lightweight threads) around that time, with the 7.0.1 release (16 November 2010) They could have even take inspiration, imagine: typed, functional, monadic init files - "systemd: avoid success at all costs" :)
  - astrobe_ 7y ago
    The topic is memory safety, not concurrency support, FWIW. Lua would have been a good candidate: memory safe, coroutine to structure the code in a concurrent-ish way if needed, and you have a configuration file parser for free (just use Lua as the configuration language, it was its very first purpose after all).
  - masklinn 7y ago
    > Ocaml parallelism/concurrency story was not that good I wouldn't expect CPU-bound multithreading to be much of a concern in an init/rc system. And resource thriftiness and predictability would likely be a bigger concern.
  - the_why_of_y 7y ago
    While that would be amusing for sure, systemd's pid 1 is actually single threaded.
  - ernst_klim 7y ago
    >Ocaml parallelism/concurrency story was not that good OCaml concurrency is great, and Lwt [1] would be exactly what systemd need: run daemon and poll the answer concurrently. Ada, C++ and D would have been another great choices. [1] https://github.com/ocsigen/lwt https://github.com/ocsigen/lwt
  - m4rtink 7y ago
    That's nice in theory, but where are all the people who know Ocaml to write it and contribute to it ? I might be clueless but I can't really name any significant projects written in it, which might imply something about the number of people using it and being able to work on and contribute to something as large and important as systemd.
    - ernst_klim 7y ago
      >I might be clueless but I can't really name any significant projects written in it From system programming solely: libguestfs, Xen API, liquidsoap, Unison, MirageOS, google drive on fuse, 0install.

> Lennart Poettering and Kay Sievers started the project to develop systemd in 2010. https://en.wikipedia.org/wiki/Systemd#History https://en.wikipedia.org/wiki/Systemd#History > Go was publicly announced in November 2009,[29] and version 1.0 was released in March 2012. https://en.wikipedia.org/wiki/Go_(programming_language)#History https://en.wikipedia.org/wiki/Go_(programming_language)#Hist... The brand-new language that Google just announced last year was probably not considered a serious option here.

loeg 7y ago
It's 2019 and Go still has a much weaker toolchain and infrastructure story than C (which has a 30 year head start).
sanderjd 7y ago
Ha yeah, I didn't mean "they really should have used Go", I just meant, "Go as it exists today may be a good thing to use for this".

masklinn 7y ago

Given the timeframe, something like OCaml would likely have been a better option.

szemet 7y ago
Ocaml parallelism/concurrency story was not that good - but Haskell has just got its fancy new epoll based I/O manager (100000+ lightweight threads) around that time, with the 7.0.1 release (16 November 2010) They could have even take inspiration, imagine: typed, functional, monadic init files - "systemd: avoid success at all costs" :)
- astrobe_ 7y ago
  The topic is memory safety, not concurrency support, FWIW. Lua would have been a good candidate: memory safe, coroutine to structure the code in a concurrent-ish way if needed, and you have a configuration file parser for free (just use Lua as the configuration language, it was its very first purpose after all).
- masklinn 7y ago
  > Ocaml parallelism/concurrency story was not that good I wouldn't expect CPU-bound multithreading to be much of a concern in an init/rc system. And resource thriftiness and predictability would likely be a bigger concern.
- the_why_of_y 7y ago
  While that would be amusing for sure, systemd's pid 1 is actually single threaded.
- ernst_klim 7y ago
  >Ocaml parallelism/concurrency story was not that good OCaml concurrency is great, and Lwt [1] would be exactly what systemd need: run daemon and poll the answer concurrently. Ada, C++ and D would have been another great choices. [1] https://github.com/ocsigen/lwt https://github.com/ocsigen/lwt
- m4rtink 7y ago
  That's nice in theory, but where are all the people who know Ocaml to write it and contribute to it ? I might be clueless but I can't really name any significant projects written in it, which might imply something about the number of people using it and being able to work on and contribute to something as large and important as systemd.
  - ernst_klim 7y ago
    >I might be clueless but I can't really name any significant projects written in it From system programming solely: libguestfs, Xen API, liquidsoap, Unison, MirageOS, google drive on fuse, 0install.