I worked on a project integrating capnproto under the directive we wanted something highly performant. I was then told to scrap it for protobuf because the wider company had better knowledge in that area and it was used elsewhere. I was just contracting by giving a helping hand so I wasn't fully aware of this. But in doing all of this, I had the chance to benchmark both capnproto and protobuf, and I had gotten slightly better performance results from PB. This was all in C++.
Looks like this has been around for over a decade now. I'm surprised I haven't heard of it until now.
If, as advertised, it's significantly better than protobufs, why hasn't it gathered more steam/adoption? If presented correctly it sounds like a great alternative/replacement to things like JSON, proto, SBE messages, ... Especially in the realm of backwards/forwards compatibility.
Has anyone tried this out and ended up switching BACK to a more widely used alternative? If so, why?
I'm just speculating (please chime in if you know more!).
Afaiu protocol buffers are very popular for over the wire communication and in that use case cap'n proto does not win you much @ performance (?).
And if you don't go over the wire the performance difference might not matter for many use cases (e.g there is plenty of json sent around as well) and when it does matter: cap'n proto or something custom w/ desired performance characteristics other than protocol buffers is chosen but here cap'n proto covers a slim middleground (?).
+ usual adoption dynamics: protocol buffers have more mindshare and if another solution is not clearly way better for the use case: switching/trialing is not happening as much. (?)
I worked on a project integrating capnproto under the directive we wanted something highly performant. I was then told to scrap it for protobuf because the wider company had better knowledge in that area and it was used elsewhere. I was just contracting by giving a helping hand so I wasn't fully aware of this. But in doing all of this, I had the chance to benchmark both capnproto and protobuf, and I had gotten slightly better performance results from PB. This was all in C++.
Looks like this has been around for over a decade now. I'm surprised I haven't heard of it until now.
If, as advertised, it's significantly better than protobufs, why hasn't it gathered more steam/adoption? If presented correctly it sounds like a great alternative/replacement to things like JSON, proto, SBE messages, ... Especially in the realm of backwards/forwards compatibility.
Has anyone tried this out and ended up switching BACK to a more widely used alternative? If so, why?
I'm just speculating (please chime in if you know more!).
Afaiu protocol buffers are very popular for over the wire communication and in that use case cap'n proto does not win you much @ performance (?).
And if you don't go over the wire the performance difference might not matter for many use cases (e.g there is plenty of json sent around as well) and when it does matter: cap'n proto or something custom w/ desired performance characteristics other than protocol buffers is chosen but here cap'n proto covers a slim middleground (?).
+ usual adoption dynamics: protocol buffers have more mindshare and if another solution is not clearly way better for the use case: switching/trialing is not happening as much. (?)
Also note cap'n web, which is half a year old more web friendly version, https://news.ycombinator.com/item?id=45332883 https://blog.cloudflare.com/capnweb-javascript-rpc-library/