What I meant to say in my original message is that if you are using system default-ish iOS UI styling, Liquid Glass is not optional decoration. If you have your entirely own UI and design system, sure you don't need it. But many of these Flutter apps or other such toolkits are using it to approximate system default UI except either without the Liquid Glass parts or with uncanny and incomplete approximations of it.

That's fine, as long as I have native OS dialogs/settings.

How much experience do you have writing mobile apps in Kotlin or Swift, as a comparison? I have worked in C++ for years, and in Swift for years. I have seen the exact same app being written both in Java and in C++.

> in C++ you can write performant code

This almost certainly does not matter for a mobile app, and definitely not for the UI part. In case your app has to do something that may need C++ (e.g. computer vision), then you can just call a C++ library over FFI.

> C++ isn't that complicated these days

I didn't mean that it is complicated. I can totally write C++. What I meant is that it is more complicated to get it right than modern languages. If users complain about a segmentation fault, it's often pretty tricky to debug. In Java/Kotlin, you will get an exception that tells you exactly which line crashed.

On top of that, C++ is slower to write. Again I have been able to compare teams working on the same app both in C++ and in Java/Kotlin/Swift (Java is not exactly a modern language, but still it's a lot faster to develop with).

And after all those disadvantages of using C++ for a mobile app, you end up with a UI that doesn't feel native to the platform.

Again: I still write C++ when it makes sense (usually that's for legacy reasons or libraries availability, otherwise Rust is a better choice IMO). But for writing a mobile UI? Doesn't make any sense to me.

Even for writing a Desktop app, I don't understand why people use Qt instead of e.g. Java. Kotlin/Compose seem to be coming on Desktop too, which makes a lot of sense to me. And maybe even Flutter.

Finally, I don't understand writing a cross-platform UI for Desktop and mobile. On mobile, I have a big finger and a small touch screen. On Desktop, I have a big screen, a mouse and a keyboard. Those require different UIs. Sharing the logic is fine, but the UI needs to be written for the platform.

Broadly speaking, Kotlin deviates from popular conventions more than Swift does. For example, Kotlin expects you to use inline if statements where in Swift, ternary operators work like they do in C, JavaScript, and many other languages.

There's also things like Swift's guard statements that can help make intent clearer and read a bit more nicely.

It's a matter of taste, even just the swift example on this website makes me raise eyebrows.

It is great if you’re comparing it against Kotlin or Swift, unless you’re stuck in an era of 1.x Dart.

Eh, it's getting there, slowly at first but more rapidly now. It now got tearoffs, I explained in another comment but

> if you have an `enum Color { red, blue }` and a function takes `Color`, you can just do `f(.red)` not `f(Color.red)`

Dart is getting new features pretty fast, they really started focusing on the DX more after Dart 2 and now especially after Dart 3. Macros were supposed to ship but it was incompatible with the goals of fast compilation, so other sorts of smaller features will ship instead.

> How did they ship pattern matching in 2023, with a million examples of how to do it right already hashed out and in the wild... and then not figure out a wildcard symbol for 2 years?

We shipped support for `_` as wildcards in patterns with Dart 3.0 when pattern matching first shipped.

However, prior to Dart 3.0, `_` was already a valid identifier (as it is in most other languages). The feature you're mentioning from last year was to remove support for uses of `_` as an identifier outside of patterns. This way `_` consistently behaves like a wildcard everywhere in the language. We didn't ship that in 3.0 because it's a breaking change and those are harder to roll out without causing a lot of user pain.

It's OK to not like Dart. There are multiple popular languages for a reason. But it is helpful when communicating about a language to others to be accurate so that they can make their own informed opinions.

You seem confused and indeed spreading FUD.

Dart wasn’t awful. It wasn’t adopted at the time because it had a distinct runtime that would require splitting web in two which nobody wanted. On top of that it gave Google too much power, because now they would control both runtime (V8) + language (Dart).

TypeScript won and became king because it was pretty much JS 2.0 instead of JS++ like Dart.

Yes this is because they are starting with a Java codebase and that obviously makes sense there.

You have other platforms like Google earth who when it was time for a proper rewrite went with flutter and dart along with a bunch of Google cloud stuff and Google Ads.