Also some feedback on our GSe50s16 opening discussion about the difference between Programers and Engineers; Alex joins us with some of his thoughts.
This episode we started talking about the differences between Engineer, Programer, Developer.
Alex and others had feedback on that discussion.
This is the motivation for explaining what Flatbuffers are and why they are amazingly cool. So this will be a series of articles that rely as much as possible on data, and little as possible on feelings. You know, practical science shit.
Lets build Netflix! All of the code I’ll be building here are found in my flatbuffers-benchmarks repo. I have only included a small portion of the code found in my aforementioned repo for readability sake. For more examples of schema’s and usage check out the test directory of Google FlatBuffers.
Protocol Buffers is indeed relatively similar to FlatBuffers, with the primary difference being that FlatBuffers does not need a parsing/ unpacking step to a secondary representation before you can access data, often coupled with per-object memory allocation. The code is an order of magnitude bigger, too. Protocol Buffers has neither optional text import/export nor schema language features like unions.