I once had a C# server with a TypeScript frontend (this was for work, so I didn't choose the tech stack). We had one part of the code which had a lot of calculations. We wrote the code in a C# library, then used Roslyn to analyse the C# code and generate TypeScript code that matched it identically. This way the client could visualise the results on the client with zero latency, no server roundtrip, but ultimately the server would be in charge of the final calculations. It was a great solution, I would do it again.

We could have potentially used Fusion for this had it existed, but I don't know if we would. We didn't have to support 12 different languages, only 2.

I think the target application is writing the same algorithm in multiple places with a guarantee that the logic will be based on a single source of truth. Not unlike Protocol Buffers work to standardize data layout across platforms.

It still feels overcomplicated compared to the standard solution of writing a library in a compiled language you like, exposing a C ABI compatible interface, and hooking it up to any language that can work with that (i.e. any language).

In theory having it in the same language could provide performance benefits, vs reaching out to a C library and dealing with C interop fun. Any language that is JIT'd would have native bytecode to optimise instead of a black box.

ORMs and variations like Protobuf or things that have to be cross-plateform in the wide sense. The perspective that the same source will behave the same in various environments, and "velocity" trumps performance considerations. If you want to work on things where performance matters, consider embedded/firmware programming ;-)