Huh. tree-sitter seems neat, but I don’t really get why the author thinks processing the descriptor set is so hard. Seems equally difficult to learn a bunch of new abstractions in the form of tree-sitter vs just learning protobuf’s own ones.

Also, if you’re parsing .proto files directly, you have to deal with a bunch of annoying issues like include paths, how you package sets of them to move around, etc. descriptor sets seem like a better solution to me.

OTOH, if you can get treesitter to work, all the best editors will gain Protobuf support.

No, they’re not inventing the tree-sitter grammar for protobuf here, they’re using the existing grammar provided by someone else. So it’s not like there’s additional reusable work being done here.

Came to the comments to say this. FileDescriptors have been so simple to work with that I am so surprised the author is touting TS for this use case.

The other nice thing about all the descriptors is their schemas are protobufs, so language agnostic and easily serialized/deserialized.

Worth noting that this is in the 'lxc' execution driver, which is no longer the default. The 'native' driver here is now the default: https://github.com/docker/docker/tree/master/daemon/execdriv...

Minor point, but New Relic has had built-in support for collecting response time distributions for over a year. Please don't lie about this.

https://docs.newrelic.com/docs/apm/applications-menu/feature...

I got confused for a second and thought I was still reading 'The Circle' while reading this page.