[Phlogistique]

It's relevant:

* For projects where one of the main purposes is for the author of the project to learn said language

* For projects which expose an API in their implementation language. In the case of an implementation of a programming language, they might offer embeddability in the host language, or a foreign function interface with the host language.

[moring]

Why do we consider it normal that APIs are exposed for the implementation language of a project (library, interpreter, application, whatever) but usually not other languages?

Is there any evidence that the "user" of an API is likely to prefer the same language that was used for the original thing?

(BTW this does not seem to be the case for networked APIs such as REST services).

[mumblemumble]

The only really stable, standardized, well-supported ABI out there is the C ABI. Communicating across it is a chore. On the side of the language publishing the API, you need to write a C-friendly façade that translates everything your language has that C doesn't into a much more Spartan semantic space. You'll be losing or having to re-implement pretty much everything you like about that language: any sort of dynamic dispatch, memory management semantics, exceptions, etc. And then, on the client language side, you probably want to write another façade in order to, to the extent that it's feasible, restore all those sorts of niceties.

Direct FFIs are possible, but generally don't happen except in exceptional cases because of the cost involved in writing a new FFI (and accompanying set of gotchas) for every possible language whose packages you might want to consume. The best and worst thing about the C ABI is that it's pretty much the least common denominator.

Even in platforms like Java and .NET that theoretically smooth over these problems, we find that it never works out that well in practice. Scala and F# users end up having to write compatibility layers in order to preset Java and C# friendly APIs, and they end up writing their own versions of just about every possible library in order to have packages that don't feel awkward to use in their language of choice. The only real exception I know of to that pattern on the JVM or the CLR is between C# and Visual Basic, and that is only because Microsoft was very careful to ensure that the two languages' semantics were similar enough to virtually guarantee no cross-language friction.

[pjmlp]

COM/UWP are doing just fine on Windows world.

[mumblemumble]

UWP in particular is very nice. But I would argue that, for most of us, the "W" stands for "not well-supported."

[richardwhiuk]

Thunking across FFI often takes a lot of work to make it ergonomic.

[Jumziey]

I agree, "machine learning framework written in <lang>" is relevant, not sure i agree about an interpreter though :p