To be fair, MATLAB only added support for reading/writing JSON this very year. And they represent JSON objects as structs, which don't support all key names, and they have a very "idiomatic" idea of which JSON arrays are decoded as matrices or cells, and how nested arrays sometimes result in nested arrays, and sometimes result in multi-dimensional arrays. And there's an uneasy relationship between the empty array and Null. It is kind of a mess, really.

Also to be fair, although I can see some uses for supporting JSON in MATLAB, it makes a lot more sense if you're using an array language to use an array-oriented format such as HDF5, which has been supported in all the major numerical platforms for quite a while.

> It is kind of a mess, really.

Honestly, that statement applies to pretty much any part of MATLAB unless the behaviour is nailed down by existing mathematical or engineering specifications - and I'm talking as someone that likes MATLAB overall. Mathworks tries a bit to polish and paint it as a coherent whole, but it's patchwork of things built upon and stuck to the sides of the existing structure, optimizing towards a particular kind of "pragmatism" than towards any kind of elegance.

I remember my colleague working with JSON in MATLAB via some thirdparty library about 2 or 3 years ago. It was regex-based, it was slow as hell but at least it was available.

Fun fact, I wrote my own JSON reader/writer in pure MATLAB, and it is also regex-based, and in many cases, it is faster than MATLAB's own, Mex-based JSON reader/writer: https://github.com/bastibe/transplant

There are few things as slow as non-vectorized MATLAB code. MATLAB's regex engine is pretty decent, actually, and supports quite a few fancy tricks. For example, I use the regex engine to find the start/end of all numbers and strings ahead of time, and for replacing escape sequences (even unicode escapes!) with their literal characters. The former is particularly important because otherwise, you'd have to manually iterate over characters until you find the end of strings or numbers, which is unacceptably slow in MATLAB.

CBOR or MsgPack are binary JSON-like encodings.

ProtoBuf depend on the schema definitions and encoder/decoder generation. Without the schema, you cannot read the format (theoretically), if you want your data to be read easily, JSON or CBOR or MsgPack are your best options.

I've been using cbor with python and it's been just fantastic. In particular it: Can send a "None"; Can tell the difference between bytes and unicode; and is real fast.

Encoding/decoding of protobufs can be done dynamically if you know the schema.

knowing the schema also means knowing the right revision of the schema. If you store messages for a while, this already can be a problem.

schemaless is never really schemaless: the code that accesses your data is implicitly assigning it a schema, so you'll have the same problem. FWIW, protobuf schemas are designed to be friendly for back and forward compatibility; unknown fields can be ignored and "required fields are generally considered harmful", interesting read: https://github.com/google/protobuf/issues/2497

> there's little reason to use XML except for legacy or markup purposes.

There's also the ability to easily and explicitly encode data that doesn't fit to JSON's limited types. A non-exhaustive example includes: sets, hash tables that don't use string keys, tuples, imaginary numbers, fractional numbers, and precision decimal numbers.

There's also the fact that XML explicitly supports streaming interpolation of documents, something which can speed up interactivity quite dramatically.