Google Is Working On Fuchsia OS Support For Apple's Swift Programming Language (androidpolice.com)

An anonymous reader shares a report from Android Police: 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. If you're not familiar with it, Swift is a programming language developed by Apple, which can be used to create iOS/macOS/tvOS/watchOS applications (it can also compile to Linux). Apple calls it "Objective-C without the C," and on the company's own platforms, it can be mixed with existing C/Objective-C/C++ code (similar to how apps on Android can use both Kotlin and Java in the same codebase). We already know that Fuchsia will support apps written in Dart, a C-like language developed by Google, but it looks like Swift could also be supported. On Swift's GitHub repository, a pull request was created by a Google employee that adds Fuchsia OS support to the compiler. At the time of writing, there are discussions about splitting it into several smaller pull requests to make reviewing the code changes easier.

Comments

Re:Isn't this backwards?

[Anonymous Coward]

"On Swift's GitHub repository, a pull request was created by a Google employee that adds Fuchsia OS support to the compiler."

Objective-C without the C...

[sconeu]

So, SmallTalk, then?

Re:Objective-C without the C...

[kwerle]

Absolutely not. Way closer to C++ or maybe C# in that it is all about compile time. Very little about the language feels dynamic. Nearly nothing.

I tried the beta, works as expected.

[Anonymous Coward]

I ran a one-line script to print "Hello world" and it uploaded 20Mb of data to Google's servers. It's almost ready for release.

What color do you want that OS?

[jfdavis668]

I think mauve has the most RAM.

Re: The decline of Linux

[Anonymous Coward]

This is a very real problem. Linux is losing the developer mindshare that it once had. Lots of developers are using macOS these days, and like you point out they aren't targeting Linux. Even if they're working on Android apps, Linux is so deeply hidden that it may as well not even be there. The BSDs are seeing a resurgence for server use, and Linux desktop use has withered with the failures of systemd and Gnome 3. I think that Linux may have plateaued, and now we are seeing the beginning of a decline.

Re: Swift is going strong. Rust? I think it's dyin

[Midnight Thunder]

Along those lines I like to break programming languages into two main groups: the languages that people use and the languages that will influence those languages. As an example: Java is a language that is used heavily in enterprise, while Scala influenced the direction of Java, without actually replacing it.

Of course this is a simplification of the reality, but this perspective seems to work well enough.

Re:Who's still going native?

[angel'o'sphere]

C is not that easy portable as many people think.

Zircon

[Misagon]

BTW, the microkernel at the bottom of Fuchsia has changed name from Magenta to Zircon.
Maybe because there's a Magenta Linux... I dunno.

Zircon has security based on capabilities (which it calls "handles", rightly so IMHO) for pretty much everything. This could support sandboxing of new sub-processes that you own, but it lacks revocation of rights from running processes that would be used as services -- which I find to be a serious omission.
IPC is very much like Unix domain sockets: with streams and queued asynchronous message passing... which means that it is never going to be faster than Mach ... and Linux is demonstrably faster than Mach. seL4 would have been a better foundation IMHO.

Re:Isn't this backwards?

[TheRaven64]

And for the guy who asked about Smalltalk - the Xerox machine which first used mouse and Icons was a hardware Smalltalk machine.

No it wasn't. It was a Xerox Alto. The Alto was a microcoded 16-bit system, and each language that was developed for it wrote its own microcode. The Alto processor was designed to execute bytecode, with each one being implemented by running the microcode provided for that index. Smalltalk bytecode was just one of the microcode implementations, the Algol virtual machine (for example) provided a different bytecode. This mechanism went out of fashion when people became interested in running programs written in more than one language without rebooting in between.