Thanks for the kind comments! I'm one of the product managers on the Flutter team, so you're welcome to apply suitable skepticism to anything I might say in response to your last point, but I will say that Flutter is already being used in many strategic projects here at Google, as well as for many customer apps, some of which already have tens of millions of users. For example, Alibaba are using it to build one of their big apps: https://www.youtube.com/watch?v=jtYk3gWRSw0

I don't know if this is helpful in assuaging your concerns?

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.

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) 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).

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".

Dart has had some null-aware operators for awhile (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".

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 (Unions) 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) 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.

I think you are attempting to present a solution to a problem you can't possibly help with.

No individual at Google can assuage any concerns caused by the corporation as a whole. (maybe the CEO could?)

Assuage =/= Eliminate

GP has certainly assuaged[1] (although not eliminated) my concerns.

[1] assuage, verb, make (an unpleasant feeling) less intense.

But it's a false premise. It seems like petting a dog on the way to the vet. The petting just calms the dog down, but has no effect on the inevitability of his situation.

So what value is a useless and pointless gesture that appears to be a marketing/public relations tactic?

Add null type annotation support to the big missing feature list. At this point every major mobile development language has nullability support, including plain old java.

I think nullability annotations have been the one major feature that have reduced crashes in the mobile apps I've worked on, and I've worked on some huge ones.

Seconded about the development experience. I wrote the same app in native Swift/Java, Flutter, and React Native. I did Flutter last, and even though I had never written a line of dart in my life, everything almost just worked.

There are still some really weird problems that occur, but after fixing those with `flutter clean`, it's hands down the best experience I've ever had making a mobile app.

If it were a google product, I wouldn’t trust it for a second. It seems that very few consumer facing products from Google are safe from being cut these days.

If google is using it internally, the risks change. After the Angular 2.0 debacle I’d fear Google Just up and changing everything and not providing a smooth migration pathway because they can. They probably won’t cut it, but that doesn’t mean that they won’t inadvertently hurt you really badly

Angular 2 is just very different product, smooth migration (reliable auto translating sources from js to ts?) would require a lot of effort..

From a marketing perspective, that was an awful choice. Releasing an effectively unrelated product and calling it 2.0 is just asking for trouble.

Second, they immediately announced no migration path and no more bug fixes at the same time. I’m not sure if they stuck with that, I was in the backbone camp at that time, but that is a painful pill to swallow. That they made that call without considering the downstream pain is a sign to me that I should be wary about depending on them

> and no more bug fixes

Angular 2 was released in Sep 2016. AngularJS continued releases up until Jul 2018, with 3 years of security fixes after that. 5 years is plenty of time to rewrite your app.

Either they backed down, or my memory is faulty. I recall at the time the announcement was that they were doing a hard cutover support wise. But since I wasn’t developing in Angular it was more of an interesting thing and not an immediate concern.

You’re right, 5 years is plenty of time.

There is a large and growing team supporting Flutter at Google. Flutter is here to stay, and even beyond Google's investment in it there's a large number of dedicated community contributors too!

I still don't see the selling point over Qt, Xamarin or using C++ with native views.

React Native is not something that I would even consider, for that I would rather do Web apps/PWAs.

I am a Qt developer by day and mobile dev in my free time. QML on mobile is very ugly when compared with Flutter and its not even close.