Linked by Thom Holwerda on Mon 20th Nov 2017 21:56 UTC
Google

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.

Order by: Score:
Another puff of smoke
by HereIsAThought on Tue 21st Nov 2017 11:31 UTC
HereIsAThought
Member since:
2017-09-14

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.

Reply Score: 3

RE: Another puff of smoke
by Bill Shooter of Bul on Tue 21st Nov 2017 14:55 UTC in reply to "Another puff of smoke"
Bill Shooter of Bul Member since:
2006-07-14

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.

Reply Score: 3

RE[2]: Another puff of smoke
by HereIsAThought on Wed 22nd Nov 2017 10:43 UTC in reply to "RE: Another puff of smoke"
HereIsAThought Member since:
2017-09-14

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.

Reply Score: 2

RE: Another puff of smoke
by zima on Wed 22nd Nov 2017 00:00 UTC in reply to "Another puff of smoke"
zima Member since:
2005-07-06

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?

Reply Score: 4

RE[2]: Another puff of smoke
by jpkx1984 on Wed 22nd Nov 2017 03:19 UTC in reply to "RE: Another puff of smoke"
jpkx1984 Member since:
2015-01-06

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.

Reply Score: 1

RE[3]: Another puff of smoke
by moondevil on Wed 22nd Nov 2017 09:36 UTC in reply to "RE[2]: Another puff of smoke"
moondevil Member since:
2005-07-08

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.

Reply Score: 3

RE[3]: Another puff of smoke
by zima on Thu 23rd Nov 2017 07:42 UTC in reply to "RE[2]: Another puff of smoke"
zima Member since:
2005-07-06

Java was open source also when Oracle took Google to court over it...

Reply Score: 3

RE[2]: Another puff of smoke
by jgfenix on Wed 22nd Nov 2017 08:27 UTC in reply to "RE: Another puff of smoke"
jgfenix Member since:
2006-05-25

It seems that developers target iOS first and Android later. Perhaps they want developers to use only one codebase to target both.

Reply Score: 2

RE[3]: Another puff of smoke
by zima on Thu 23rd Nov 2017 07:39 UTC in reply to "RE[2]: Another puff of smoke"
zima Member since:
2005-07-06

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

Reply Score: 2

Chrome OS Replacement
by Iapx432 on Wed 22nd Nov 2017 15:16 UTC
Iapx432
Member since:
2017-09-30

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?

Reply Score: 1

Reason?
by birdie on Wed 22nd Nov 2017 16:38 UTC
birdie
Member since:
2014-07-15

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

Reply Score: 3