We use FlatBuffers (the parent project) in our code @ FS... that means it has to work in C++, Rust, Java, and TypeScript. It's mostly the schema processing that requires a C++ compiler to make it work.

It's a pretty stellar cross-platform serialization toolkit and the zero-copy support for reading is no joke.

We've been using it across multiple languages too as the data serialization format between server and (web) client. It's fantastic.

FlexBuffers currently is implemented in C++, Java, Rust, Dart, Swift, (and JS under review).

You forgot Python and C# :). Plus a Unity3D specific version, which is battle tested in a game with more than half a million downloads ;).

We use Flexbuffer to serialize aribitary Objective-C objects through reflection (rather than NSCoding). It is faster and stable for us in a few years actually (we implemented that in early 2019).

The codegen for flatbuffers is fairly extensive, but C++ is still the blessed language for gRPC, however [0].

[0] https://google.github.io/flatbuffers/flatbuffers_grpc_guide_...

gRPC FlatBuffers is supported in quite a few languages besides C++, Java, Go, Python, Swift, off the top of my head..

FlatBuffers libraries are implemented in a big list of languages, as you can see on the website. FlexBuffers is not implemented in all the same languages yet, at least in the official Google repo. Otherwise, it is very relevant in any language--it's a binary serialization format.

If you need a language support for FlexBuffers please create an issue on GitHub repo. I ported it already to Swift, C#, Dart, Python, JS (is in review). If I am familiar with the language you need, it will take me just a couple of days to port it.

It is basically a code template generator. It is written in C++ but it can generate code for other languages.

It is one of the best serialisation methods currently available.

AFAIK some languages can use C++ fairly easily, including D and Rust

These languages can use C fairly easily. To use C++, you must wrap the C++ interface in `extern "C"` interfaces. It's very hard to use the full spectrum of C++ features.

Consider that you're writing a custom struct/data type called MyStruct in your language. Now, can you use std::vector<MyStruct>? This requires your other language to read the entire vector header and instantiate a new type based on both your definition of your custom type and the vector template. The vector instantiation will ask questions like whether or not your type is copy constructible and move constructible, and if so, use these implementations. Designing this into your other language requires a lot of compromises.

And that's just templates. ADL poses an even bigger difficulty. Again when you write your custom type in your language and define a swap function for it, will C++ standard algorithms that need swapping find your implementation via ADL? Recall that swapping is invoked via having `using std::swap;` and then invoking the bare function `swap` which triggers ADL. Again, designing this into your other language requires a lot of compromises.

The only language that I know of that comes close to having full interoperability with C++ is Objective-C, and it does so by creating a new Frankenstein language called Objective-C++. It has two different kinds of classes, two different exception mechanisms, etc.

Wrong, D has support for C++ FFI.

https://dlang.org/spec/cpp_interface.html

It supports neither templates nor ADL, the two of my examples.

In fact the doc says,

> Being 100% compatible with C++ means more or less adding a fully functional C++ compiler front end to D. Anecdotal evidence suggests that writing such is a minimum of a 10 man-year project, essentially making a D compiler with such capability unimplementable.

It then goes on to describe the pragmatic approach that doesn't allow full compatibility:

> D takes a pragmatic approach that assumes a couple modest accommodations can solve a significant chunk of the problem:

> matching C++ name mangling conventions

> matching C++ function calling conventions

> matching C++ virtual function table layout for single inheritance

Can you see how limited this subset of interoperable API is?

> matching C++ name mangling conventions

> matching C++ function calling conventions

> matching C++ virtual function table layout for single inheritance

Basically COM? Which is not surprising as it was designed as an OO native FFI.

And UWP improves on it, giving more C++ features across the ABI, basically what .NET v1.0 should have been all along.

I didn't state it supports 100% compatibility, and it is still better than being stuck with an OS ABI from the 70s, that is only meaningful when the underlying OS is written in C anyway.