I think I didn't explain myself well.

As long as a language has bytes and arrays, you can implement anything on top of them, like unsigned integers, 8-bit strings, UTF-8 strings, UCS-2, whatever you want. Sure it won't be native types, so it will probably be slower and could have an awkward memory layout, but it's possible

Granted, if a language is so gimped that it doesn't even have integers (as you mentioned JavaScript), then that language will not be able to fully support it indeed.

Unfortunately that doesn't solve the problem -- it only pushes it around

I recommend writing a protobuf generator for your favorite language. The less it looks like C++, the more hard decisions you'll have to make

If you try your approach, you'll feel the "tax" when interacting with idiomatic code, and then likely make the opposite decision

---

Re: "so gimped" --> this tends to be what protobuf API design discussion are like. Users of certain languages can't imagine the viewpoints of users of other languages

e.g. is unsigned vs. signed the way the world is? Or an implementation detail.

And it's a problem to be MORE expressive than C/C++ -- i.e. from idiomatic Python code, the protobuf data model also causes a problem

Even within C/C++, there is more than one dialect -- C++ 03 versus C++ 11 with smart pointers (and probably more in the future). These styles correspond to the protobuf v1 and protobuf v2 APIs

(I used both protobuf v1 and protobuf v2 for many years, and did a design review for the protobuf v3 Python API)

In other words, protobufs aren't magic; they're another form of parsing, combined with code generation, which solve some technical problems, and not others. They also don't resolve arguments about parsing and serialization!