4 ms·

All of them. Linux has one: C. For clarity, this is talking mostly about what languages they will use when writing the OS itself (that’s what “approved” means

by Gaelan 7y ago

All of them. Linux has one: C. For clarity, this is talking mostly about what languages they will use when writing the OS itself (that’s what “approved” means in the article). They do also touch on what languages are supported (I.e. they’re building the infrastructure to allow it to happen) in userspace, but they’re not saying you can’t run other code on the OS.

swiley 7y ago
A lot of Linux OSes define protocols and interfaces with matching implementations. The kernel has syscalls, the GUI has a socket protocol etc. Sure the individual components pick a language but there's no singular language applications are "supported" for (except libraries like GTK which you don't really need), that's how we get nice things like TCL/TK and guile.
- anthk 7y ago
  In Unix, C is THE API.
throwaway17_17 7y ago
I don’t know that your take away is correct, I was under the same assumption the these specific languages were for OS code, but from the article: “ 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.” This seems to say that software executed by end-users is only going to be ‘supported’. As was stated earlier in a comment, there is a difference between ‘allowed’ and ‘supported’, but I don’t understand why they are taking such a general hard line about the support of it is just kernel specific. I’m still going to maintain the assumption that the OS is only going to be natively usable in the approved languages and that all others will require individually maintained shim layers.
- swetland 7y ago
  You're incorrect. This document is describing languages used to develop the platform itself (and a bit about priority of external support for languages). The Fuchsia platform was designed to be language agnostic, bring-your-own-runtime. at least as of when I last worked on it, but it has been a core principle from day one that I would be shocked to see abandoned.
- masklinn 7y ago
  > This seems to say that software executed by end-users is only going to be ‘supported’. As was stated earlier in a comment, there is a difference between ‘allowed’ and ‘supported’, but I don’t understand why they are taking such a general hard line about the support of it is just kernel specific. Support for end-developers means provision for built-in API and affordances. They won’t stop you from using something else for your Fuschia applications but you should not expect much if any help in getting it working or whatnot.

by Gaelan 7y ago

swiley 7y ago

A lot of Linux OSes define protocols and interfaces with matching implementations. The kernel has syscalls, the GUI has a socket protocol etc. Sure the individual components pick a language but there's no singular language applications are "supported" for (except libraries like GTK which you don't really need), that's how we get nice things like TCL/TK and guile.

anthk 7y ago
In Unix, C is THE API.

throwaway17_17 7y ago

I don’t know that your take away is correct, I was under the same assumption the these specific languages were for OS code, but from the article: “ 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.” This seems to say that software executed by end-users is only going to be ‘supported’. As was stated earlier in a comment, there is a difference between ‘allowed’ and ‘supported’, but I don’t understand why they are taking such a general hard line about the support of it is just kernel specific. I’m still going to maintain the assumption that the OS is only going to be natively usable in the approved languages and that all others will require individually maintained shim layers.

swetland 7y ago
You're incorrect. This document is describing languages used to develop the platform itself (and a bit about priority of external support for languages). The Fuchsia platform was designed to be language agnostic, bring-your-own-runtime. at least as of when I last worked on it, but it has been a core principle from day one that I would be shocked to see abandoned.
masklinn 7y ago
> This seems to say that software executed by end-users is only going to be ‘supported’. As was stated earlier in a comment, there is a difference between ‘allowed’ and ‘supported’, but I don’t understand why they are taking such a general hard line about the support of it is just kernel specific. Support for end-developers means provision for built-in API and affordances. They won’t stop you from using something else for your Fuschia applications but you should not expect much if any help in getting it working or whatnot.