We use Kaitai at work, and it seems like quite a clever tool at first glance, but it feels weirder the more I use it.
There's the small stuff: YAML is convenient as a universal language, but it means that declarations are very verbose - you can't use any sort of syntax sugar, you're having l basically writing the underlying AST that a more convenient language would parse to. It's also still YAML, with all the problems that come from that.
I also can't make head nor tail of the IDE. The big selling point is that it can parse test data you provide automatically as you build your Kaitai structure, but you can't edit the test data at all, and last I checked it didn't provide any sort of completion or hinting as you write your parser. So I might as well edit the structure in my editor of choice and occasionally copy it into the IDE if there's something I need to check, except then I also need to generate an interesting binary test case file and upload it, because, like I said, I can't edit those test cases in the IDE.
But the most important thing is that it literally only does parsing. Kaitai is a poor way to describe a binary API because if you do that, you'll get parsers for free, but you'll have to write all the generating code yourself - at which point, you have to wonder what advantage Kaitai is actually giving you. As I understand it, this isn't some missing feature that's in the works - the Kaitai team do not want to make this a two-way format, that is a complete non-goal.
Which means, as far as I can understand, the main purpose of Kaitai is to parse binary file formats like .PNG or .PDF files without the need for a special parser. It's basically a binary PEG (but, as mentioned before, in YAML).
Yeah, I've used Kaitai to parse binary game files. But ended up dropping it when I wanted to round trip back into binary. Might as well have the decode live next to the encode stuff in the same file at that point.
The nice thing about Kaitai is that it also comes with visualizers. Though the online IDE chokes on repeating frames in large files, the Ruby library can handle it, and it's decent for figuring out what's going wrong.
Finally, I wish Kaitai offered a better dev experience. Its errors are surprisingly barren for a tool that has one job.
I was sort of doing language to do similar tasks as kaitai, before I knew kaitai was a thing, once I found out about kaitai I sort of lost interest.
https://cloudef.pw/fspec-guide.html
There's the small stuff: YAML is convenient as a universal language, but it means that declarations are very verbose - you can't use any sort of syntax sugar, you're having l basically writing the underlying AST that a more convenient language would parse to. It's also still YAML, with all the problems that come from that.
I also can't make head nor tail of the IDE. The big selling point is that it can parse test data you provide automatically as you build your Kaitai structure, but you can't edit the test data at all, and last I checked it didn't provide any sort of completion or hinting as you write your parser. So I might as well edit the structure in my editor of choice and occasionally copy it into the IDE if there's something I need to check, except then I also need to generate an interesting binary test case file and upload it, because, like I said, I can't edit those test cases in the IDE.
But the most important thing is that it literally only does parsing. Kaitai is a poor way to describe a binary API because if you do that, you'll get parsers for free, but you'll have to write all the generating code yourself - at which point, you have to wonder what advantage Kaitai is actually giving you. As I understand it, this isn't some missing feature that's in the works - the Kaitai team do not want to make this a two-way format, that is a complete non-goal.
Which means, as far as I can understand, the main purpose of Kaitai is to parse binary file formats like .PNG or .PDF files without the need for a special parser. It's basically a binary PEG (but, as mentioned before, in YAML).