Could you explain why? I have been interested, in theory, in Kotlin Multiplatform. But I'm already very comfortable in Dart and Flutter. I have decades of experience with Java, Javascript, and quite a few years with Typescript. Kotlin feels like a different kind of language, one I find grating. I think this is primarily aesthetic, but it's still enough to make getting over the initial hump annoying. As petty as it is, I think the lack of statement-terminating semicolons is a major reason I do not like it.
I would welcome a factual list of things that make the KM experience better for you.
Kotlin doesn’t feel right to me either. I did a portion of AoC in it this year and it was surprisingly more verbose than I expected. I think the thing I liked the least was trailing lambda syntax combined with how verbose it was to define variables with types.
It also inherits all of the bad parts of the JVM. Crappy build tooling (gradle), and then the slow startup and high memory usage.
Coming from writing a ton of Swift (and previously Obj-C), Kotlin’s ergonomics feel kinda off. It also feels like it’s different for the sake of being different more often than I’d like.
Can you give concrete examples? I played with Swift in school after already making the dive into Kotlin. It just felt like Kotlin but trapped on Apple. Part of the program even included a course in using a different language every couple weeks where we went through Scala, Lisp, and some others just to see what they could do.
Currently Kotlin is far and away my favorite language but I also haven't looked into the newer languages recently and am interested in hearing pain points people have. Especially if it isn't annoyances with Gradle
Broadly speaking, Kotlin deviates from popular conventions more than Swift does. For example, Kotlin expects you to use inline if statements where in Swift, ternary operators work like they do in C, JavaScript, and many other languages.
There's also things like Swift's guard statements that can help make intent clearer and read a bit more nicely.
Same opinion. It just feels off. Why use `fun` for function declarations instead of func or function? Dropping () before { makes it hard to tell what runs first. It feels like it's trying to be different for the sake of being different. I'm not able to quickly skim kotlin code like other 'C-like' languages and tell what is going on because it's trying to be too clever.
I used Kotlin as well and it just feels off too. The package support is a major thing, as I don't want to mess around in Gradle, I want something that Just Works™. Dart 3 has much of the same feature set as Kotlin now with sealed class support, it's just not as functional, but it recently got tearoffs so you don't have to specify the class, just the property, similar to Swift (ie if you have an `enum Color { red, blue }` and a function takes `Color`, you can just do `f(.red)` not `f(Color.red)`).
The main thing though is that Dart has pub.dev and a CLI that makes it extremely easy to add packages, via `dart pub add`. If I do want to go more of a functional route I'll just use Rust instead, it has all of what Kotlin has and more, plus a similar streamlined package management as Dart in the form of `cargo add`.
Darts pretty good. It has a lot of modern features, nullable types, pattern matching, sum types, and factory constructors; some really good build tooling. It can compile fully AoT.
Eh, it's getting there, slowly at first but more rapidly now. It now got tearoffs, I explained in another comment but
> if you have an `enum Color { red, blue }` and a function takes `Color`, you can just do `f(.red)` not `f(Color.red)`
Dart is getting new features pretty fast, they really started focusing on the DX more after Dart 2 and now especially after Dart 3. Macros were supposed to ship but it was incompatible with the goals of fast compilation, so other sorts of smaller features will ship instead.
Big turnoff with Dart is the lack of json (de) serialization -- kind of shocking to have to resort to source code generation libraries in a modern language.
Also, statement based instead of expression based, and not immutable by default are kind of a drag; not the end of the world but a bit unpleasant, IMO.
Serialization support is coming, probably this year. As for statements vs expressions, it does have some expressions such as if and for inside lists but changing it wholesale to an expression based language would be too much of a breaking change.
Serialization support has been coming for years, I lost patience.
Otherwise, yes, some support for expressions, some support for immutability, no support for optional semi-colons, no privacy modifiers so "_" littered everywhere.
I just found it to be an exceedingly ugly language when I used it a couple of years ago. Yes, some more pleasant modern functionality has been bolted on since then, but it's unfortunate that Dart was chosen as the backing language for Flutter, which is an awesome mobile framework.
Serialization has always been possible via libraries, so most people were doing fine with that, what is coming is native serialization support, but in practice it will be functionally the same, ie rather than you running build_runner, the compiler will do it for you. I'm not sure what you used but that's what you were hung up on, there were always ways to solve it.
Dart is a pragmatic language, it has everything you need and has a lot of benefits too, such as sound null checking (very few languages have this, Rust comes to mind), JIT and AOT support (Javascript / TypeScript such as for React Native doesn't, and Kotlin is just getting there with Kotlin Native but it still has a lot of issues), and now more functional programming concepts with algebraic data types via sealed classes and pattern matching.
What language would you have chosen when Flutter came out circa a decade ago, or, we can be even more charitable and ask what language would you use today if you were to implement Flutter? I'm curious because everyone has their own ideas but they all don't work for one reason or another.
isn't this just because Dart is way newer than those? it's from the 2010s. it's really modern in comparison (same generation as Kotlin swift and typescript)
Dart is hands down the best modern language out there for app development right now what are you even talking about? I understand that maybe a lot of people haven’t used it or maybe haven’t used it in years and that probably drives a lot of the FUD but for those who use it, it has stupidly high ratings from developers who use it and has for years.
Great progress! But smells a lot like the language I had it pegged for when "underscore as a wildcard" lands in February 2025, 2 years after pattern matching lands.
How did they ship pattern matching in 2023, with a million examples of how to do it right already hashed out and in the wild... and then not figure out a wildcard symbol for 2 years?
-
* Dart was awful, lost to Javascript because no one rated it highly enough to justify moving off Javascript, and was practically dead until Flutter dusted off the corpse and pivoted away from their browser goals... so super weird revisionism to act like we're talking about some beloved evergreen language.
> How did they ship pattern matching in 2023, with a million examples of how to do it right already hashed out and in the wild... and then not figure out a wildcard symbol for 2 years?
We shipped support for `_` as wildcards in patterns with Dart 3.0 when pattern matching first shipped.
However, prior to Dart 3.0, `_` was already a valid identifier (as it is in most other languages). The feature you're mentioning from last year was to remove support for uses of `_` as an identifier outside of patterns. This way `_` consistently behaves like a wildcard everywhere in the language. We didn't ship that in 3.0 because it's a breaking change and those are harder to roll out without causing a lot of user pain.
It's OK to not like Dart. There are multiple popular languages for a reason. But it is helpful when communicating about a language to others to be accurate so that they can make their own informed opinions.
Dart wasn’t awful. It wasn’t adopted at the time because it had a distinct runtime that would require splitting web in two which nobody wanted. On top of that it gave Google too much power, because now they would control both runtime (V8) + language (Dart).
TypeScript won and became king because it was pretty much JS 2.0 instead of JS++ like Dart.
In your version of history Dart was always a great language... but Google was simultaneously too powerful for other vendors to allow Dart to proliferate, but also too weak to sustain it themselves despite Chrome going on to do just that for many many web standards.
I'm sure that's a really cozy idea, but doesn't pass the "common sense" test: a bit like your random misuse of the term FUD.
-
The simple reality is it wasn't very good, so no one was rushing to use it, and that limited how hard Google could push it. ES6 made Javascript good enough for the time being.
Dart 1.x had a weak type system, and Dart 2 was adding basics Kotlin already had almost 2 years earlier: that was also around the time I first crossed paths with Flutter, and honestly Flutter by itself was also pretty god awful since it was slowly reinventing native UI/UX from a canvas.
(It was a lot like Ionic: something you used when you had a captive user-base that literally couldn't pick a better product. Great for Google!)
> In your version of history Dart was always a great language... but Google was simultaneously too powerful for other vendors to allow Dart to proliferate, but also too weak to sustain it themselves despite Chrome going on to do just that for many many web standards.
"In my version of history"
It takes two seconds to find this if you weren't there when it happened. Google had a fork of Chromium with Dart VM called Dartium, it wasn't a matter of resources. Industry flipped Google off, plain and simple.
Educate yourself before making such claims, the decision to not adopt Dart wasn't because of its technical merits as a language.
The rest of your comment is just your opinion, so you do you. I'm not a Dart or Flutter devrel team to sell you their product.
I guess this is the Dunning-Kruger effect everyone talks about!
To understand just enough to regurgitate what happened, but miss why it happened... and then assume someone who's pointing at the much more relevant why is just plain wrong.
Because the why requires actually understanding of things like developer mindshare rather than regurgitating search results.
-
The hint I'll leave if you're willing to consider maybe you don't know everything ever... look at who's feedback is being promoted when Chrome wants to do obviously unpopular things on the web: https://github.com/webmachinelearning/prompt-api/blob/main/R...
And model for yourself what happens if developer interest exceeds vendor refusal in magnitude, so Google just ships the thing, without a feature flag, to a massive percentage of the web-going world.
This is completely incorrect. Large companies like Canonical are all in on Flutter even now, they're making it the default for desktop UI development in Ubuntu and are writing a lot of their own apps in Flutter.
The "layoffs" were not any of the core team, it was just an offshoring, of infrastructure devs at Google that happened to work on Flutter builds, to Europe where they rehired for the same positions there.
Google Workspace has been moving to KMP. They said at KotlinConf that it has replaced their decade-old transpiler from Java to ObjC, which is very impressive.
Yes this is because they are starting with a Java codebase and that obviously makes sense there.
You have other platforms like Google earth who when it was time for a proper rewrite went with flutter and dart along with a bunch of Google cloud stuff and Google Ads.
That's funny, I found it the exact opposite, not the least of which is that it requires a JetBrains IDE to even run it. VSCode or neovim with Flutter and really most every other UI framework like React (and Native) work great.
Regarding KMP specifically, I didn't find it much use to only write business logic in one language, while still having to rewrite the UI up to 6 times (mobile, web, desktop), I'd rather have everything all in one.
Compose Multiplatform looks promising as it's Flutter-like in that it renders its own UI but it's still quite early, I know they say it's "stable" but when I used it, it really didn't seem so, plus the package support is extremely lacking compared to Flutter and of course the behemoth that is React (and Native)'s npm.
These days I'm looking forward to Dioxus, they're making their own native renderer similar to Flutter but especially for web, they are not doing the canvas trick, because they actually use plain HTML and CSS as their markup languages so they can compile directly to browser standards sites while still having a non-webview experience on mobile and desktop.
I think you're confused. It's not "something on top of Gradle". For instance to run on in Swift on iOS, it has to compile to native, and then it wraps it in a C interface and finally in a Swift interface. This has absolutely nothing to do with Gradle.
> For instance to run on in Swift on iOS, it has to compile to native, and then it wraps it in a C interface and finally in a Swift interface. This has absolutely nothing to do with Gradle.
And what exactly orchestrates the process of compilation (invoking Kotlin compiler + fetching dependencies)?
Whatever you want, really. The default just happens to be Gradle because that's the default on Android.
My point is that the fundamental difference between Flutter and KMP is not at all Gradle.
Last time I checked, Flutter was relying on messaging. KMP leverages FFIs. Flutter is a framework, KMP is not. If all you see is the command line you invoke to run the build, I think you're missing a lot.
