Two big issues in Golang are that you can't actually build an arena allocator that can be used for multiple types in a natural way.
The other is that almost no library is written in such a way that buffer re-use is possible (looking at you, typical kafka clients that throw off a buffer of garbage per message and protobuf). The latter could be fixed if people paid more attention to returning buffers to the caller.
Rust also suffers from libraries returning a newly allocated strings and vectors when the code should allow to pass a pre-existing string or vector to place the results.
Granted the latter leads to more verbose code and chaining of several calls is no longer possible.
But I am puzzled that even performance-oriented libraries both in Go and Rust still prefer to allocate the results themselves.
The article nor the talk appear to reference the XML standard that EN 16931 is built upon: Universal Business Language, https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=... - which is freely available. Examples can be found here: https://github.com/Tradeshift/tradeshift-ubl-examples/tree/m... . It is a good standard and yes it's complex, but it is not complicated by accident. I would any day recommend UBL over IDOC, Tradacom, EDIFACT and the likes.
This avoids JSON-inside-JSOn and allows to pretty-print the original object with the signature.