Hacker News Reader

Comment by 0x_rs | Hacker News Reader

Dart is really nice to write in, with far less mental overhead than some of its would-be competitors that couldn't possess the same wisdom and foresight at the time of their creation, so an interactive shell for it is pretty cool. In general I think it's slowly trying to carve its place in the world other than Flutter's language (for which many great packages have been made), but it doesn't have any other forefront project or library, and probably still carries a bit of prejudice from the Dartium mayhem and being a language looking for some purpose that could be orphaned by a blind-sighted Google at any time, the Ads story about it still comes up often. I'd like to see it around more.

View on HN

I somewhat disagree.

Dart is a decent language for Flutter, but I’m not sure why you’d want to use it off of the flutter path. Maybe for CLI or other client-side tools? Either way, if you’re not re-using a dart package or using flutter, you absolutely should not pick it as your tool of choice.

The language seems nice syntactically, but I find it really frustrating in practice. It’s good enough for the “happy path” that was envisioned - basic UI hierarchies. It’s clear some team designed the language by first writing examples of what they wanted it to look like when making a UI. I think Swift UI caused similar complexities on Swift. You can confirm that even the contributors think this from reading controversial PRs in GitHub.

The nice thing about flutter, and Dart, is that it’s starting to take a life on outside Google. Google should hand off ownership to a foundation or other organization - especially now that their newest thing is Kotlin Multiplatform. I hear more and more companies writing flutter backends for their UI work, so hopefully it could survive alternative stewardship. I believe some TVs and car navigation systems now use flutter, plus all the google stuff.

Dart is my favourite language, it is the flutter framework I'm not so fond of. People literally designed better GUI frameworks than flutter 20 years ago. They did all sorts of weird things, probably for "performance" reasons, that forces the user to do things that kinda undo many of those "gains". Language wise, I love the fact that it comes with NULL safety out of the box, the number one feature I miss in GO-lang is NULL safety. NULL safety has very low cost to syntax or compile efficiency, and literally takes away half your program crash possibilities.

> People literally designed better GUI frameworks than flutter 20 years ago.

Which ones? Flutter is quite good, especially compared to things like Java Swing or GTK.

Delphi VCL, Windows Forms, WPF, Cocoa,

exactly. Borland era OOP gui code was amazingly well thought out. The flaws in the flutter framework are soooo many, a lot of half baked things are made standard. Try to get 2-way scrollbars working decently (try to nest them, or go watch the video tutorials that supposedly explain how to do this - it was an absolute horror show). There are so many hassle factor things that one googles or searches the github for, find tons of other smart people beg for it with examples and use cases and just watch the team say they won't implement for some or other reason. But even the simplest thing, that when you create a component (say with mutable state) - you don't create one class to get one widget defined, noooo you have to create two, one stateful and one stateless. All of these little weird decisions that were made for bs reasons eventually add up to a ton of incidental complexity. Oh we made part immutable for "performance" reason, but the real reason is that people don't understand when to avoid functional style programming idioms. All the weird ways the layout system can bite you, the way they designed constraints being passed down and sizes passed back up - boy are they forcing you to do a lot of thinking about incidental complexity, and the different containers and how thy interact in ways you would not expect by default. The fact that you cannot on a per container basis disable overflow displays in dev (many people have asked for this). That silly debug ribbon your app gets until you disable it LOL who thought that was a good default. In the end though one can make it do a lot, and it is reasonably performant. But the pitfalls are many, and basic stuff that it doesn't solve well for you.

Golang doesn't have an alternative ownership structure. Kotlin doesn't have an alternative ownership structure. Why is it important for dart and flutter? This feels like moving goal posts.

If there were major other entities seeking to participate in its development and advancement I could see a reason to change things, but that doesn't seem to be the case.

First, I was defending Dart/Flutters ownership structure - Google's support seems weak, but many other companies are taking a stronger interest in the ecosystem, so that's encouraging to it's long-term future. Meanwhile, Google seems to be turning to non-flutter tools in their approach to cross-platform development, so it is questionable how much support Google will give it long-term, as their needs change.

I think that Google should explicitly encourage and support the ecosystem by moving key tooling to a third party foundation, even if staffed by their employees - eg. the pub.dev package manager could be maintained independently and get a team dedicated to it. Google would be then free to drop support, or change direction, without dragging this great ecosystem down to stagnate.

Golang/Kotlin are seeing strong, and continued, support amongst their owners, and their support isn't questioned. That said, many people have questioned the direction of Golang because the only maintainers are Google employees, and they don't listen to much outside opinions for direction.

Kotlin is a Jetbrains product, not a Google one.

I don't think the OP was making that point just that Google is now USING Kotlin.

Reply on news.ycombinator.com