This is a good point, and something I considered. There are a few reasons I decided against using the .proto format:
* In .proto format, it's generally assumed that _removing_ a field, or having a gap in field numbers, is OK. In Cap'n Proto, it's not OK, because offsets of subsequent fields are affected.
* The language frankly has a lot of little ugly quirks that I wanted to get away from.
* I want control over my format so that I can add features that protobufs may not be interested in, like the ability to define constants.
* After proto2 I'm kind of tired of working around legacy. :)
* I'm not working for Google anymore, so I don't have any particular reason to cater to what would make the most sense for Google. Why not use Thrift or POJOs or anything else as the base language? :)
I think most of the benefits you describe could be achieved by writing a .proto<->.capnp translator, which should not be very hard given that, as you say, the languages are pretty much isomorphic.
* In .proto format, it's generally assumed that _removing_ a field, or having a gap in field numbers, is OK. In Cap'n Proto, it's not OK, because offsets of subsequent fields are affected.
* The language frankly has a lot of little ugly quirks that I wanted to get away from.
* I want control over my format so that I can add features that protobufs may not be interested in, like the ability to define constants.
* After proto2 I'm kind of tired of working around legacy. :)
* I'm not working for Google anymore, so I don't have any particular reason to cater to what would make the most sense for Google. Why not use Thrift or POJOs or anything else as the base language? :)
I think most of the benefits you describe could be achieved by writing a .proto<->.capnp translator, which should not be very hard given that, as you say, the languages are pretty much isomorphic.