SoylentNews is people
SoylentNews
from the if-some-is-good,-and-more-is-better,-than-too-many-languages-is-not-enough dept.
Google will contribute changes to Apple's Swift programming language, and will support the language in the Fuchsia OS, a presumed replacement for Android, ChromeOS, etc. that is designed to work on all devices:
Fuchsia is Google's not-at-all-but-kind-of-secret operating system that's being developed in the open, but with almost zero official messaging about what it's for, or what it's built to replace. (Android? Chrome OS? Both? Neither?) The operating system's core is written in mostly C and C++, with Dart for the default "Flutter" UI, but other languages like Go, Rust, Python, and now Swift have also found a home in the project.
Of course, just because you'll be able to compile Swift to run on Fuchsia doesn't mean you'll be able to instantly port any iOS app to Google's new OS when or if it ships. While Apple has open sourced the Swift language itself, much of the iOS platform (like the UI stuff, for instance) is closed source, so code that relies on those closed Apple libraries won't be portable.
One possible future in a world where Fuchsia is an important and relevant platform for apps is that you write the "core logic" of your app in your language of choice — Swift, Go, Rust, JavaScript, etc. — and then you build a custom UI for each platform — Android, iOS, Fuchsia, Linux, Windows, the web — using the appropriate tools for each.
Also at Android Police.
Previously: Google's New Non-Linux OS: Fuchsia
Google's Not-So-Secret New OS
Google Fuchsia UI Previewed
(Score: 2) by DannyB on Monday December 04 2017, @02:46PM
I must strongly disagree with that.
I don't mind if the system allows you to select which GC algorithm to use. And if it provides lots of knobs and controls to tune it. (See Java runtime system.)
But GC must be built into the underlying runtime for any king of application programming language. For Systems and Microcontroller programming, stick to C, C++, Rust, etc. Although microcontrollers already are capable or running Java, Python, Node.js and other GC languages / platforms.
Why must GC be in the runtime platform?
This is one of the hidden strengths of Java. There are C and C++ programs and libraries galore. A major problem is that they have so many different memory management disciplines which make them all incompatible. Or make it difficult for a program to introduce another library that requires yet one more different memory management discipline.
In Java, there are libraries galore. An absolute embarrassment of riches. But they are all compatible. I don't care who creates what data structure. And nobody thinks about anyone being "responsible" to dispose of it. When it is no longer referenced, the GC will eat it.
I would also point out that GC has come a long way since the 1970's. A modern JVM can have dozens or even hundreds of Gigabytes (not Megabytes) of memory and only 10 ms GC pauses. Multiple vendors offer various solutions. Even the stock OpenJDK GC is amazing. But see Azul Systems Zing runtime for Java. You can have hundreds of cpu cores and hundreds of gigabytes and only 10 ms max GC pauses.
The thing about landline phones is that they never get lost. No air tag necessary.