Hacker News Reader

Comment by sandGorgon | Hacker News Reader

The engine’s C/C++ code is compiled with Android’s NDK, and the majority of the framework and application code is running on the Dart VM. The Dart VM generates JIT-compiled optimized native code on the device. (In other words, the Dart VM is not an interpreter.)

So Google is officially making its stand as Dart being the future of Android (the Swift of Android?).

Anybody who has worked on this and Kotlin, care to compare ?

EDIT: how does this work inside Google ? I mean you have legendary heavyweights behind Go. Were they designed as domain specific (Go for server and Dart for mobile)?

View on HN

  > Dart for mobile

Dart was originally designed for the client-side as a challenger to Javascript, and I consider it to have generally succeeded in its ulterior goal of spurring the Javascript standardization committee into greater velocity out of threat of competition. Recently it's pivoted towards server-side programming, though I could see it finding a home in mobile app development. Given its familiarity to Java, it was always more likely than Go to succeed Java on Android (though IMO less likely than a typed variant of Javascript).

To be clear I don't think this is an "official stand" proclaiming Dart as the future of Android (and regardless of Oracle's asshattery, I don't see Google outright removing Java support any time soon). As other commenters have pointed out, Google has more than one ongoing initiative in this area.

Am I wrong in thinking that Dart VM on Android is the only other VM that has been officially released by Google ?

Doesnt that make for a pretty strong statement ?

No. This isn't the same thing at all.

The C# runtime on android is used by thousands of apps; this is simply a dart runtime that runs on android.

This is a cool project; and its great to see people trying to do interesting things with dart; Dart as it currently stands is a total and abject failure in all of its goals as a replacement for javascript.

New goals for it to live as a mobile platform might give it a breath of fresh air. Pretty nice to see; it's a nice language with a good ecosystem, if it gains traction as a 'app' language, it could go places.

...but this is absolutely not Google saying 'the future of android is dart'.

>this is simply a dart runtime that runs on android.

User facing side of the framework is written in Dart. That means something.

Not really. The User facing side of unity is written in C#.

/me spins finger in the air...

This is like any other 'insert language here' mobile runtime with native bindings to the mobile apis (eg. camera, etc) and its own widget library.

Unity and kivy spring immediately to mind as examples of other ones. Hardly revolutionary.

Google is notorious for officially funding multiple competing solutions to every problem under the sun. I'm not trying to discount how important this is for Dart, but this announcement here doesn't carry even a thousandth of the heft as e.g. Apple's support for Swift over Obj-C.

Yes, that is wrong. They have also released V8.

> Dart was originally designed for the client-side as a challenger to Javascript, and I consider it to have generally succeeded in its ulterior goal of spurring the Javascript standardization committee into greater velocity out of threat of competition

Dart was never a threat to JS in anyway. I don't think it had any effect on ES spec. ES spec evolved "faster" because the committee changed, the old guard (anti OO ) moved on and Microsoft didn't sabotage the effort this time. Things were way different back in 2007 for those who remember it. MS had a commercial interest in not wanting ES4 to succeed ( Silverlight ) while ironically Adobe and the Flash team were pushing for a strong standard. So I fail to see how Dart has anything to do with ES6 success.

I tend to agree that Dart was never a "threat" to Javascript (smarter hackers than I have remarked at how difficult it would be to have both V8 and the Dart VM playing nicely together), but at the time of its announcement Dart (nee Dash) was certainly the cause of much consternation over potential fragmentation of the web. I recall more than a few of Brendan Eich's impassioned denouncements of Dart during that time. Dart's origin was just as much political as it was technical (though I do think it's transcended that origin to become quite a nice language, though still trying to find its foothold in the dev community).

> So Google is officially making its stand as Dart being the future of Android (the Swift of Android?).

It's almost never accurate to use "Google" as a singular noun. We are a very large company, and teams are given much wider latitude than at most other companies, so there is rarely a single official "voice" representing what Google is doing.

Instead, you have a lot of teams each working to make the best thing they can. Some of these projects overlap, sometimes they coordinate, occasionally they even compete with each other. Google is big, and the world is even bigger. There's a lot of room for different solutions to problems.

Exactly right.

I don't work for Google, but as far as I can tell Go was developed for helping with Google's internal server issues. They found the C++ code to be too difficult to get new Googlers acquainted with, and they had legal and other issues with Java. Dart on the other hand is a migration path for their heavy use of Java in front end areas for cross client-server usage with their GWT toolkit. It's also designed to make Javascript 'nicer' to use for some of their developers who do not like using Javascript.

However, Google is really big with a lot of differing opinions. They still have a lot of developers working on GWT. They still have a lot of developers heavily involved with C++ standards etc. So some Googlers are not going to be giving up Java or C++ any time soon. Some Googlers who really like Dart want to use it for everything. Some want to use Golang for everything. So the languages aren't really pushed or designed to be complimentary and they're more along organizational boundaries inside Google.

From the last words on the topic, Android itself is still staying fully Java and Dart or Golang will be alternative ways to deploy certain kinds of applications to Android which don't need very heavy integration. This Flutter appears to be closer to a Google replacement for javascript-based Cordova cross platform apps in the same way Dart is designed to be a replacement for Javascript websites.

  > they had legal and other issues with Java

Note that the legal issues with Java revolve around Google's custom implementation of Java that ships with Android, which is certainly not the version of Java that Google is using for its internal server programming.

Flutter ships with a functional-reactive style framework, inspired by React. Flutter gives developers access to any service or API that the host operating system provides, via Mojo’s IPC system

If I can write android apps with the SAME performance as Java, then this is effectively a replacement for me. I was seriously considering Kotlin, but with Google making a play here - this is the way I'll go.

It will always be slower than Java on Android, because you need to pay the price of JNI calls to the Framework libraries.

they are using Mojo to call native.

Had to search for what it is.

https://github.com/domokit/mojo

I doubt it is faster than Java ART for access to Android Frameworks.

Call JNI from C++ it might have delays around 300ms or more per call.

300ms for a JNI call? In all my years using JNI with Dalvik/ART i have never seen such a degradation. Can you give an example?

This is a number I had on my head from the "Using the NDK Performantly (Big Android BBQ 2015)" talk.

https://www.youtube.com/watch?v=Wb5HAI73QRE&list=PLWz5rJ2EKK...

From some examples using buffers, maybe I am wrong.

I think they update their benchmark results to https://chromeperf.appspot.com/ (browse for benchmarks with mofo prefix) Looks like pretty damn fast to me.

This is rendering performance.

I mean calling Android APIs via JNI vs calling them from Java.

It's a custom UI framework, you will only need to use JNI to call system services which shouldn't be a bottleneck - rendering engine is written in C++ AFAIK and it then uses IPC to talk with it.

Skia is already used by the Android UI stack.

IPC is usually slower than JNI specially on ART, because ART can optimize native calls across the boundaries better than Dalvik since the interpreter/JIT execution mix no longer happens.

That's assuming it is using Dart IPC -> Skia and not Dart IPC -> Higher Level GUI C++ rendering API -> Skia

> Skia is already used by the Android UI stack.

Android's hardware renderer does not use Skia for 2D drawing. So if your canvas returns true from canvas.isHardwareAccelerated() (and it should unless you're running on Gingerbread), it does not use Skia.

pjmlp, according to the FAQ, the mention the performance in a section

"You can expect excellent performance on both Android and iOS. Flutter is designed to help developers easily achieve a constant 60fps. Flutter apps run via natively compiled code, no interpreters are involved"

But I'm no Android developer so might just be marketing fluff.

I find that hard to believe. I think someone who doesn't understand the architecture wrote that or that Google opened a semi truck sized security hole.

Jit requires self modifying code. That's a huge security risk on devices which is why 3rd parties aren't allowed to ship jits. If Google makes a special case for Dart that would be a huge hole.

I'm guessing they just use AOT like the rest of us which is required on ios as well.

Android allows JITs. On ios one has to go through precompilation or use an interpreter. The current approach for Flutter is precompilation.

> So Google is officially making its stand as Dart being the future of Android (the Swift of Android?).

Where did you read that? They just provided a way to build Android apps with Dart (like you can with C# via Xamarin and other such frameworks).

Reply on news.ycombinator.com