My windows machine can run make and gcc natively. You don't need to be unix to run those platforms. I haven't watched fuchsia closely (last interfaced about 6 years ago, talked to a team member, who said that eventually it would be able to emulate unix enough to build and host a compiler).
I guess I should have put my question in a more useful way: why would I want to use this desktop, given its limitations compared to existing desktops? Is it ever going to be a development system? If not, I can't see how it would grow beyond being a device environment- in which case there probably shouldn't be a terminal anyway. Probably I'm asking for something which is not a goal of fuchsia, but in that case, I really can't get exicted about something that's supposed to replace Android and other OSes.
They don't install the apps for the purpose of seeing advertising, and there's no way to opt out of the ads, so I don't think that is a good assessment.
> In conclusion. Too early, lack of experts, rapid evolution pains. It was stacking risk on top of an already risky project.
Rust was extremely immature and too early to be used in an OS at the time. It just hit 1.0. By then, Fuchsia already wrote its kernel Magenta (now Zircon) in C++.
In short, it did not make sense to write the OS kernel in Rust from both a technical and business standpoint at the time.
Dude it's a kernel. What other alternatives do you suggest? ATS and all sound nice for academic projects but it's an industry project (even if some research purpose is there) they have different tradeoffs.
I'm sure they don't need my recommendation, and the whole thing is moot today if Rust has fixed the issues in the years since.
But to play with counterfactual history: Apparently Go is fairly big there. There was a Usenix paper about a Go kernel a while back, and there's also gVisor. Then there is Ada, and Kotlin native, and various safe dialects of C. MS did one in .NET - there were lots of options.
There are papers with Python kernels. Doesn't mean Python's a good language for writing a kernel. gVisor had to fight Go quite a lot, I think it was a huge mistake for them to choose it.
Ada is the only language you've mentioned that really fits IMO. One of the safe languages like P would be interesting but it's unproven in the space.
As for Ada, it's a sad story, but ultimately the language is unlikely to gain traction after too many early mistakes (particularly around licensing).
So its from quite a prestigious institution, has at least one big authors, and concludes that it works quite well and recommends it over C for new kernels and VMMs.
I also disagree the "no traction" argument about Ada since it's been used in real projects and had a big enough developer community for a long time, and is alive and well. People can surely pick up new programming languages when they join a new project, I know I've done it many times. Tooling licensing should be fine as well since GNAT is available under GPL + Licensing exception, same as Google has been using with GCC since dawn of time, and under the Adacore license which Google probably can afford.
So, I hold that there were many other options vs Rust. Including the others in my original comment that we didn't get to in details. Except Kotlin Native, I made a timeline mistake there, it was too early in 2016.
