3 ms·

Reasons not to use protocol buffers (in C++ at least): 1) Doesn't support Visual Studio 2013. 2) Doesn't support Mac OS X Mavericks. 3) No "nice" s

Reasons not to use protocol buffers (in C++ at least): 1) Doesn't support Visual Studio 2013. 2) Doesn't support Mac OS X Mavericks. 3) No "nice" support C++11 (i.e. move constructors) (These can be at least partly solved by running off svn head, but that doesn't seem like a good idea for a product one wants to be stable) With JSON I can be sure there will be many libraries which will work on whatever system I use.

nly 12y ago
All 3 of your points are the fault of Protobufs being an almost stagnant project. Nothing significant has changed for a number of years. You only have to look at the public repo commit log to see Protobufs may as well be a release tarball only distribution[0], with already infrequent releases[1]. [0] https://code.google.com/p/protobuf/source/list https://code.google.com/p/protobuf/source/list [1] https://code.google.com/p/protobuf/downloads/list https://code.google.com/p/protobuf/downloads/list
- kentonv 12y ago
  The management chain for Protobufs goes up through the internal infrastructure org. Sadly, they never really seemed to understand the importance of the open source release. Even though Chrome, Android, and other open source Google products rely on it, those orgs generally don't work with internal infrastructure very much, so they naturally seem distant and unimportant. Meanwhile, there are two branches of Protocol Buffers: internal and external. They contain mostly the same code, and there are scripts that automatically merge changes back and forth, but those scripts do require some amount of human supervision. And since the internal users are a lot more demanding than the external ones, most development occurs internally. This is a pretty crappy way to run an ostensibly open source project, and that's my fault. I probably should have put in the effort to better unify the two branches so that changes could be integrated automatically. It would have been a pretty significant amount of work, though, and I was mostly a one-man team (with a few "20% time" helpers), and most of my time was spent trying to figure out how to convert millions of lines of existing internal application code over from proto1 to proto2 (where proto1 is the original version of protobufs which has never been released publicly). What I did do was make sure to run the fiddly release process on a semi-regular basis, so that the open source release did not fall behind. Luckily the core code was pretty stable, so it wasn't necessary to do releases all that often. But pushing releases was something I pretty much had to do on my own initiative; management never cared. So when I eventually moved off protobufs, the replacement team (which management didn't even realize was needed until about six months later) naturally deprioritized open source releases. They've done a couple over the years, but as you've noted, it's rare. On the "bright" side, judging from the way things were going when I left the company in early 2013, it's unlikely that there has been any significant change in the internal code from which you'd benefit, so maybe it doesn't really matter.
  - nly 12y ago
    Wow, thanks for the insight in to behind the curtain :}
TillE 12y ago
> Doesn't support Visual Studio 2013 That's a really tiny issue which just requires including another header. https://code.google.com/p/protobuf/issues/detail?id=531 https://code.google.com/p/protobuf/issues/detail?id=531
- CJefferson 12y ago
  This still means you can't just use the standard package, and also shows how it took 4 months to fix it, and then after another 8 months there still hasn't been another release.

nly 12y ago

All 3 of your points are the fault of Protobufs being an almost stagnant project. Nothing significant has changed for a number of years. You only have to look at the public repo commit log to see Protobufs may as well be a release tarball only distribution[0], with already infrequent releases[1]. [0] https://code.google.com/p/protobuf/source/list https://code.google.com/p/protobuf/source/list [1] https://code.google.com/p/protobuf/downloads/list https://code.google.com/p/protobuf/downloads/list

kentonv 12y ago
The management chain for Protobufs goes up through the internal infrastructure org. Sadly, they never really seemed to understand the importance of the open source release. Even though Chrome, Android, and other open source Google products rely on it, those orgs generally don't work with internal infrastructure very much, so they naturally seem distant and unimportant. Meanwhile, there are two branches of Protocol Buffers: internal and external. They contain mostly the same code, and there are scripts that automatically merge changes back and forth, but those scripts do require some amount of human supervision. And since the internal users are a lot more demanding than the external ones, most development occurs internally. This is a pretty crappy way to run an ostensibly open source project, and that's my fault. I probably should have put in the effort to better unify the two branches so that changes could be integrated automatically. It would have been a pretty significant amount of work, though, and I was mostly a one-man team (with a few "20% time" helpers), and most of my time was spent trying to figure out how to convert millions of lines of existing internal application code over from proto1 to proto2 (where proto1 is the original version of protobufs which has never been released publicly). What I did do was make sure to run the fiddly release process on a semi-regular basis, so that the open source release did not fall behind. Luckily the core code was pretty stable, so it wasn't necessary to do releases all that often. But pushing releases was something I pretty much had to do on my own initiative; management never cared. So when I eventually moved off protobufs, the replacement team (which management didn't even realize was needed until about six months later) naturally deprioritized open source releases. They've done a couple over the years, but as you've noted, it's rare. On the "bright" side, judging from the way things were going when I left the company in early 2013, it's unlikely that there has been any significant change in the internal code from which you'd benefit, so maybe it doesn't really matter.
- nly 12y ago
  Wow, thanks for the insight in to behind the curtain :}

TillE 12y ago

> Doesn't support Visual Studio 2013 That's a really tiny issue which just requires including another header. https://code.google.com/p/protobuf/issues/detail?id=531 https://code.google.com/p/protobuf/issues/detail?id=531

CJefferson 12y ago
This still means you can't just use the standard package, and also shows how it took 4 months to fix it, and then after another 8 months there still hasn't been another release.