Google’s in-development operating system, named ‘Fuchsia,’ first appeared over a year ago. It’s quite different from Android and Chrome OS, as it runs on top of the real-time ‘Magenta’ kernel instead of Linux. According to recent code commits, Google is working on Fuchsia OS support for the Swift programming language.
There’s a tiny error in this summary form AndroidPolice – Fuchsia’s kernel has been renamed to Zircon.
All this has been playing out late last week and over the weekend – Google is now working on Swift, and some took this to mean Google forked Apple’s programming language, while in reality, it just created a staging ground for Google to work on Swift, pushing changes upstream to the official Swift project when necessary – as confirmed by Chris Lattner, creator of Swift, who used to work at Apple, but now works at Google.
Zac Bowling, a Google engineer working on Fuchsia, then highlighted a pull request that Google pushed to the main Swift repository: Swift support for Fuchsia. He also mentioned a few upcoming pull requests:
FYI, in the pipeline after this we will have some PRs related to:
- adding ARM64 support for the Fuchsia SDK
- fixing cross-compiling issues for targeting BSD, Linux and Fuchsia targets from a Darwin toolchain
- adding support for using lld for linking specific SDK stdlibs (part of getting a Darwin toolchain capable of cross compiling to other targets)
- supporting unit tests on Fuchsia
Regarding Fuchsia’s purpose, this is yet another little puff of smoke. Sadly, we still haven’t found the fire.
Google appear to have hired a another developer relations kind of guy for the platform – this one away from MS.
https://medium.com/@timsneath/new-beginnings-google-bf849766a497
To be honest I think it’s quite clear what the strategy is – build a great cross platform developer experience for mobile native apps – android, IOS, fuchsia.
Support polyglot programming via a language neutral idl and message passing.
Thus making the transition from android to fushsia as good experience, and as risk free, as possible for developers.
Doesn’t matter how technically good fushsia turns out to be – it needs developer support to succeed.
If you want to take a leap forward in platform you have to break some existing stuff and get the developers to want to jump with you. The largest single hurdle for developers is learning a new language – a polyglot approach here is a big win.
It’s a twin track strategy – continue to evolve Android, and at the same time try and built something that tries to be the next big leap, unencumbered by the past.
It’s clearly not specifically for Google Home or Chromecast – the focus is developers, developers, developers – that has to be a mass market phone/tablet.
Yeah, I kinda wonder if there really is a single Google mind on what to do with Fushsia vs Android. It might just be a research OS, that never gets used in whole. With parts being stripped out for Android and/or ChromeOS. Kind a like how Plan 9 was never commercially advertised, but lots of it was incorporated in Linux and other OS.
I’d agree there isn’t likely to be a single view within a company like Google – there will be people cheer leading the web everywhere, or evolved Android, or this that and the other.
Google has the resources to have bets on multiple horses.
For this bet – all you can say is it looks better resourced that a typical 20% pet project – both in terms of talent and in terms of numbers.
As you say – parts could be successful in their own right – or reused – to some extent the Dart stuff is a pivot from previous adventures.
The developer platform is cross-plaform so if they never ship the OS, it still could succeed as a way of writing android and IOS apps. Similarly kernel research may be folded back into other products.
But if you were to design shipping a new mobile platform
you need to have a plan to cross the app desert that Windows phone died on.
Two approaches:
– emulation – problem here is running say Android apps on a new OS typically doesn’t give a good user experience and you get stuck in this valley – where it’s good enough for developers to not want to bother porting until the OS really takes off, but the OS doesn’t take off because emulated apps makes the experience a bit $#!+.
— have a kick ass developer tool everyone is already using to develop cross-platform Android/IOS apps, that magically natively supports the new platform when it ships.
You could try the web route for the latter option – though people have tried and it’s perhaps not kick ass enough – performance and platform integration just not there.
The flutter team appear to be trying option two with ‘compile to native’ option – it’s not technically easy – but if they can pull it off it just may work.
Hm, though it’s kinda interesting that Java/Dalvik seems to be taking a 2nd stage compared to, now, Swift …to perhaps get rid of “dependancy” on Oracle in the hoped-for future?
Dalvik (JIT) has been ditched in favour of ART (AOT+JIT) since Android 5. I doubt Oracle is a factor here – Java is open-source now; I would rather bet on technical reasons – Java relies on a garbage collector which is a poor choice for a mobile device: tracing GC needs a lot of RAM to work properly and eats CPU cycles (energy) while doing its bookkeeping.
Windows Phone also makes use of managed languages and low end devices always outperformed Android devices on the same price range.
Designers of Lisp Machines would be wet if they could have had access to the supercomputers on our pockets.
It is only a matter of quality of implementation, and as any Android developer will tell you, given the quality of Android releases, Google apparently doesn’t have their PhDs able to do inverted tree whiteboard exercises on Android team.
Also from CS literature and papers point of view, ARC is a GC algorithm.
Java was open source also when Oracle took Google to court over it…
It seems that developers target iOS first and Android later. Perhaps they want developers to use only one codebase to target both.
Perhaps. Though there’s more to such ~compatibility than the language… Now, if Google would adapt GNUStep for mobile (like Sony supposedly almost did several years ago), this would raise some eyebrows… Though the question here is, does Google even want their OS to be a technical clone of that of Apple.
Edited 2017-11-23 07:53 UTC
Could this not be a CHrome OS replacement, especially given the COS machine popularity with some developers, despite the hassle in setting it up accordingly?
The reason is that the Linux kernel + Android’s Java implementation suck completely.
Google wants to replace them with something manageable.
Edited 2017-11-22 16:39 UTC