Flutter desktop isn’t there yet

There are AoT compilers for Java, but I'm not aware of any successful widely-used ones. Java and the Java ecosystem rely pretty heavily on class loaders and reflection which make AoT compilation very difficult. Java in its bones is designed to be a JIT VM language and you'll always be going against the grain if you try to statically compile it.

Dart was also initially designed to be a JIT VM language (by the same folks who made the HotSpot JVM) but without many of the pitfalls in Java that make AoT hard, and over time we have deliberately evolved the language (in breaking ways!) to make it much more amenable to static compilation.

Languages are not all interchangeable and some languages are better suited for certain implementation strategies than others.

This is a really good question. The reason is that it ensures that you can never see a field before it's initialized. In Java, you might think that you'll never observe a final field before it's been initialized but not so! In the constructor, you can call a method on `this` even before all fields have been definitely initialized. Inside that method (which might be overridden!), you can then read the field. It will be default initialized.

This means every time you create an object in Java, some extra code is running to default initialize all the fields just in case they get read before they're actually initialized. (I assume in some cases the compiler can prove it's not needed and eliminate it, but not in the general case).

It also means that the type system can't rely on fields being initialized for static safety. That in turn means that the compiler can't optimize based on that fact.

In Dart with the constructor initialization syntax, it's not syntactically possible to access any state on a new instance until after every single one of its initializers has run. That means that, in concert with null safety, if you have a non-nullable field, the compiler knows it will never ever be null and then can generate smaller, faster code based on that guarantee.

I agree the constructor initializer syntax is annoying and I wish we had something better, but it's there for a reason. Also, in practice, you often use `this.` or `super.` on the constructor parameters and avoid the initializers entirely.

> While stating itself to be statically typed you can also shoot yourself in the foot by simply using `as Type`, similar to TypeScript. Because that just assigns it to a type and doesn't cast it like you do it in say Rust.

An "as" expression is fully sound and will throw a runtime exception if the value isn't a valid instance of the cast type.

> The extreme use of classes with `abstract class` and whatnot feels kinda 90's to me, just a lot of abstractions and for what?

You don't have to use classes if you don't want to. You can define functions and variables all at the top level and write in a completely procedural or functional style if that's your jam. Some of the Dart packages I maintain are mostly functions.

> I think making it more functional would help it.

We're getting there. It's always had anonymous functions, closures, and plenty of higher-order functions in the collection API. We're adding pattern mataching and exhaustiveness checking now which should let you program in an algebraic datatype style.

Flutter is unquestionably designed mobile-first, with everything else a distant second. Flutter may be the best option for developing cross-platform mobile apps right now (I don’t know), but if you care about web or desktop, it’s not a particularly good choice. Things based on web tech are very likely to be better.

i've learned at least a half a dozen languages over the years, and dart is now my favorite. so much so that i am converting existing projects to it. for example, i have a series of scripts i wrote, in python, to automate away the boring parts of my job, which i am now converting to dart. at this point, for me, trying to get anything done in python is like wading through molasses. (like, why does almost any change to a python implementation file cause you to also have to revisit the imports section? ugh, i hate that so much.)

my number one change would be to add configuration options to the formatting tool you wrote. i can see why consistency is a virtue for large projects, but for me, it is strictly a hindrance. programming is thinking, and i really don't like you dictating the way i ought to think. (yeah, i know you won't do it, but that's my big one.)

my second big change would be to allow me to implement a big dart class in two or more implementation files. the business logic in the flagship flutter app i maintain is getting unbelievably complicated, and large chunks of it cannot be moved out of the one object it is in, due to inheritance reasons.