Memory safety is not the alpha and omega of programming languages. People do not write million lines of code applications in bash, for a reason, trade-offs are to be made.
That said I agree they should have picked Go instead /s.
Sure, there are other concerns and bash is not an ideal language, but memory safety is responsible for quite a large number of security flaws, since its lack turns bugs into code execution vulnerabilities on a regular basis.
I don't really have an opinion on what language should have been picked instead, though OCaml may be a good candidate.
I think I know what my next Erlang project's gonna be. Erlang-as-PID-1, here we come!
EDIT: or maybe as PID 2, per https://github.com/omisego/ewallet/issues/108 , though I'd be interested in the idea of writing an OTP application that can reap zombies and forward signals.
> People do not write million lines of code applications in bash, for a reason, trade-offs are to be made.
Isn't that basically what SysVinit and a good-sized chunk of the management tooling in Linux is?
To their credit, Bash is a _weird_ language, but it's not going to corrupt memory when it crashes, and its failure modes are pretty well understood by the distro maintainers writing those scripts.
Those are all not million lines of code applications, but that only speaks in favor of a more traditional Unix userspace design. With modularity on the process level you don't need a million lines of code to herd services. Why an init system should a million lines of code is a mystery to me.
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" :)
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).
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.
> 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.
Rust would have been more appropriate. Something like SystemD at such a low level in terms of hardware and service management should not be done in a language with a garbage collector imho.
I understand that... Go still isn't an appropriate language for SystemD, also, when did SystemD really take hold? Lots of projects will shift underlying options with time.
The only thing that I can think of for that 2019 Go that would be a problem for this use case is binary size. None of the rest of the usual complaints would be stoppers or even that big a deal, and most of them, I'd pay to have a memory-safe language being used at that level. Init systems are a type of code that we don't have a good word for, but that I tend to end up in a lot, the code that isn't CPU intensive, or disk intensive, or RAM intensive, etc., but is all just logic and correctness rather than any of that. So "but Go is GC'ed!" isn't particularly relevant, for instance, because an init system pretty much ought to settle into a steady state and not be executing at all, on average, so who cares about a handful of microsecond GC pauses that may or may not occur at startup time?
Rust might be better now; my primary concern would be community size and whether I was limiting my contributor base, which Go also has as a concern. In both cases though I'd take it over C/C++ being used on such a critical project at this juncture.
I understand there's a much more limited subset of developers for Rust or even Go vs. C/C++. Also, I recall hearing about Rust before systemd, but am not sure. Today, it would probably be my first choice. Not that go is a bad choice, I just don't think it's a good spot for it. I also agree that either are probably quite a bit better than C/C++ options.
I'm not against go, other than gc and some size considerations. Given that a lot of k8s infrastructure for the likes of CoreOS and similar are written in it, it's definitely not a bad option. I think that today, and more so in late summer as async/await syntax settles, that Rust should be a first consideration for any low-level system code.
It doesn't execute low level code in terms of hardware. It's a init system, all it (should do) is create a dependency graph and initialize the services in the correct order.
Many init systems have been created in bash, and I'd hardly call that a low level language.
That said I agree they should have picked Go instead /s.