From 44f71923a8f350b87a6e634df561a4a6a58a9569 Mon Sep 17 00:00:00 2001 From: Harsh Shandilya Date: Sun, 7 Mar 2021 22:55:08 +0530 Subject: [PATCH] More words on Flutter [staging] Signed-off-by: Harsh Shandilya --- content/posts/my-flutter-experience.md | 36 +++++++++++++++++++++++++- 1 file changed, 35 insertions(+), 1 deletion(-) diff --git a/content/posts/my-flutter-experience.md b/content/posts/my-flutter-experience.md index def4584..b787cb8 100644 --- a/content/posts/my-flutter-experience.md +++ b/content/posts/my-flutter-experience.md @@ -22,7 +22,41 @@ The core and material libraries included in Flutter are great for building desig :warning: Hot take alert :warning: -Dart as a language still feels like it hasn't escaped its JavaScript roots. It has a lot of _implicit_ features that are not always desirable, such as [implicit interfaces] and most notably: [dynamic failsafe for type inference]. One could argue that rather than filling in with `dynamic`, the system should report that type inference failed and ask for the user to annotate the type themselves. The language also does not support [sum types], which makes modeling some situations harder than it needs to be. There are community developed libraries to fill in some of these gaps ([sum_types]), but they often involve codegen, which is another pain-point. +Dart as a language still feels like it hasn't escaped its JavaScript roots. It has a lot of _implicit_ features that are not always desirable, such as [implicit interfaces] and most notably: [dynamic failsafe for type inference]. One can argue that the type system should simply fail compilation if type inference fails and ask for the user to annotate the type themselves. This is what a lot of languages do! However, Dart opted for a weird middle ground where it will sometimes generate an error and sometimes assume the type to be `dynamic`, which basically means "anything". This lack of consistency leaves the door open for a variety of subtle type related bugs that would be resolved by always throwing an error. + +I'm not usually one to argue about subjective aspects like syntax, but I have to say I found Dart's syntax to be rather convoluted. I'll just drop an example here and move on, since this is a really pedantic talking point. + +```dart +// Given MyWidget1... +class MyWidget1 { + final String param1; + final int param2; + + MyWidget1(this.param1, this.param2); +} + +// ... it can only be initialised as: +final widget = new MyWidget1("Param 1", 2); + +// However, if I slightly change the constructor... +class MyWidget2 { + final String param1; + final int param2; + + MyWidget2(this.param1, {this.param2}); +} + +//... it can now only be initialised with an explicit name for param2 +final widget1 = new MyWidget2("Param 1", param2: 2); + +// The braces in the constructor also change the meaning of the parameters +final widget2 = new MyWidget2("Param 1"); + +// This code will compile fine, because parameters inside braces are optional. +// You can change that by annotating the parameter with @required. +``` + +The language also does not support [sum types], which makes modeling a variety of real-world situations much harder. There are community developed libraries to fill in some of these gaps ([sum_types]), but they involve codegen, which is another pain-point. ## Flutter tooling is (for the most part) great