alt Hacker News> We did not want to spend time maintaining a backward compatible parser or doing code archaeology. So this option was discarded.
Considering all of the effort and hoop-jumping involved in the route that was chosen, perhaps this decision might be worth revisiting.
In hindsight, maintaining a parser might be easier and more maintainable when compared to the current problems that were overcome and the future problems that will arise if/when the systemd libraries decide to change their C API interfaces.
One benefit of a freestanding parser is that it could be made into a reusable library that others can use and help maintain.
Replies
That's what I was thinking too. A go native library is 10 times better in the go ecosystem than a c library linked to a go executable.
Also in the age of AI it seems possible to have it do the rewrite for you, for which you can iterate on further.
There is an existing pure Go library [1] written by someone else. The issue is that we weren’t confident we could ship a reliable parser. We even included an excerpt from the systemd documentation, which didn’t exactly reassure us:
> Note that the actual implementation in the systemd codebase is the only ultimately authoritative description of the format, so if this document and the code disagree, the code is right
This required a lot of extra effort and hoop-jumping, but at least it’s on our side rather than something users have to deal with at deploy time.
[1]: https://github.com/Velocidex/go-journalctl