5 ms·
Java is not really a great choice because you need a JVM for the task at hand. Python is not a good choice because of concurrency constructs, and it's clear tha
by xemdetia 10y ago
Java is not really a great choice because you need a JVM for the task at hand. Python is not a good choice because of concurrency constructs, and it's clear that the goal of this was to self-contain the whole thing and not have fringe packages in a semi-direct port from C to a different language. For a raw systems daemon that needs to run on mostly everything being coupled to only one runtime is a huge boon for portability.
- gok 10y agoThat disqualifies Go even more so. You could easily embed a competent JVM in the space a typical Go binary requires to embed all its libraries (the "docker" binary I'm looking at is 13 MB). Go's "Hello, world" is well over a megabyte.
- xemdetia 10y agoThe critical feature here is that the resulting Go binary is whole and complete and tightly coupled to the system at hand, which fits more the output from Rust or C. Inherently Java software is dependent on two runtimes, the JVM and the core libraries the JVM is compiled against. Space isn't the most critical concern here, it is portability and bringing a JVM everywhere is really painful and really a project well outside the goals of the software described. If a JVM was going to be considered a solution this project would have to package the JVM and the daemon which would be silly.