4 ms·

I can't speak for everyone, but my problem with flutter isn't the framework - it's the language. Or, more accurately, the fact that it's not a JVM-based languag

I can't speak for everyone, but my problem with flutter isn't the framework - it's the language. Or, more accurately, the fact that it's not a JVM-based language. When Android came out, it was able to piggyback on millions of existing Java packages (such as Apache commons). When Kotlin came out, it was able to piggyback on millions of existing Java packages and Android packages (and even better, existing Java code can seamlessly forward work with Kotlin). Now, Google is using its muscle to drag everyone to its language which has pretty much no existing adoption. Oh. And many remember Dart being optional-typed (like Typescript).

porker 9y ago
Lack of libraries is a valid reason for preferring another language. But, when Go came out, there were no libraries. And it didn't get so much bad press.
- greenhouse_gas 9y ago
  >But, when Go came out, there were no libraries. And it didn't get so much bad press. 1. Go had a lot going for it when it came out (single, static, exe, memory safety). 2. Go's stdlib came with a lot out of the box. To the extent that you can write some fairly complicated code without touching a single library. 3. There was cgo.
allover 9y ago
> Oh. And many remember Dart being optional-typed (like Typescript). So? Some could argue it's a very productive approach.
- hota_mazi 9y ago
  Even the Dart team themselves stopped arguing it's a productive approach. Dart is going all strongly typed, after seven years of feet dragging. Dynamically typed languages are a thing of the past.
  - moocowtruck 9y ago
    it would be nice if dart had a more expressive type system, why do we say types are the future, then gimpy the language with basically a java type system to which most static type people will say is not the good definition of a static typed language?
    - hota_mazi 9y ago
      The Java type system is pretty solid, and the languages that followed (C#, Kotlin, Swift) improved only marginally over what Java had already done in that area. I think it's a great middle ground between no type system and what Haskell and ML offer.
      - moocowtruck 9y ago
        the java type system is unsound :D it's not very expressive... i mean i don't expect haskell level but i think we can do better than current java, especially for new languages
        hota_mazi 9y ago
        Unsound is what you want. Sound type systems are pretty much unusable.
- greenhouse_gas 9y ago
  >So? Some could argue it's a very productive approach. Some could. And others look at it and think "Python" or "JS" speed app. Oh. And harder to refactor/detect errors.
kyrra 9y ago
Flutter will be based on Dart 2 when it finally ships (I believe). Dart 2 requires strong-mode (aka: types are inferred/required, and will fail static analysis if you do unsafe things)[1]. You can read more about strong-mode here[2]. [1] https://www.dartlang.org/dart-2#strong-mode-and-static-typing https://www.dartlang.org/dart-2#strong-mode-and-static-typin... [2] https://www.dartlang.org/guides/language/sound-faq https://www.dartlang.org/guides/language/sound-faq
- greenhouse_gas 9y ago
  So I understand this correctly, Dart just pivoted language styles 7 years after being in stable? So all old Dart code won't work now? This seems much worse than the Python 2 - Python 3 jump.
  - wstrange 9y ago
    Type inference goes a long way to mitigate this. And most old code tended to use type annotations even though they were optional.
  - munificent 9y ago
    > Dart just pivoted language styles 7 years after being in stable? Yes, we are migrating to a new type system, previously called "strong mode". This is the main reason for the major version number bump to Dart 2.0. > So all old Dart code won't work now? Most Dart code works the same as it did before. A significant but relatively small amount will need a little love and migration to fix type errors. These are usually straightforward fixed. We have a lot of experience migrating code like this (Google's internal corpus of Dart code is now using the new type system). If you are other users run into problems, we are happy to help. Most external Dart users have already migrated their code to strong mode over the past year or two. It went as smoothly as you could hope and most of the feedback we got was really positive. For me, one of the main pieces of evidence in favor of moving Dart from optional types to the new static type system was how easy this migration was (relatively speaking). I'd claimed years ago that most Dart users already wrote in a fairly static style, and this helped confirm that. > This seems much worse than the Python 2 - Python 3 jump. Oh, heavens no. Most of the pain in Python as I understand it is around strings. Between 2 and 3, Python changed the meaning and runtime behavior of an existing very commonly used type. That's basically the hardest possible change to do (though I understand why they made that change). Dart's migration is more annoyingly in your face because it's tightening the static type system. Existing code may now have type errors and you have to fix them before the code can be compiled. But on the other hand, the type system will basically tell you all the code you need to fix to complete the migration without having to run anything. There are few scary migration bugs hiding in your code that you won't discover until much later. Once your error window is empty, you're almost completely done. And, in return, you get a much tighter static type system — a sound one, unlike, say, TypeScript — that finds more mistakes in your code than the old one did.
deeg 9y ago
And it adds to the already high level of churn in the UI development arena. Dart is a perfectly fine language but is it noticeably better than Kotlin? To use Flutter I have to learn a new framework, a new language, and rewrite pretty much all my app infrastructure that currently runs on the JVM.
- teen 9y ago
  To be fair, you can learn the majority of Dart in a a day or two if you're familiar with JS and Java. It's essentially the best parts of both.
- greenhouse_gas 9y ago
  >and rewrite pretty much all my app infrastructure Though, to be fair, you'd have to do that even if the Flutter was written in Kotlin. Maybe not the back-end parts, but the View would definitely have to be re-written.
akritrime 9y ago
I think its also to get people to look away from the JVM based things and prepare developers for its upcoming Fuchsia platform.
Hixie 9y ago
Flutter has a concept called "plugins" that specifically is intended to let you use existing platform libraries. That's how we implement things like notifications. Dart code talks to the OEM side that is implemented using the native library. See https://flutter.io/platform-channels/ https://flutter.io/platform-channels/
vlovich123 9y ago
Well Flutter does provide for a way to call into existing native code so I think that mitigates the code-reuse concern. The other thing to consider is that this advantage of code reuse was never realized to iOS. Writing apps for iOS & Android always meant having a C/C++ core with platform-specific shims; J2Objc more recently let you write it in Java but again that just lets you write the core in Java with 2 platform-specific independent frontend implementations. A lot of developers just wound up writing the app twice & shifting as much logic server-side as possible (which hurts battery too). This is the first time you can write the app once & run on both iOS & Android. AFAIK Dart is also only a requirement for the front-end. You are still free to use whatever language you want for your business logic. I'm not 100% clear yet on how good the bridging story is but I suspect it's not bad.
- greenhouse_gas 9y ago
  >Well Flutter does provide for a way to call into existing native code so I think that mitigates the code-reuse concern. Is it like calling Java from Kotlin (pretty) or C from Java (ugly)? > The other thing to consider is that this advantage of code reuse was never realized to iOS. iOS does interact well with C.
  - xster 9y ago
    Disclaimer: I work on Flutter You can call into Android libraries or SDK code from Java or Kotlin code via plugins on Android. You can call into iOS libraries or SDK code from Objective-C or Swift (as of 12 days ago https://github.com/flutter/flutter/issues/10968 https://github.com/flutter/flutter/issues/10968) code via plugins on iOS.
- snovv_crash 9y ago
  You could also use a C++ core with Qt/QML to target not only iOS and Android but also Windows, macOS and Linux, all from the same codebase.
  - BatFastard 9y ago
    Wow, let me stick the hot pokers in my eyes first! Qt/QML in a mobile app is something only a masochist could love.
Andrex 9y ago
Is Swift that much different? Genuinely asking because it seems like a similar situation to what you described.
tathougies 9y ago
You know... you can call almost any language from any other as long as both have some kind of FFI? It is high time we get over this ridiculous need that everything works with everything else without any added work. Writing software (for most) is a profession. You should expect to have to do actual work.

porker 9y ago

Lack of libraries is a valid reason for preferring another language. But, when Go came out, there were no libraries. And it didn't get so much bad press.

greenhouse_gas 9y ago
>But, when Go came out, there were no libraries. And it didn't get so much bad press. 1. Go had a lot going for it when it came out (single, static, exe, memory safety). 2. Go's stdlib came with a lot out of the box. To the extent that you can write some fairly complicated code without touching a single library. 3. There was cgo.

allover 9y ago

> Oh. And many remember Dart being optional-typed (like Typescript). So? Some could argue it's a very productive approach.

hota_mazi 9y ago
Even the Dart team themselves stopped arguing it's a productive approach. Dart is going all strongly typed, after seven years of feet dragging. Dynamically typed languages are a thing of the past.
- moocowtruck 9y ago
  it would be nice if dart had a more expressive type system, why do we say types are the future, then gimpy the language with basically a java type system to which most static type people will say is not the good definition of a static typed language?
  - hota_mazi 9y ago
    The Java type system is pretty solid, and the languages that followed (C#, Kotlin, Swift) improved only marginally over what Java had already done in that area. I think it's a great middle ground between no type system and what Haskell and ML offer.
    - moocowtruck 9y ago
      the java type system is unsound :D it's not very expressive... i mean i don't expect haskell level but i think we can do better than current java, especially for new languages
      - hota_mazi 9y ago
        Unsound is what you want. Sound type systems are pretty much unusable.
greenhouse_gas 9y ago
>So? Some could argue it's a very productive approach. Some could. And others look at it and think "Python" or "JS" speed app. Oh. And harder to refactor/detect errors.

kyrra 9y ago

Flutter will be based on Dart 2 when it finally ships (I believe). Dart 2 requires strong-mode (aka: types are inferred/required, and will fail static analysis if you do unsafe things)[1]. You can read more about strong-mode here[2]. [1] https://www.dartlang.org/dart-2#strong-mode-and-static-typing https://www.dartlang.org/dart-2#strong-mode-and-static-typin... [2] https://www.dartlang.org/guides/language/sound-faq https://www.dartlang.org/guides/language/sound-faq

greenhouse_gas 9y ago
So I understand this correctly, Dart just pivoted language styles 7 years after being in stable? So all old Dart code won't work now? This seems much worse than the Python 2 - Python 3 jump.
- wstrange 9y ago
  Type inference goes a long way to mitigate this. And most old code tended to use type annotations even though they were optional.
- munificent 9y ago
  > Dart just pivoted language styles 7 years after being in stable? Yes, we are migrating to a new type system, previously called "strong mode". This is the main reason for the major version number bump to Dart 2.0. > So all old Dart code won't work now? Most Dart code works the same as it did before. A significant but relatively small amount will need a little love and migration to fix type errors. These are usually straightforward fixed. We have a lot of experience migrating code like this (Google's internal corpus of Dart code is now using the new type system). If you are other users run into problems, we are happy to help. Most external Dart users have already migrated their code to strong mode over the past year or two. It went as smoothly as you could hope and most of the feedback we got was really positive. For me, one of the main pieces of evidence in favor of moving Dart from optional types to the new static type system was how easy this migration was (relatively speaking). I'd claimed years ago that most Dart users already wrote in a fairly static style, and this helped confirm that. > This seems much worse than the Python 2 - Python 3 jump. Oh, heavens no. Most of the pain in Python as I understand it is around strings. Between 2 and 3, Python changed the meaning and runtime behavior of an existing very commonly used type. That's basically the hardest possible change to do (though I understand why they made that change). Dart's migration is more annoyingly in your face because it's tightening the static type system. Existing code may now have type errors and you have to fix them before the code can be compiled. But on the other hand, the type system will basically tell you all the code you need to fix to complete the migration without having to run anything. There are few scary migration bugs hiding in your code that you won't discover until much later. Once your error window is empty, you're almost completely done. And, in return, you get a much tighter static type system — a sound one, unlike, say, TypeScript — that finds more mistakes in your code than the old one did.

deeg 9y ago

And it adds to the already high level of churn in the UI development arena. Dart is a perfectly fine language but is it noticeably better than Kotlin? To use Flutter I have to learn a new framework, a new language, and rewrite pretty much all my app infrastructure that currently runs on the JVM.

teen 9y ago
To be fair, you can learn the majority of Dart in a a day or two if you're familiar with JS and Java. It's essentially the best parts of both.
greenhouse_gas 9y ago
>and rewrite pretty much all my app infrastructure Though, to be fair, you'd have to do that even if the Flutter was written in Kotlin. Maybe not the back-end parts, but the View would definitely have to be re-written.

akritrime 9y ago

I think its also to get people to look away from the JVM based things and prepare developers for its upcoming Fuchsia platform.

Hixie 9y ago

Flutter has a concept called "plugins" that specifically is intended to let you use existing platform libraries. That's how we implement things like notifications. Dart code talks to the OEM side that is implemented using the native library. See https://flutter.io/platform-channels/ https://flutter.io/platform-channels/

vlovich123 9y ago

Well Flutter does provide for a way to call into existing native code so I think that mitigates the code-reuse concern. The other thing to consider is that this advantage of code reuse was never realized to iOS. Writing apps for iOS & Android always meant having a C/C++ core with platform-specific shims; J2Objc more recently let you write it in Java but again that just lets you write the core in Java with 2 platform-specific independent frontend implementations. A lot of developers just wound up writing the app twice & shifting as much logic server-side as possible (which hurts battery too). This is the first time you can write the app once & run on both iOS & Android. AFAIK Dart is also only a requirement for the front-end. You are still free to use whatever language you want for your business logic. I'm not 100% clear yet on how good the bridging story is but I suspect it's not bad.

greenhouse_gas 9y ago
>Well Flutter does provide for a way to call into existing native code so I think that mitigates the code-reuse concern. Is it like calling Java from Kotlin (pretty) or C from Java (ugly)? > The other thing to consider is that this advantage of code reuse was never realized to iOS. iOS does interact well with C.
- xster 9y ago
  Disclaimer: I work on Flutter You can call into Android libraries or SDK code from Java or Kotlin code via plugins on Android. You can call into iOS libraries or SDK code from Objective-C or Swift (as of 12 days ago https://github.com/flutter/flutter/issues/10968 https://github.com/flutter/flutter/issues/10968) code via plugins on iOS.
snovv_crash 9y ago
You could also use a C++ core with Qt/QML to target not only iOS and Android but also Windows, macOS and Linux, all from the same codebase.
- BatFastard 9y ago
  Wow, let me stick the hot pokers in my eyes first! Qt/QML in a mobile app is something only a masochist could love.

Andrex 9y ago

Is Swift that much different? Genuinely asking because it seems like a similar situation to what you described.

tathougies 9y ago

You know... you can call almost any language from any other as long as both have some kind of FFI? It is high time we get over this ridiculous need that everything works with everything else without any added work. Writing software (for most) is a profession. You should expect to have to do actual work.