> Thanks for the elaborate answer! You probably have a higher standard on programming languages than I do. I understand that Dart is a very basic language, and comparing it to something almost academic like Haskell will probably make it seem real primitive and stupid. Coming from mostly frontend/UI product dev in C#/Java/JS I've had a blast with it though.
Well I spend a lot of my time yak shaving so :). Most of the time in the real world, Dart is good-enough (and is definitely better than JS without TS, from a safety/maintainability perspective).
You're absolutely right, Haskell is academic, but what impresses me about other languages was that they took little bits -- Rust took a lot, Golang took a tiny bit (protocols look more like type classes than class-based inheritance).
I'm somewhat surprised that you prefer it to C# though -- C# was supposed to be better Java, and I didn't think that Dart was better than C# outright. Maybe I'm wrong on that, if it feels more fun to use (i.e. easier so much so that it's enjoyable, but you're not frustrated).
> I do agree that some common patterns are contrived (BLoC, json serialization via codegen, etc), but I'm not sure it's fair to criticize the language itself for this.
BLoC isn't fair to criticize (it's more about Flutter), but JSON serialization is fair in my mind because it's the direct result of a too-weak type system. But yeah overall I'm making the typical HN ado about nothing. In the real world people would just pick flutter (for it's good parts) and commit.
> Also FWIW sound null safety is now the preferred way to write Dart (given your deps have adapted to it), so that part is hopefully solved.
First I've heard of this addition, and it's commendable that they're undertaking this herculean effort, but this is so meh. Typescript arguably has this problem (since it has to interop with JS), but the way you solve it is so simple there. Turn on strict mode, and you're done -- because they considered it from very early on (if not the beginning). Language designers should know what the state of the art is and make good decisions around it up front, this is like 10x worse than writing a bad framework, because you can't drop out (of the framework) -- there is nowhere to drop out to (I mean... yeah you could FFI or something ridiculous but...).
But anyway I'm just tilting at windmills -- people that have to get shit done will just get it done with Dart like they have with every other tool that is less-than-perfect. I'll just stay in my ivory molehill.