4 ms·

Thanks for taking the time to address concerns here. Much appreciated! Most of the anxiety and concern isn't from the Flutter project itself so I wholly empath

Thanks for taking the time to address concerns here. Much appreciated! Most of the anxiety and concern isn't from the Flutter project itself so I wholly empathize, but from Google's history in the dev space. Virtually anyone who had an AngularJS codebase knows what it means to depend on a Google OSS product that Google uses internally. > There are many millions of lines of code written that power everything from Ads to our internal CRM system. Google wouldn't be better off if we had to throw all that code away and start over. IIRC, when the AngularJS team came out with a brand new JS framework and called it "Angular", I believe the team explained how they automated migration of most of Google's "millions of lines" of complex internal codebase from AngularJS to Angular in a relatively short time, thanks to Google's internal infrastructure and tooling. You could do dependency analysis, build ASTs across projects, at "Google scale", and have special tooling, transpilers, compilers to migrate code across Ads and verticals in a fortnight. Google has the talent, tools, cash to take such grand measures and come to conferences to showcase how they did it. So the several million devs using Flutter are still undertaking a risk if Google deems targeting each new iOS version UX is too expensive, freezes contributions from internal devs, and starts internally migrating codebases to native with some shiny, new internal tooling. EDIT: If such a scenario does come to pass internally, I think the Flutter community would very much appreciate project leaders being upfront about it.

ssmsjm 4y ago
Let me just go cry over here in AngularDart.
timsneath 4y ago
Interestingly, that's exactly what is going on internally at the moment with Dart code, as we migrate the Google ecosystem to sound null safety, which was introduced in Dart 2 and will be the only mode in Dart 3. Adding a feature like sound null safety to a codebase the size of Google's is a large undertaking. It also brings a ton of benefit, both to the language itself and code that has migrated, since we can now provide guarantees around nullability that are not available in most other languages. But all the tooling we built for that multi-million LOC migration is open source, and available to everyone as part of the core SDK (https://dart.dev/null-safety/migration-guide#migration-tool https://dart.dev/null-safety/migration-guide#migration-tool). It's sophisticated, migrates much code automatically, and provides a visual editor to help make decisions about other code. That should be evidence at least that we care about migration. Every ecosystem goes through migrations at some point (Objective-C to Swift, Java to Kotlin, Win32 to UWP, etc.) Flutter isn't immune to that risk, but I don't think it's particular to Flutter either.
- sirius87 4y ago
  I suppose two issues are at play: centralized OSS project stewardship that alters direction every 3-5 years to meet evolving org goals, and people building consulting careers on top of OSS projects that are strongly aligned with org goals (extreme case for impacted users). At least some of your million dev userbase comprises of consultancy shops, contributing in part to your popularity by building products for their clients, but also making a buck with low effort on the underlying tech. They end up stitching codebases using unusual practices to meet deadlines that often blow up when a migration is upon them. Angular had a migration tool called ngUpgrade that was painful in the wild. All I'm saying is, these tradeoffs have now surfaced and crystallized.

ssmsjm 4y ago

Let me just go cry over here in AngularDart.

timsneath 4y ago

Interestingly, that's exactly what is going on internally at the moment with Dart code, as we migrate the Google ecosystem to sound null safety, which was introduced in Dart 2 and will be the only mode in Dart 3. Adding a feature like sound null safety to a codebase the size of Google's is a large undertaking. It also brings a ton of benefit, both to the language itself and code that has migrated, since we can now provide guarantees around nullability that are not available in most other languages. But all the tooling we built for that multi-million LOC migration is open source, and available to everyone as part of the core SDK (https://dart.dev/null-safety/migration-guide#migration-tool https://dart.dev/null-safety/migration-guide#migration-tool). It's sophisticated, migrates much code automatically, and provides a visual editor to help make decisions about other code. That should be evidence at least that we care about migration. Every ecosystem goes through migrations at some point (Objective-C to Swift, Java to Kotlin, Win32 to UWP, etc.) Flutter isn't immune to that risk, but I don't think it's particular to Flutter either.

sirius87 4y ago
I suppose two issues are at play: centralized OSS project stewardship that alters direction every 3-5 years to meet evolving org goals, and people building consulting careers on top of OSS projects that are strongly aligned with org goals (extreme case for impacted users). At least some of your million dev userbase comprises of consultancy shops, contributing in part to your popularity by building products for their clients, but also making a buck with low effort on the underlying tech. They end up stitching codebases using unusual practices to meet deadlines that often blow up when a migration is upon them. Angular had a migration tool called ngUpgrade that was painful in the wild. All I'm saying is, these tradeoffs have now surfaced and crystallized.