81–86 of 86 posts
It might sound stupid, but I'd really like to see flutter for desktop as well. Web too, hell why not?
You may appreciate https://github.com/google/flutter-desktop-embedding
I'm also working on a similar project.
I've been using flutter now for a few months and I love the workflow I can get in, quickly iterating and seeing the changes immediately. A side effect of the hot reloading I found is that I am able to build quickly and not worry about the style until later because I know changing the style is relatively easy and quick to iterate on itself. If you use VSCode, it really is a first class citizen, which makes me happy as…
Earlier quoted context omitted.
Or this: https://github.com/google/flutter-desktop-embedding I'm also working on a similar project.
Not sure if you meant to, but you posted the same link.
Earlier quoted context omitted.
> (I'm not aware of any cases where it's been done at this scale.) Facebook has done it twice at this scale: PHP -> Hack, plain JS -> Flow JS.
As far as I know, both Hack and Flow are unsound and don't do any runtime type checks to preserve soundness. It's a lot easier to migrate dynamic code to a static type system if you have the luxury of just ignoring the type system when you want to. :) In Dart 2, the type system is sound and checked at runtime in cases where it can be proven statically safe (downcasts, variance, etc.). That makes it a lot more work to…
Hack does check type hints at runtime, so it's "sound" in the same sense as Java might be. Is this the same sense in which Dart is sound?
> the type system is sound and checked at runtime in cases where it can be proven statically safe
I didn't understand this. If the code is statically proven safe, why would you need runtime checks?
Earlier quoted context omitted.
I'm on the Dart team (though I wouldn't necessarily take my comment to be an official statement of the entire team). > (no non-nullable types) I really wanted [1] to get those into Dart 1 (way back before Swift and TypeScript even existed), but I couldn't convince language team at the time that it was worthwhile. When we moved to a stricter, sound type system with strong mode, we hoped to get non-nullable types into…
> (I'm not aware of any cases where it's been done at this scale.) Facebook has done it twice at this scale: PHP -> Hack, plain JS -> Flow JS.
Both of these languages started out with strict null-checking — Hack because there were too many bizarre falsy values in PHP to allow otherwise, and Flow because it worked out so well in Hack. So neither had to tack on strict null-checking afterwards.
There have been some similar large-scale migration efforts. For example, Hack's record types were built on top of PHP arrays, which don't distinguish between absent and null values. Consequently, Hack's record types didn't distinguish between optional and nullable fields. Furthermore, records support width subtyping by default. This is unsound: you can construct distinct types A and B with A After a lot of effort, we did migrate the entire codebase to resolve this unsoundness. Essentially, we changed every record declaration to be an "open" record type and made all new records "closed" by default (referring to whether they supported width subtyping).
The analogue, then, would be something like refactoring every type declaration in every consumer's Dart code to be annotated as nullable, adding explicit null-checks, and allowing them to write non-nullable types as the default thenceforth.