Dart added support for cross-compilation(dart.dev)
dart.dev
Dart added support for cross-compilation
https://dart.dev/tools/dart-compile#cross-compilation-exe
54 comments
Dart/flutter of course predates a lot of this stuff. But the point is that Kotlin and Kotlin multiplatform are things that happened to Google that they ended up endorsing and embracing (to their credit).
When they were digging in with the Oracle lawsuit, their Android Java support fell behind a bit. And then Kotlin showed up as a drop in replacement and quickly became the default for a lot of Android development. It was so obviously nicer than Java 1.6 that many Android developers didn't bother waiting for kotlin 1.0 to be released even. Java support was eventually upgraded for Android but that took a while. Google made endorsing Kotlin official many years ago. Kotlin is now the preferred language for Android development. And while Java is still supported, using it is probably a mistake for new applications as Java API support increasingly an afterthought in both Android SDKs and the wider library ecosystem.
Google also pushed Flutter as a completely new way of doing UI and targeted it at a completely new OS (Fuchsia) that would replace Android. That never happened and Fuchsia is basically still around on life support but otherwise not going anywhere. Meanwhile, Flutter seems well liked by some but it's also a bit a weird techstack with its own language and compiler and fairly limited integration options. In short that whole techstack seems increasingly a bit of a dead end.
And crucially, Google has always pushed back on the notion of building any support for Kotlin around flutter, which was an obvious thing to start doing years ago. There are some weak arguments about native compilation here. But Java/kotlin were always compiled ahead of time on Android. So, I expect that the dominant arguments here were non technical and boil down to not invented here syndrome.
And now kotlin multiplatform (endorsed last year by Google) and compose multi platform are there. Compose multiplatform is interesting because it extends Google's own framework to other platforms (IOS, Web, Desktop). That has been an obvious thing to work on for a while but Google didn't want to go there because it had Flutter. But now Jetbrains has done it for them. The multiplatform support on IOS is getting quite nice. Native compilation, easy bindings between kotlin and swift code (both ways), etc.
It will be interesting to see if Google rallies behind compose multiplatform as well. IMHO they should and it's an opportunity to get a bit of control over IOS development and wrestle that away from Apple.
When they were digging in with the Oracle lawsuit, their Android Java support fell behind a bit. And then Kotlin showed up as a drop in replacement and quickly became the default for a lot of Android development. It was so obviously nicer than Java 1.6 that many Android developers didn't bother waiting for kotlin 1.0 to be released even. Java support was eventually upgraded for Android but that took a while. Google made endorsing Kotlin official many years ago. Kotlin is now the preferred language for Android development. And while Java is still supported, using it is probably a mistake for new applications as Java API support increasingly an afterthought in both Android SDKs and the wider library ecosystem.
Google also pushed Flutter as a completely new way of doing UI and targeted it at a completely new OS (Fuchsia) that would replace Android. That never happened and Fuchsia is basically still around on life support but otherwise not going anywhere. Meanwhile, Flutter seems well liked by some but it's also a bit a weird techstack with its own language and compiler and fairly limited integration options. In short that whole techstack seems increasingly a bit of a dead end.
And crucially, Google has always pushed back on the notion of building any support for Kotlin around flutter, which was an obvious thing to start doing years ago. There are some weak arguments about native compilation here. But Java/kotlin were always compiled ahead of time on Android. So, I expect that the dominant arguments here were non technical and boil down to not invented here syndrome.
And now kotlin multiplatform (endorsed last year by Google) and compose multi platform are there. Compose multiplatform is interesting because it extends Google's own framework to other platforms (IOS, Web, Desktop). That has been an obvious thing to work on for a while but Google didn't want to go there because it had Flutter. But now Jetbrains has done it for them. The multiplatform support on IOS is getting quite nice. Native compilation, easy bindings between kotlin and swift code (both ways), etc.
It will be interesting to see if Google rallies behind compose multiplatform as well. IMHO they should and it's an opportunity to get a bit of control over IOS development and wrestle that away from Apple.
That usual Kotlin narrative keeps forgetting that Android Studio, Gradle, and Kotlin itself are built and depend on, Java based technologies, and there is no Kotlin without Java ecosystem, unless JetBrains ends up releasing a Kotlin Virtual Machine, and rewriting all the Android development stack on top of it.
Additionally, to prove this point even further, as the Java ecosystem keeps moving along happily, despite the anti-Java jabs typical among Android developers playing with Kotlin, ungrateful for its origins, the Android team was obligied to make ART upgradable via Play Store, and update its Java language support all the way up to Java 17 LTS, so that Android developers could still make use of Java libraries on Maven Central, that have moved beyond Java 8.
You should also have a look at Jake Wharton interviews regarding on how the Android team looked up on Flutter, Compose was pratically started as counter movent from the team, there might even still exist on Twitter some of his comments on the subject.
Additionally, to prove this point even further, as the Java ecosystem keeps moving along happily, despite the anti-Java jabs typical among Android developers playing with Kotlin, ungrateful for its origins, the Android team was obligied to make ART upgradable via Play Store, and update its Java language support all the way up to Java 17 LTS, so that Android developers could still make use of Java libraries on Maven Central, that have moved beyond Java 8.
You should also have a look at Jake Wharton interviews regarding on how the Android team looked up on Flutter, Compose was pratically started as counter movent from the team, there might even still exist on Twitter some of his comments on the subject.
I also agree, supporting both tools seems unnecessary. In my experiences Kotlin multiplatform and compose multiplatform is vastly more enjoyable to write instead of Dart. The development environment alone has also been much easier to get started with using Kotlin multiplatform.
With Android’s frequent releases starting this year, I doubt Flutter can keep up.
https://android-developers.googleblog.com/2024/10/android-sd...
https://android-developers.googleblog.com/2024/10/android-sd...
Flutter have been doing quarterly releases for years I think they are going to be fine, I don’t think Android doing 2 releases in a year is going to present any kind of problems whatsoever for them.
I love Dart as a language, but there were multiple choices made by Google that kind of ruined it outside of Flutter.
First, when it was still a viable Node.js alternative, Google only partially cared about that side. And when they did, they had someone make Shelf, which kind of killed a lot of web framework initiatives (including my own). Instead of building support tools, and fleshing out the stdlib, they were busy making competing libraries. And shelf was miserable to work in, and killed off a lot of desire to work on backend.
Second, at some point they just said F U to the backend and focused 100% on frontend, abandoning backend to whatever the current state it is in. I don't think they have improved anything on that front much.
Finally, when their gamble on Web/Frontend failed, and aliented all the tool/backend developers, Flutter was the only thing to save it.
Dart could have been a great Node.js alternative, but Google was too fixated on web. Typescript ate its lunch, browser devs said no, including Chromium team, and now Deno is a viable alternative to Node.js and Dart backend.
I still maintain a couple of my dart libraries, and have been for 12 years now i think (since Dart launched). maybe longer. but I don't do any other active dev in Dart. I just fondly think of what could have been anytime I go into those codebases.
First, when it was still a viable Node.js alternative, Google only partially cared about that side. And when they did, they had someone make Shelf, which kind of killed a lot of web framework initiatives (including my own). Instead of building support tools, and fleshing out the stdlib, they were busy making competing libraries. And shelf was miserable to work in, and killed off a lot of desire to work on backend.
Second, at some point they just said F U to the backend and focused 100% on frontend, abandoning backend to whatever the current state it is in. I don't think they have improved anything on that front much.
Finally, when their gamble on Web/Frontend failed, and aliented all the tool/backend developers, Flutter was the only thing to save it.
Dart could have been a great Node.js alternative, but Google was too fixated on web. Typescript ate its lunch, browser devs said no, including Chromium team, and now Deno is a viable alternative to Node.js and Dart backend.
I still maintain a couple of my dart libraries, and have been for 12 years now i think (since Dart launched). maybe longer. but I don't do any other active dev in Dart. I just fondly think of what could have been anytime I go into those codebases.
Thing is Dart is a shitty language with tradeoffs made specifically to make Flutter work well.
The terrible meta programming support shows in basic things such as JSON serialization. It's like Java--, I can't think of a reason to use it on backend over Java or Go.
It's not comparable to Javascript - despite it's warts, Javascript is very dynamic and when coupled with typescript that let's you do a lot of powerful things and describe it with the structural type system.
I have not used dart for a few years now but I've used it both when it was DartAngular and Dartium, and in flutter 2/3.
Don't get me wrong - the DX of writing flutter and fast reload is the best I've used in mobile space, but the language itself is terrible and I would not use it in any other scenario.
The terrible meta programming support shows in basic things such as JSON serialization. It's like Java--, I can't think of a reason to use it on backend over Java or Go.
It's not comparable to Javascript - despite it's warts, Javascript is very dynamic and when coupled with typescript that let's you do a lot of powerful things and describe it with the structural type system.
I have not used dart for a few years now but I've used it both when it was DartAngular and Dartium, and in flutter 2/3.
Don't get me wrong - the DX of writing flutter and fast reload is the best I've used in mobile space, but the language itself is terrible and I would not use it in any other scenario.
Java-- is an interesting comparison. I used Dart when I was at Google like a decade ago and my impression as I was learning the language was that it was like a scripting language variant of Java. I'd have called it "JavaScript" ;)
I haven't really looked at it since then but it felt like a lighter and easier Java at the time, which I was fine with. (I did a lot of Java in those days.)
I haven't really looked at it since then but it felt like a lighter and easier Java at the time, which I was fine with. (I did a lot of Java in those days.)
It's not my favorite language but Dart feels like a more modern less-verbose Java from another timeline. Features like sound null safety rule and writing Flutter apps feels nice, in no way Dart gets in the way.
That said, I prefer writing backends in Go. Less is more FTW.
EDIT: Also having the ability to compile it to JS, WASM, native for Android, iOS, Windows, Mac & Linux is a plus.
That said, I prefer writing backends in Go. Less is more FTW.
EDIT: Also having the ability to compile it to JS, WASM, native for Android, iOS, Windows, Mac & Linux is a plus.
Fair assessment, I am not quite as polarized, but there is a reason i use Go, Deno, and Typescript myself.
I feel like at this point Dart suffers from being a Google project: Google decides its fate, and Google has built a rather poor reputation when it comes to stability. I don't have concrete evidence, but I think the Google culture adheres more to the rolling release and move fast and break things ideology. I personally witnessed several of my own Dart projects needing serious refactoring after just a few years.
Also, I feel like Dart is a maximalist project. "Batteries included" also means a whole myriad of tools and libraries also at the grace of the Google Dart team.
Also, I feel like Dart is a maximalist project. "Batteries included" also means a whole myriad of tools and libraries also at the grace of the Google Dart team.
I think the main problem for Dart was that Typescript is simply the better approach for fixing Javascript (even though TS has its own share of problems with its 'kitchen sink type system').
> even though TS has its own share of problems with its 'kitchen sink type system'
Eh, people critique the kitchen sink type system but at the end of the day that system is why TypeScript took over, not a weird add-on you have to put up with to get it. It's what makes it possible to assign comprehensive types to ~every JS library, which is what allows TypeScript to gradually eat the whole JS ecosystem.
Any other approach stops short of the goal of being JS+Types, which means you end up with a different language with different semantics, which is where Dart failed.
Eh, people critique the kitchen sink type system but at the end of the day that system is why TypeScript took over, not a weird add-on you have to put up with to get it. It's what makes it possible to assign comprehensive types to ~every JS library, which is what allows TypeScript to gradually eat the whole JS ecosystem.
Any other approach stops short of the goal of being JS+Types, which means you end up with a different language with different semantics, which is where Dart failed.
Agreed for enabling gradually adding types to large JS code bases, but at the same time it's also used for very questionable 'template metaprogramming hacks' (which then result in pages-long and completely undecipherable error messages). It's a very similar problem to 'abusing' the C++ template system.
Go is doing exceptionally well while being a Google project. I don't think its a Google problem.
IMO Dart has become a niche Flutter language instead of a general-purpose language. Dart decided to focus on being a client-side language and it is very difficult to win over JS/TS.
IMO Dart has become a niche Flutter language instead of a general-purpose language. Dart decided to focus on being a client-side language and it is very difficult to win over JS/TS.
Go had the name of its authors to weight in. While I'm not of the type to give high weight in term of technical assessment. And I don't even mean C is praisable in term of influence it had on the industry. But without a doubt it did impact it deeply over a very long span of time. And at larger scale many people do love to follow their unquestionable prophets.
Being at Google helped, not that Alef, Limbo, Newsqueak and Oberon-2 were that huge commercial successes, and there is also the question how much influence would have C had in the industry if AT&T would be selling it from the get go, instead of the way UNIX and C were freely distributed across universities.
Many times it isn't the quality of the programming language alone, rather external factors that trigger its adoption.
Many times it isn't the quality of the programming language alone, rather external factors that trigger its adoption.
I think that's because it's of use to google internally. Dart and lit probably don't find as much use.
It suffers from being the Flutter language, it was already given as dead outside Google, had it not been for Flutter.
I also advise watching the Angular documentary, where they briefly describe being forced to adopt Dart by management was a friction point, only sorted by letting them go with TypeScript, and AngularDart be its own thing.
https://www.youtube.com/watch?v=cRC9DlH45lA
I also advise watching the Angular documentary, where they briefly describe being forced to adopt Dart by management was a friction point, only sorted by letting them go with TypeScript, and AngularDart be its own thing.
https://www.youtube.com/watch?v=cRC9DlH45lA
It's a Google project: Batteries included, and once the batteries are empty, they throw the whole thing away
> I feel like at this point Dart suffers from being a Google project
Not only Dart. Lit was completely abandoned without any public announcement. Soon it should be added to the killed by google website.
Not only Dart. Lit was completely abandoned without any public announcement. Soon it should be added to the killed by google website.
wtf are you taking about with “completely abandoned”? https://github.com/lit/lit/pulse/monthly
Abandoned doesn't mean dead (yet). Google don't care and don't spend a dime on it anymore but they "forgot" to tell that to people using lit.
Dart is one of the most underrated language out there.
Paradoxically is alive thanks to Flutter, but is also not as popular due to Flutter.
Paradoxically is alive thanks to Flutter, but is also not as popular due to Flutter.
Dart is easy to learn. If you've been around a while and know a few c-like; the gotcha hits pretty quickly. Nice tooling, good documentation and generally no surprises good or bad.
Dart is such an amazing language. I really wish it gained traction in more industries.
In two companies we already gave up on Dart and Flutter because of how it's backwards incompatible is. The language and frameworks moves very fast, it develops new tools and classes before the old ones become mature enough and adopted by the industry. Then suddenly, Flutter 27 lands, requires Dart 45, which requires intl 81.2.5. and now you can't compile anything anymore. Whole upgrade process, tools, compiles and libraries are broken for months before Google and OSS catches up. Once ecosystem is on Flutter 27 your upgrade path takes weeks, because a core method was renamed or compiler flag removed and CI/CD is failing. So you just move back to Java and Kotlin, where code from 2012 still compiles and works just fine.
mhoad(3)
Genuine question: what do you think is amazing about the language?
Tooling, documentation, language design, balance across a million different competing goals, interoperability, deployability, simplicity, expressivity and much more.
It’s just a REALLY REALLY nice modern language with a team of very smart people behind it who very clearly sweat the small details and have a long history of being able to make great decisions along the way even in ambiguous situations where it’s not always clear what the best path is going to be.
It’s just a REALLY REALLY nice modern language with a team of very smart people behind it who very clearly sweat the small details and have a long history of being able to make great decisions along the way even in ambiguous situations where it’s not always clear what the best path is going to be.
Tooling, to start with.
First party lsp and plugins for IntelliJ, VSCode, formatter, test, Flutter, etc.
It’s like Go meets Java, but in a great way.
First party lsp and plugins for IntelliJ, VSCode, formatter, test, Flutter, etc.
It’s like Go meets Java, but in a great way.
> It’s like Go meets Java, but in a great way.
I am struggling hard to imagine how any greatness could be achieved from that. Can you say a bit more?
I am struggling hard to imagine how any greatness could be achieved from that. Can you say a bit more?
Dart allows you to write compact and clean code, like GO.
Dart properly supports classes and is feature-rich, like Java.
I think those are the main points for the above comment
I think those are the main points for the above comment
Compact and clean is very far from my experience writing a very simple library management app with flutter. The framework literally gets in the way. You can't do anything without having to deal with some convoluted callback mechanism. You can't manipulate any object without some forced async crap. And it's so verbose. Despite my best efforts to keep things clean and organized, I get lost in the very small codebase after a couple of weeks. It's got to the point where I'm just rewriting it with Qt quick instead. It was my first time touching both flutter and dart, so maybe it's all subjective, but right now I think it's just a badly designed language/framework.
We must have very different definitions of compact, with Go requiring dozens of lines of boilerplate where other languages make do with one line of '?' or '.filter'.
I think we know what made it not popular then
Amazing tooling meets more than okay language.
Agreed, one of my pass the time activities during covid was basically just spending the year trying out and evaluating different languages across a whole range of different metrics and features. For me Dart was the clear winner and I’ve never once regretted making it my new default, in fact it’s only increased its gap compared to everything else in the time since then.
[deleted]
I love Dart and Flutter, it's my go-to when starting a new app idea.
I want to learn Kotlin, but something about it just keeps me bouncing right off. It's ugly to me. It does not look like a serious language. I know that it IS, but I just hate reading/writing kotlin. Dart fits right into the well-worn grooves in my brain established from decades of Java, AS3, JavaScript and Typescript.
https://github.com/dart-lang/sdk/issues/28617 provides some commentary on where things are, and what might happen next.
dart's always been solid for me but barely see it in big companies tbh - something stopping adoption or is it just stuck in its lane?
It’s only maybe for the past two years now that it’s even been promoted as a general purpose language, which I think was a huge oversight on the Dart team’s behalf. For a long time they would just promote it as a great way to build UIs. What ever drove them to talk about it like that originally is beyond me.
The competition is too strong. At a team or organization level, where neither uses Flutter, why would you use Dart when C# and Kotlin exist? Both have better performance, better UX for doing common application tasks and vastly bigger ecosystems.
Additionally, none of them are tied to a UI framework as survival, had it not been for Flutter and Dart would be long gone.
I think the idea was you can make a UI using one codebase for iOS and Android.
https://blog.jetbrains.com/kotlin/2025/05/compose-multiplatf...
Also the web stack (incl Wasm) got some big updates.
https://blog.jetbrains.com/kotlin/2025/05/present-and-future...
Why would Google still invest in Flutter and Dart when Kotlin is becoming this versatile?
Are there long term advantages with Dart which I am missing?