3 ms·

If they had figured out a way to make Flutter use Kotlin back in 2015 before Android officially adopted it, I think it would have gained much more developer ado

If they had figured out a way to make Flutter use Kotlin back in 2015 before Android officially adopted it, I think it would have gained much more developer adoption. I don't think Kotlin is performant enough for Flutter though.

pjmlp 7y ago
The hard work is done by Skia, implemented in C++. ART is able to do several nice optimizations, including vector instructions, and uses a mix of JIT/AOT with PGO. Kotlin is performance enough, hence Jetpack Composer.
- filleduchaos 7y ago
  At the time (and to a large extent even now) Kotlin would have required shipping a JVM along (on non-Android platforms at least, and not a straightforward task at all on iOS). That's _far_ from performant for the use case in question.
  - pjmlp 7y ago
    As if Dart doesn't ship a runtime into all the platforms it runs on. A quite big one actually. That has nothing to do with performance, and plenty to do with storage space and download times, as anyone knowledgable how compilers work is well aware of.
    - scalatronn 7y ago
      > As if Dart doesn't ship a runtime into all the platforms it runs on. > A quite big one actually. yeah, whole 4,5 mb....
    - filleduchaos 7y ago
      Do you _really_ want to compare the size on disk and [default] memory requirements of, say, HotSpot to the Dart AOT runtime?
      - pjmlp 7y ago
        Yes, specially because we aren't speaking about Hotspot here, rather ART, Kotlin/Native.
        filleduchaos 7y ago
        - rather ART Is Android-specific, created specifically for Android, and it's almost as if the aim here was to develop a cross-platform framework that could at least target the two major mobile OSes in existence, one of which ships with literally zero Java anything. I brought up HotSpot because that's (part of) the canonical, actually-built-to-run-on-multiple-platforms JRE. - Kotlin/Native The state of Kotlin/Native is _far_ shabbier than the state of AOT-compiled Dart, and that's in 2020 (not, you know, 2014 when Flutter (then Sky) initially kicked off). It's interesting to me how in discussions like this people act as though the development of the project in question started literally yesterday.
        pjmlp 7y ago
        If Fuchsia never gets out the door, Dart is guaranteed to be another CoffeeScript. I guess the lack of mature libraries and integration issues with Android native APIs is one reason why we consider it a language started yesterday.
        filleduchaos 7y ago
        When I refer to a project starting yesterday, in case it was too difficult to understand, I was implicitly asking you for non-posthoc justifications for choosing Kotlin _in 2014_ to build a UI framework that - should target multiple mobile and desktop platforms (and not, like you seem to think, Android first or alone) - is a game engine style, Skia-backed project, which you are essentially trying to pick a scripting language for. So, do you actually have anything to back up Dart's runtime being a worse investment than your proposed ideas (which seem to be "go the way of Multi-OS Engine, that notoriously successful project" and/or "wait half a decade more for AOT compilation that would still be in beta and in a worse state than what we already have")?

pjmlp 7y ago

The hard work is done by Skia, implemented in C++. ART is able to do several nice optimizations, including vector instructions, and uses a mix of JIT/AOT with PGO. Kotlin is performance enough, hence Jetpack Composer.

filleduchaos 7y ago
At the time (and to a large extent even now) Kotlin would have required shipping a JVM along (on non-Android platforms at least, and not a straightforward task at all on iOS). That's _far_ from performant for the use case in question.
- pjmlp 7y ago
  As if Dart doesn't ship a runtime into all the platforms it runs on. A quite big one actually. That has nothing to do with performance, and plenty to do with storage space and download times, as anyone knowledgable how compilers work is well aware of.
  - scalatronn 7y ago
    > As if Dart doesn't ship a runtime into all the platforms it runs on. > A quite big one actually. yeah, whole 4,5 mb....
  - filleduchaos 7y ago
    Do you _really_ want to compare the size on disk and [default] memory requirements of, say, HotSpot to the Dart AOT runtime?
    - pjmlp 7y ago
      Yes, specially because we aren't speaking about Hotspot here, rather ART, Kotlin/Native.
      - filleduchaos 7y ago
        - rather ART Is Android-specific, created specifically for Android, and it's almost as if the aim here was to develop a cross-platform framework that could at least target the two major mobile OSes in existence, one of which ships with literally zero Java anything. I brought up HotSpot because that's (part of) the canonical, actually-built-to-run-on-multiple-platforms JRE. - Kotlin/Native The state of Kotlin/Native is _far_ shabbier than the state of AOT-compiled Dart, and that's in 2020 (not, you know, 2014 when Flutter (then Sky) initially kicked off). It's interesting to me how in discussions like this people act as though the development of the project in question started literally yesterday.
        pjmlp 7y ago
        If Fuchsia never gets out the door, Dart is guaranteed to be another CoffeeScript. I guess the lack of mature libraries and integration issues with Android native APIs is one reason why we consider it a language started yesterday.
        filleduchaos 7y ago
        When I refer to a project starting yesterday, in case it was too difficult to understand, I was implicitly asking you for non-posthoc justifications for choosing Kotlin _in 2014_ to build a UI framework that - should target multiple mobile and desktop platforms (and not, like you seem to think, Android first or alone) - is a game engine style, Skia-backed project, which you are essentially trying to pick a scripting language for. So, do you actually have anything to back up Dart's runtime being a worse investment than your proposed ideas (which seem to be "go the way of Multi-OS Engine, that notoriously successful project" and/or "wait half a decade more for AOT compilation that would still be in beta and in a worse state than what we already have")?