Thanks, I had not seen this, only the earlier hack where some dev got the alpha version of ARC working on desktop OS's on his own, which I thought about mentioning here but didn't. I figured it wasn't that important.
Yes - my judgement (acknowledging I am stepping outside of my area of core expertise) is that this might turn out to be very important indeed.
It's a slightly crazy situation today where you have to develop for the Mac, Linux, Windows, iOS, and Android - and it's not even all that comfortable to use one language for the different ports. I acknowledge that there are choices that make it easier in some ways than this simplistic description, but none of these options from what I have read (but without experience so far) seem to be without their faults too.
[Tangent follows: We seem to be in a time when it pays to iterate rapidly. My interest and experience is more on the enterprise (or at least commercial) side, and there it is a real pain to deal with repeated updates from applications (that always seem to break things in their interactions with other things on Windows machines). I dealt with this personally in a similar way to a friend of mine who announced that he would be doing his own IT support henceforth and wished to be disconnected from the internal network and put on a DMZ. (Partner at a tech asset manager, so he could). But my point is - even at enterprise level, where it's a less obvious domain - some possibility that there are gains to be had (with appropriate restrictions, no doubt).
On the other hand, as an economist I believe that if a resource becomes free due to temporary abundance, human beings find a way to make use of it - but it takes time, and for a while people get into the habit of wasting things and have a rude awakening when it becomes rather less scarce (which may not happen gently, life being what it is). I reckon that might be happening with memory usage and efficiency (if you act like I/O is the bottleneck, in a few years you can be sure it won't be any longer) - and until this is the new consensus, I adopt the position of a native code fanatic (as a multi-year trading view, not for a lifetime)].
To be fair, they've actually done a lot to secure NaCl, unlike ActiveX. ;) But yes, nobody uses the Chrome Store: they seem to be trying to change that with ARC.
Yes - the concept was not necessarily mistaken, but their timing was off, and they (Microsoft) were not the right people to do it.
If we have Android support for ARM, what is the advantage of running in the browser on mobile devices? This is never going to work on iOS, because Apple doesn't allow full Chrome with NaCl on iOS, only the Chrome UI wrapped around Apple's local WebKit. WP? :D
Not so much benefit to running in the browser on Android, obviously, except that I am somewhat pickier about the apps I install than the websites I take a look at, and probably this is true of many people. Small frictions cumulatively have large consequences in an age of short attention spans, low future time orientation, and a lack of determination and nerve.
The benefit is you (if I have understood correctly - and I am not yet confident I have) can write something and have it be kind of usable across desktop platforms and android. (Presuming they do open up the app store - it looks like for now perhaps it is opened up to Arc-weld ported apps, but only for chromeos - although it is not clear). Of course you need to tweak according to the platform, and one shouldn't underestimate the trouble involved. But being able to produce something usable quickly is quite valuable.
As for converting native Android D apps to run on ARC, they don't mention NDK, ie native, apps on their ARC webpage, but the Chromium bug tracker shows that they're working on some kind of NDK translation layer (funny that they hit the same 64-bit long double issues on x86 that I did):
I think they might have it kind of working but maybe with glitches on native code. I don't know how much slow down is involved in the translation. Obviously ART/AOT changes many factors wrt relative advantage of native code (since it helps Java especially) - people say the difference is small, but the improvement in responsiveness doesn't seem small to me. But that doesn't detract from the possibly very appealing idea of being able to write in one language across everything. (except iOS).
As you said, NaCl requires a modified compiler that restricts the compiled binary to a more secure subset, so they appear to be translating NDK-compiled or our D code to what the NaCl sandbox accepts for it to work.
BTW here is what it looks like for x86: https://developer.chrome.com/native-client/reference/sandbox_internals/x86-64-sandbox#x86-64-sandbox Here is the API for a pure Chrome native client app: https://developer.chrome.com/native-client/c-api Here are some libraries that have been ported: https://code.google.com/p/naclports/wiki/PortList
But I'm skeptical that all these native workarounds in the browser will ever really amount to anything- they haven't so far- not because I don't believe in native, but because you're often still stuck in the browser, ie the horrible HTML/DOM/js stack.
But you are stuck because people use IE, Firefox, Safari etc? Or something else? It's worth taking a quick look at the native client demos - there was some python thing to fix to get them to work when I looked at a few months back, but I can't recall exactly what it was - a few lines needed to be changed for one of the python scripts used to install them.
I suppose they want to take the Android runtime everywhere, including the ART support that they're working on now apparently, so given the great success of the Android platform so far, who knows what will come of it.
I agree, although things don't change overnight.
