Originally designed as a successor to Javascript, Dart's syntax surprised me with how straightforward it was to learn. C-like with static typing, and close to C++ with its OO paradigm. So, a verbose language from a Haskell perspective, but does what it's told and as modern language with modern tooling pleasantly guiderails me away from footguns.

One of the guiderails I've really liked is leaning on immutability with its distinction between final and const. Where as const is a traditional compile-time constant variable, final is variable that stays constant after its initial runtime assignment. To extend usability of final, it can be prefixed with late as promise by the programmer to have it initialized before actually using it. Interestingly though, final does not mean much with classes. A class assigned to a final is still mutable. To mitigate this, you can use @immutable compiler macro to add some heuristics to see if a class is mutable or not.

The way Dart does optional types feels tacked on, revolving around null, but still, does what it is expected to do. The important thing is that all types lack null by default. With null-aware operators and ? notation handling null-able types explicitly is nice and fluid.

When initializing classes, Dart interestingly denies doing any function calls in default constructors. Only factory methods can be used for more involved class initialization. Multiple inheritance is also missing, with mixins filling in the role.

Flutter (and Dart) has a pronouncedly batteries-included vibe; the standard library is extensive and seems to cover the bases any mainstream app would require. Its association with Google though is clear: you have to run through hoops to avoid a Flutter PWA from accessing Gstatic for both the default fonts and CanvasKit. And to my experience, using local rather than CDN CanvasKit files is patchy. If I change the web renderer from auto to canvaskit, it suddenly starts fetching Canvaskit from Google CDN even with FLUTTER_WEB_CANVASKIT_URL set to local file.

Nevertheless for its arrogant vibe expected from FAANG corps, Flutter is a breeze to develop with and works mostly as expected on all 6 platforms (Win/Linux/MacOS/Android/iOS/PWA). Flutter is a "MVC+S" framework (S being Service), which on par with distributed architectures being the default. Probably makes GCP marketing team happy too.

Interestingly the skeleton template in Flutter divides the source code into folders named after features. I haven't written big enough projects that I would've run into the debate between features and types in project folder structuring, but apparently it's a thing. I do agree it's a good idea to use features as the naming scheme.

I wanted to write an exploratory prototype for a clock radio app that

• Shows time on a clock face 24/7 beside my bed, without disturbing my sleep.
• Can play internet radio channels and playing the radio works as an alarm

First I wanted to replicate the LED screen from my old clock radio. I didn't want to trace the screen, so I just drew an artesanal SVG off it.

All 30 elements were put into their own <1kB SVG files, so when the app inteprets current time into ABCDEFG 7-segment led, it looks like this in-app (I did rework the alarm into a bell). The clock face can be tapped to turn radio on and off

With a long press, I could then move to settings tab, and set my alarm time in my barebones-only-I-understand-what-everything-does settings tab.

For all intents and purposes, the clock radio was now ready.