5 ms·

Hey, thanks for the data point. I'm actually fairly interested in Flutter, but I have no interest at all in Dart since I find it severely lacking compared to mo

Hey, thanks for the data point. I'm actually fairly interested in Flutter, but I have no interest at all in Dart since I find it severely lacking compared to modern, more popular production languages for mobile development such as TypeScript or Kotlin (which have features such as algebraic data types which have become an absolute must-have for me and my team), to the point it completely deters me from adopting it. Is there any chance that the Flutter core could get bindings to another language in the future? Regardless, thank you for your work on Flutter; if not Flutter, at least it has paved the way for demonstrating a "native-imitation" makes a lot of sense with regards to developer productivity and performance, something that sorely needed more buy-in from the mobile community.

jrs95 8y ago
The great development experience is largely tied into Dart and it's toolchain, not to mention all of the underlying Dart code in the project. However, you can get the same kind of control flow out of Dart albeit with a little less static checking (https://github.com/dart-lang/sdk/issues/33079 https://github.com/dart-lang/sdk/issues/33079) so from a pragmatic standpoint this really shouldn't be something that's holding you back. The cost of not having ADTs is much lower than the cost of maintaining two separate iOS and Android apps (or even dealing with the downsides of other cross platform approaches IMO).
- mixedCase 8y ago
  Hi. Thanks for the workaround, it's fairly similar to how it's handled in TS, except more verbose (which TS is already very much so when compared to something like Elm). That isn't a problem for me since I have some experience with functional programming, but that'll likely be a serious disincentive for other devs (TS itself has been a problem already). Maybe I'm off the mark and that is idiomatic and a very common Dart pattern, and can be assimilated through familiarity? On another note, is there any workaround to have true non-nullable types? As far as the cost of having one codebase goes, right now it's somewhat of a worse is better approach; we're looking into something that heavily improves things and is worth rewriting our apps into. RN hasn't been it due to its FFI/bridge problems not making us comfortable and Flutter is something we've been looking into but the language has been a deterrant, so it's hard for us to argue "yes it's better on every metric and worth the effort".
  - jrs95 8y ago
    Dart has had some null-aware operators for awhile (https://news.dartlang.org/2015/08/dart-112-released-with-null-aware.html https://news.dartlang.org/2015/08/dart-112-released-with-nul...) otherwise you'll need to explicitly do null checks. It's certainly not perfect, but it's still "good enough" to make handling null relatively concise. In my experience code review can do a good enough job at promoting good practices around null handling that non-nullable types are really just a "nice to have".
danbalthasar 8y ago
Dart isn't perfect, and I think at the least would really benefit from Union types. There are some open issues related to these things though: https://github.com/dart-lang/sdk/issues/4938 https://github.com/dart-lang/sdk/issues/4938 (Unions) https://github.com/dart-lang/sdk/issues/421 https://github.com/dart-lang/sdk/issues/421 (Tuples) Please feel free to contribute here! That said, it's certainly possible to work around these things. Dart has a tuple library (https://github.com/dart-lang/tuple https://github.com/dart-lang/tuple) which covers a lot, and much of what you'd use Unions for can still be covered by accepting `Object` or `dynamic` parameter types and doing some typechecking.

jrs95 8y ago

The great development experience is largely tied into Dart and it's toolchain, not to mention all of the underlying Dart code in the project. However, you can get the same kind of control flow out of Dart albeit with a little less static checking (https://github.com/dart-lang/sdk/issues/33079 https://github.com/dart-lang/sdk/issues/33079) so from a pragmatic standpoint this really shouldn't be something that's holding you back. The cost of not having ADTs is much lower than the cost of maintaining two separate iOS and Android apps (or even dealing with the downsides of other cross platform approaches IMO).

mixedCase 8y ago
Hi. Thanks for the workaround, it's fairly similar to how it's handled in TS, except more verbose (which TS is already very much so when compared to something like Elm). That isn't a problem for me since I have some experience with functional programming, but that'll likely be a serious disincentive for other devs (TS itself has been a problem already). Maybe I'm off the mark and that is idiomatic and a very common Dart pattern, and can be assimilated through familiarity? On another note, is there any workaround to have true non-nullable types? As far as the cost of having one codebase goes, right now it's somewhat of a worse is better approach; we're looking into something that heavily improves things and is worth rewriting our apps into. RN hasn't been it due to its FFI/bridge problems not making us comfortable and Flutter is something we've been looking into but the language has been a deterrant, so it's hard for us to argue "yes it's better on every metric and worth the effort".
- jrs95 8y ago
  Dart has had some null-aware operators for awhile (https://news.dartlang.org/2015/08/dart-112-released-with-null-aware.html https://news.dartlang.org/2015/08/dart-112-released-with-nul...) otherwise you'll need to explicitly do null checks. It's certainly not perfect, but it's still "good enough" to make handling null relatively concise. In my experience code review can do a good enough job at promoting good practices around null handling that non-nullable types are really just a "nice to have".

danbalthasar 8y ago

Dart isn't perfect, and I think at the least would really benefit from Union types. There are some open issues related to these things though: https://github.com/dart-lang/sdk/issues/4938 https://github.com/dart-lang/sdk/issues/4938 (Unions) https://github.com/dart-lang/sdk/issues/421 https://github.com/dart-lang/sdk/issues/421 (Tuples) Please feel free to contribute here! That said, it's certainly possible to work around these things. Dart has a tuple library (https://github.com/dart-lang/tuple https://github.com/dart-lang/tuple) which covers a lot, and much of what you'd use Unions for can still be covered by accepting `Object` or `dynamic` parameter types and doing some typechecking.