3 ms·

I heard Dart is also going native in Dart 2.0 I am not sure I really understand the trend The two most popular language (in the job market at least) are Java a

I heard Dart is also going native in Dart 2.0 I am not sure I really understand the trend The two most popular language (in the job market at least) are Java and C# It is weird, because Dart and Kotlin, are targeting being multi-platform, and the historical solution, was .. building a language that compile to byte code for a virtual machine But now the trend seem to have changed Now we have language, that compile to Javascript, webassembly, even C And this is seen as an improvement And DSLs were once very popular, I think this new trend of new languages that compile to everything, also goes againts building and using DSLs I am still a believer in using different languages for different levels (Ousterhout's dichotomy), but it will be interesting to see, how this goes

modeless 9y ago
Simple, it's Apple's stupid App Store policies prohibiting JIT compilers.
- eropple 9y ago
  I wouldn't call those policies "stupid", both from a security (a JIT compiler means you can't trust NX bits) and a battery-life/performance standpoint.
  - yorwba 9y ago
    But Apple's JavaScript engine uses a JIT as well, doesn't it?
    - pjmlp 9y ago
      Well, one can always advocate that they can validate and secure as much as possible their own JIT compiler, including special OS paths, whereas for 3rd party ones everything goes. Also Microsoft does exactly the same on store apps. Just Google doesn't, because they never bothered to ramp up Java AOT compilation at the store level, rather using everyone's batteries and since that went pretty bad, now they have a mix of interpreted/JIT/AOT.
  - modeless 9y ago
    The security argument is bogus. The benefit over W^X is miniscule. The battery life argument is even more bogus, as JITs are likely to be faster for dynamic languages.
    - eropple 9y ago
      The benefit over W^X is that they already have it in place and usable. A JIT, full-stop, is going to consume more battery in the general-purpose mobile case than compiled code will. Break-even points on performance certainly exist but mobile applications don't tend to run for that long. You might be okay with that tradeoff--and it is not an unreasonable one--but Apple does tend to prioritize battery life and performance over developer happiness on their mobile platform. And JIT and garbage collection are both red flags for iOS according to the people I know who've worked on the platform from a performance and a battery-life perspective. "But dynamic languages"--Apple doesn't seem to care about dynamic languages, do they? Aside from JavaScript, which uses their own, tested, internally blessed, JavaScript runtime. Developers might get frothy about that--but iOS is where the users who actually pay for things are.
pjmlp 9y ago
Java and C# have gone native since ever. Most people just don't pay attention to the tools available to them. .NET never used an interpreter. Code is either JITed on load, or compiled to dynamically linked binaries at installation time via NGEN. Mono always offered the option to AOT compile and its their default deployment mode in iOS. Then there is IL2CPP, CoreRT, Bartok MDIL and .NET Native. The only exception, regarding Microsoft implementations was the .NET Micro Framework, used for example on NETduino. On Java side, AOT was always available on commercial JDKs, specially the ones targeted to embedded deployment. Now it is finally becoming available on the free JDK (alternatives like gcj never mattered). Personally I am happy to see the mix JIT/AOT coming back. It was the way with Oberon, Lisp, Eiffel, Sather, and we just got distracted because Sun was religiously against providing AOT support themselves. EDIT: added reference to .NET MF.
resource0x 9y ago
dart never compiled to bytecode - there was no bytecode to compile to in the first place https://www.dartlang.org/faq#q-why-didnt-google-build-a-bytecode-vm-targetable-by-multiple-languages-including-dart https://www.dartlang.org/faq#q-why-didnt-google-build-a-byte...
afsina 9y ago
Dart story is a little different AFAIK. Flutter uses Dart. Flutter targets Android and IOS. IOS does not allow JIT. So they had to make AOT compilation (native) for Dart. Even before Dart 2.0 work started. In Android, first they used JIT but switched to AOT there as well. JIT is used in Dart console applications (server). The biggest change with Dart 2.0 is that it uses a sound type system (strong mode).

modeless 9y ago

Simple, it's Apple's stupid App Store policies prohibiting JIT compilers.

eropple 9y ago
I wouldn't call those policies "stupid", both from a security (a JIT compiler means you can't trust NX bits) and a battery-life/performance standpoint.
- yorwba 9y ago
  But Apple's JavaScript engine uses a JIT as well, doesn't it?
  - pjmlp 9y ago
    Well, one can always advocate that they can validate and secure as much as possible their own JIT compiler, including special OS paths, whereas for 3rd party ones everything goes. Also Microsoft does exactly the same on store apps. Just Google doesn't, because they never bothered to ramp up Java AOT compilation at the store level, rather using everyone's batteries and since that went pretty bad, now they have a mix of interpreted/JIT/AOT.
- modeless 9y ago
  The security argument is bogus. The benefit over W^X is miniscule. The battery life argument is even more bogus, as JITs are likely to be faster for dynamic languages.
  - eropple 9y ago
    The benefit over W^X is that they already have it in place and usable. A JIT, full-stop, is going to consume more battery in the general-purpose mobile case than compiled code will. Break-even points on performance certainly exist but mobile applications don't tend to run for that long. You might be okay with that tradeoff--and it is not an unreasonable one--but Apple does tend to prioritize battery life and performance over developer happiness on their mobile platform. And JIT and garbage collection are both red flags for iOS according to the people I know who've worked on the platform from a performance and a battery-life perspective. "But dynamic languages"--Apple doesn't seem to care about dynamic languages, do they? Aside from JavaScript, which uses their own, tested, internally blessed, JavaScript runtime. Developers might get frothy about that--but iOS is where the users who actually pay for things are.

pjmlp 9y ago

Java and C# have gone native since ever. Most people just don't pay attention to the tools available to them. .NET never used an interpreter. Code is either JITed on load, or compiled to dynamically linked binaries at installation time via NGEN. Mono always offered the option to AOT compile and its their default deployment mode in iOS. Then there is IL2CPP, CoreRT, Bartok MDIL and .NET Native. The only exception, regarding Microsoft implementations was the .NET Micro Framework, used for example on NETduino. On Java side, AOT was always available on commercial JDKs, specially the ones targeted to embedded deployment. Now it is finally becoming available on the free JDK (alternatives like gcj never mattered). Personally I am happy to see the mix JIT/AOT coming back. It was the way with Oberon, Lisp, Eiffel, Sather, and we just got distracted because Sun was religiously against providing AOT support themselves. EDIT: added reference to .NET MF.

resource0x 9y ago

dart never compiled to bytecode - there was no bytecode to compile to in the first place https://www.dartlang.org/faq#q-why-didnt-google-build-a-bytecode-vm-targetable-by-multiple-languages-including-dart https://www.dartlang.org/faq#q-why-didnt-google-build-a-byte...

afsina 9y ago

Dart story is a little different AFAIK. Flutter uses Dart. Flutter targets Android and IOS. IOS does not allow JIT. So they had to make AOT compilation (native) for Dart. Even before Dart 2.0 work started. In Android, first they used JIT but switched to AOT there as well. JIT is used in Dart console applications (server). The biggest change with Dart 2.0 is that it uses a sound type system (strong mode).