This isn't saying that you are not allowed to use some other language, just that you might be on your own wrt an SDK etc.

FTA: "Supported for end-developers means that the Fuchsia SDK contains tools and libraries that help people use the language to develop software for Fuchsia, including a language-specific backend (and supporting libraries) for FIDL. Support also implies some level of documentation, including tutorials and examples, as well as investment from developer relations."

So when you read something like:

> Go is not approved, with the following exceptions:

>>>> netstack. Migrating netstack to another language would require a significant investment. In the fullness of time, we should migrate netstack to an approved language.

> All other uses of Go in Fuchsia for production software on the target device must be migrated to an approved language.

Does that not imply that okay sure use whatever language you want, but production software (that exists in repositories?) must adhere to approved languages?

I could be misreading

> Does that not imply that okay sure use whatever language you want, but production software (that exists in repositories?) must adhere to approved languages?

> I could be misreading

To me, that reads: platform devs, i.e. people developing Fuchsia itself, must adhere to the approved language list. Which is not uncommon in projects of all sizes from small to large.

I think the wording is a bit weird because Google is expecting 3rd party device manufacturers to make modifications to the OS and expects them to adhere to the approved language list as well.

I don’t read it as requiring production software for end-user applications requiring specific languages. I think I’m correct in assuming that the OS level calls, bindings, and built ins will only be provided with approved and supported APIs for the approved languages. I also think that’s what the GP comment was saying. I think the result will be language specific shim layers that are required by language/implementation maintainers. But I’m just making a guess.

Edit: had I read the quote from a comment not far below before posting, I would not have made these assumptions. That quote does sound like applications will be language restricted.

> Does that not imply that okay sure use whatever language you want, but production software (that exists in repositories?) must adhere to approved languages?

> I could be misreading

That’s for “production software” (as opposed to tooling I’d guess) in / of Fuschia itself. They’re saying that aside from netstack & stuff that only runs on the dev machines everything that’s in Go in the Fuschia repository must be migrated ASAP to an approved langage.

For end-developers it’s the same status as eg Rust: you’ll be on your own with no support from the fuschia project.

This document is about the use of languages within the project itself.

Fuchsia, as a fundamental principle, supports "bring your own runtime" -- if you are a PIE ELF executable and can dynamically link against libzircon.so (the syscall ABI) and speak the platform's RPC protocols, you are a Fuchsia app.

The Fuchsia IDL compiler is designed to support third party backends for other languages beyond the core platform languages.

I've moved on to other things, but I'd be very surprised to learn this had changed.

> This document is about the use of languages within the project itself.

Only in part; they also specifically mention whether or not they will support use of each language by end-developers. (As you say, end-developers can use whatever they want, as long as their language has a C-ABI FFI, but that's not the same as being "supported".)

Isn't this just a list of languages allowed to use when writing Fuchsia? I don't see how they would ban users from writing their apps in say Go or Clojure.

> 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”.

They support C, so anything with a FFI to C can be used, just Google will not give people tooling for it or support it.