I'm not really sure where it slots in in a world with a lot of programming language choices. Why would I use it over something like Rust, Go, or even JavaScript?

>Why would I use it over something like Rust, Go, or even JavaScript?

Honestly, mainly for flutter. But if you do chose flutter for your project, you will suddenly wish everyone was using dart for everything else instead of Java on android, or c#/Swift on ios ect. if that makes sense. If sound type checking is truly feasible on the web then I'd say dart should be there too. But I can't say if that's really the case. At least ECMA seems to think it isn't, at least for js.

> Java on android

You mean Kotlin?

Nah. Dart is ok. It doesn't perform as well as those peer languages. It's nice its FFI story is good, but the ecosystem is very weak even compared to Javascript.

As for the tooling. It's decent. I wouldn't call it amazing, unless you come from systems that were anemic to begin with, then it seems pretty amazing.

As for flutter. I recently installed it again. A test app with a single CupertinoTextField consumes 45% of an Intel core on a linux desktop (Wayland and X11 were similar). Like, goodbye. Maybe if WORA means iOS and Android, fine, I get that is the common use case. But that is wishful thinking to false advertising as far as I care.

https://github.com/flutter/flutter/issues/125388

https://github.com/flutter/flutter/issues/101591 (going on 2 years!)

I also believe Google will shit can both this and Fuchsia, because Google is CADT baked into its organizational structure.

The dart ecosystem is way richer than I expected it to be. So far I've found good options for everything I need and in more than a few cases the libraries are better designed than the JS equivalents.

I can't speak to Linux desktop performance but on the Mac my Flutter app sips CPU and memory.

Google abandoning it is a real risk. If they continue to support it I think Flutter has a great future.

So I tried the exact same test on a last gen Intel Macbook Pro. Same thing. 20 to 40% app CPU usage not including WindowServer. Putting cursorOpacityAnimates: false "fixes" it, seemingly similar to this:

https://github.com/flutter/flutter/pull/104335

This is more of an eyebrow raising signal to me. This is not quality congruent with a multibillion dollar company backing. If the cupertino widgets are in this sorry of a state they probably should be marked as such.

But perhaps someone more invested in the ecosystem may want to submit that pull request. It seems like low hanging fruit.

Sounds like this is specific to the Cupertino widgets? I’m not using those because I think they’re just going to put you in the uncanny valley of almost native Mac UI.

The material stuff looks good and performs well and at this point users have more desktop apps on their machine that don’t use native controls than do.

My flutter app is way more responsive and efficient than the electron prototype it replaced.

> 45% on an intel core on a linux desktop

Just tried it out. 3-5% in debug build. 0% on release build.

Let me guess, you did a TextField, not a CupertinoTextField? (It's 20% on release for me, still too much for a blinking cursor). Sure there may be some simple pathological bug in that one widget, but this quality issue in a fundamental widget in the official kit just does not give me the warm fuzzies, especially looking over the the github issue tracker.

And yes I am biased because it is google and they hardly dog food this product.

This particular problem is "fixed" by a simple cursorOpacityAnimates: false (which is apparently how they "fixed" TextField). That still doesn't speak well for QA. This is not really a complaint about a single widget. I really really want to like this stuff, but I have no confidence in it as a serious long term product.

https://github.com/flutter/flutter/pull/104335

Simple CupertinoTextField

> consumes 45% of an Intel core on a linux desktop

Like for 1ms? For a second? Eternally?

Eternally, as long as that text field has focus with the animation of a blinking cursor. I'm not telling my customers to make sure they're not "holding it wrong" by deigning to leave the app in the foreground and killing their battery.

CADT?

I think Dart really suffered from missteps in the early days. Originally, Dart didn't seem like anything special and it kinda wasn't. It was a dynamic language where optional type hints were suggestions and it'd be run in a VM just like JS and seemed like JS with some slight differences.

It feels like Dart became a completely different language that just happens to have the same name. It's now statically typed, has AOT compilation, null safety, etc.

I think that left Dart in a weird place in terms of mindshare. A lot of people likely looked at Dart 1, didn't see a real place for it, and haven't gone back to it. Google was also highly ambivalent about Dart for a while and most of the mindshare went to Go (despite the fact that I suspect most would prefer Dart).

In the end, it feels like Dart is lacking the ecosystem that other languages have. There's so much written for JS or Python or C# by comparison and so much of Dart seems to be in order to support Flutter.

Rust somewhat occupies its own place in the universe: people who want something a lot stricter than ordinary static languages where there's still a GC and still some runtime stuff. However, I think if Dart got more momentum it could be seen as a nice alternative to Java, JS/TS, C#, Python, etc. Note: I'm not saying that Dart has no momentum, but as you note it's mainly for Flutter.

On top of that, it was AdWords team that kept Dart 1.0 alive, while Flutter made Dart 2.0 happen.

It isn't much beyond Flutter making Dart relevant, other than the folks that decided to rewrite Sass into Dart I guess (I wonder when A RIIR will happen, like most JS tooling nowadays).

As someone who has written plenty of Java and JavaScript, Dart feels way more enjoyable to write. It just does. Maybe it's because I was less experienced when starting with Java and JavaScript, but it felt like there was a much smaller learning curve with Dart, too. I imagine it helps that I'm writing it in Android Studio, a JetBrains product, but I find the ergonomics better than even Kotlin. If you want to use it outside Flutter, you probably will wish it had a larger ecosystem, depending on what you're trying to write.

Actually Android is all about Java, Kotlin and C++, with a bit of Rust on the side.

All languages that have more use cases than being bound to a GUI framework, which is the problem with Dart.

I mainly just trust Bob Nystrom (https://news.ycombinator.com/user?id=munificent) to keep this thing on the rails. He's an excellent language designer.

> Rust

Dart has a GC.

> Go

Dart has exceptions.

> JavaScript

Dart is statically typed.

---

Plus....Dart has a first-class mobile story, unlike Rust + Go.

---

Hope that helps!

> Dart has a first-class mobile story, unlike Rust + Go

Not really, the Android team doesn't even list it as supported language, a team that belongs to the same employeer.

The same team not only lists Rust, it has official documentation on the Android site for OEMs, on how to use Rust.

Basically seamless multiplatform targeting - iOS, macOS, Linux, Windows, Android, web

Come for the Flutter, stay for the extras.

Exactly. I use it for a full stack mobile app development. Backend and frontend can share code. Server can be compiled to a single machine code binary.

That’s really interesting and compelling. What’s the rest of your backend stack look like? Do you get good performance from the database drivers written in dart?

Please do, because excluding minor exceptions, the more popular of recent programming languages have these as table stakes. Everything (even previously dynamic languages like python) has some form of static typing, options/null-safety, and really good tooling (ts ecosystem is huge, rust compiler has entire articles praising it for making people better programmers). Some languages might be slow to compile but have solutions like HMR for ts and are actively being improved in languages like rust.

Some form of static typing != proper static typing. The 'static typing' from Python (and other previously dynamic languages) do not come close to Dart's; neither does Typescript's.

All forms of null-safety aren't the same. The ergonomics differ.

Huge ecosystem != good tooling. But indeed, Rust has good tooling. Doesn't mean you can compare Rust to Dart though.

Rust's compile-time is improving, but why are we bringing in future items for comparison?