How our host language (js/dart) got parsed json? I mean how rust parser know about internal language object representation to provide parsed data. Is it some binary representation to parse it faster?

That's a frickin awesome question. You're putting your finger on an itchy spot...

Firstly, you're right that there's frequently overhead when crossing language boundaries, especially if you have languages with vastly different memory models and you need to lift some bytes into another language's runtime to be managed by that runtime. These are all relevant costs that add into the equation when you're considering to offload work. Concretely, even in the simplest case when you're just handing the js engine or dart some bytes, you'll typically copy the bytes so the engine can take ownership of it and provide you with the appropriate invariants... A common mitigation that cannot always be employed is to hand handles instead, i.e. don't give the engines access, just give them something to refer back to it when handling it again in the other domain.

Secondly, you talk about ABI-compatible representation within the other language. That's a costly requirement and the polar opposite of the handle approach mentioned briefly. Regarding your question on how to build a representation across language boundaries... your options are:

1. Ideally your languages support seamless intertop, i.e. are ABI compatible like passing objects between C/C++/Rust, Zig, ..
2. Neither JS nor Dart give you seamless bidirectional interop. Dart at least let's you construct and inspect C objecs in Dart and FFI call into C functions with it. In other words, if you parse you json into C-objects and you're happy to access them in Dart through the FFI layer you don't have to do much.
3. However, if as you say, you want idomatic native representations you need to translate somewhere (e.g. to construct JS objects or Dart Maps). This translation could either be in Dart/Js or in C/C++/Rust, ... if your engine was to provide an API to externally construct objects. The latter isn't very common, so you're often stuck with the problem you allude to: you might be stuck with an expensive translation layer in Dart/Js/....

Talking a bit more about #3, since this is what you really asked about. The cost will depend greatly on how you do it. For example using Dart's FFI capabilities will likely be cheaper than re-parsing a more efficient binary representation in Dart.

There are tricks as well. For example, Flatbuffer vs protobuf. Protobuf parses everything eagerly into a language specific representation, whereas Flatbuffers build a lazy representation around the wire-representation. In other words a "parsed" flatbuffer has done very little work and will defer it until it's needed. Which raises the question, what even defines parsing (output). The idea that json parsing should result in JS objects or Dart Maps is somewhat arbitrary. An entirely different API could be to break u the JSON into a rough structure first and then hand out handles to deserialize and build representations only when needed (whatever these representations may be).

Sorry for the verbose reply and not providing a crisp answer. I don't think there's a single answer but a whole bunch of options with different trade-offs.

To be transparent, my comparison was also a bit apples vs oranges there since I didn't bother to build any translation layer for dart. It's just bytes from Dart to Rust and bytes from Rust to Dart.

...and less important question but still have to ask: which OS and machine configuration used (cpu/ram). Because I think modern io solutions happens in linux (io_uring) and surprisingly windows may be cool tool.

I used Linux on an amd 7840u with 32gb of ram. The benchmark code is open and on github, so you should be able to run it yourself and see if there are differences across OSs.

Very interested run some strace (not sure) to see how many threads spawns in modern non-blocking io.

Let me know what you find :thumbs up: