> This document describes which programming languages the Fuchsia project uses and supports for production software on the target device, both within the Fuchsia Platform Source Tree and for end-developers building for Fuchsia outside the Fuchsia Source Platform Tree. The policy does not apply to (a) developer tooling, either on target or host devices, or (b) software on the target device that is not executed in normal, end-user operation of the device.

As far as I can tell, this is supposed to be “the” languages that can execute on a Fuschia-powered device.

Support means all APIs have first class support by Google, just like how Kotlin has first class support on Android.

They have no means to enforce that. They're talking about what they provide support for, not what is possible.

If you control the App Store, you can enforce a policy like this. And, the whole security model of Fuschia seems great for enforcing something like this: use object capabilities to grant access to everything and don’t provide a stable API for getting those capabilities in unsupported languages.

Unless you have the developers submit source code, it's not really possible to determine what language the source code was written in (if the developer doesn't want you to). For example, if there is a C API, I could write my code in Rust and with only a little effort, have it compile to something which could also have been compiled from something written in C. Even for languages with a more substantial runtime, you could "transpile".

The thing is, you don’t need to make it impossible, just difficult and officially say that it’s “unsupported” to make it a non-starter.

That’s sadly exactly what this means, for now at least: https://fuchsia.dev/fuchsia-src/concepts/api/council

“Supported”, however, is a different word than “allowed”.