Hacker News Reader

The Flutter team has answered this question directly in a few public pieces:

https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf

https://flutter.io/docs/resources/faq#why-did-flutter-choose...

I personally already knew Dart, and had quite a bit of experience with it before I found out about Flutter, but honestly, I still don't see the language itself as _that_ much of a barrier to a platform to where it should be one of the most common criticisms of the entire framework.

After all, there _do_ exist alternative mobile development frameworks/infrastructure, in the other languages that people usually bring up as alternatives to Dart (ex. Kotlin, Java, Swift, C#, JS).

Thanks for replying, but I don't actually see the answer to my question here. They read like post-hoc rationalization, i.e., Given that Dart was chosen, what are some attributes of it that programmers found desirable?

Several other languages offer most of these desired features. Did anyone compare the effort required to add the remaining requirements to an existing language? That's what would make it an engineering decision.

Even if Dart somehow takes zero effort to learn, I'm still not convinced it was a net win.

Here's a podcast episode with Randal Schwartz on Flutter that you might find interesting, as it might shed some light as to how Flutter evolved from the Dartium project and how the Chrome team was involved.

https://softwareengineeringdaily.com/2018/07/11/flutter-in-p...

You can also skim the transcript (pgs. 3-6) Transcript here:

Going with Dart gave flutter - complied to machine code - fast GC - stateful Hotreload, a feature of the Dart vm use in dev builds.

My understanding is Dart originally started out with a vm along with a Dart-to-JavaScript compiler. The Dart team was also doing their own experiments in the iot and ios space.

Flutter, at that time it was call the Sky project/experiment, looked at several languages before give dart a go.

Apple only allows their JS VM on ios.

The nature of flutter, creating and discard many objects per frame, required a fast GC.

The hotreload feature was one the Flutter team didn't know they wanted, it was a suggestion from the Dart team.

So the Dart Team was able to meet flutters needs of creating a fast GC and being able to be compiled to machine code for ios and android as well.

"is there any feature of Dart that is required by Flutter?"

The Dart platform provides the following features:

- Subsecond hot reload

- AOT to ARM

- Bytecode interpreter for debug mode on IOS

- JIT for debug mode on Android

- GC tuned for Flutter's build methods. (like React's render)

Not aware of any other platform provides all of these features. Bolting these features on to another existing language and platform which wasn't designed with these goals would be hard.

Spend some time with Common Lisp, specially the commercial versions like Allegro or LispWorks.

Eiffel would be another possibility.

Then there was the way Oberon was originally designed.

The fact is that there is nothing special about Dart other than trying to save the language.

i dont think lisp is as popular...

i actually prefer a java like language than learn prefix calls and conj

Sure, the point being there is nothing special about Dart.

What it gets promoted as Dart special features for Flutter is also available in other languages, not only Lisp.

C-like languages have prefix calls; what you have to learn is that no commas are required and the opening parenthesis encloses the operator, not just the arguments. You were able to create a HN account, so I think you can handle it.

So much arm chair theorising, lol. Meanwhile someone has picked up the Dart tool chain and built a compelling framework with it. There is nothing "theoretically" special about this, but it is special in the "practical" sense that it exists, and I can use it today.

I can download it, install it, and get hot-reload on Android and iOS mobile devices while coding. I can swap out code at any layer of the framework since all of the framework's layout code and widgets are implemented in the same language as used to build an app.

Dart's performance characteristics and the combination of the AOT, JIT, and bytecode interpreter make this possible.

I write Clojure for a living. I like the elegance of Lisps. Clojure is mostly tolerable. The thing I like most about it is loading code immediately into the REPL. I hope more of the industry moves towards live programming. (or moves back to live programming, since I guess back in the Smalltalk days it used to be mainstream.)

Commercial Common Lisp compilers can also target mobile platforms, nothing theoric about it.

In any case, the issue is that Dart isn't a special snowflake with some extraordinary set of AOT, JIT, and bytecode interpreter not available to any other programming language.

There are plenty of programming languages that offer these applicabilities.

Flutter can be equality well implemented with any of them and I believe Dart is going to bet the cause of Flutter's failure, unless Google forces it upon us, e.g. replacing Android with Fuchsia.

Well for the mainstream VMs: Hotswap on the JVM is very limited, likewise with edit and continue on the CLR. Xamarin has live XAML updates, only for markup though. V8 is better at hot reloading, but then suffers on the performance front, since it's basically impossible to do efficient AOT for it.

So which languages/platforms do you mean?

Eiffel would be such an example, from the list I have listed.

Regarding JVM, hotswap is only limited if you constrain yourself to the OpenJDK basic features.

As we in the Java community are well aware, that are other options out there, like HotswapAgent and JRebel for example.

Commits adding Fuchsia support for ART started to land on AOSP, so lets see how much love Flutter/Dart will actually get from Google internal politics.

Haven't used Eiffel. Seems to compile to C and CIL, also GPL and likely even less popular than Dart. Jrebel dicontinued android support. Does hotswapagent support android?

Cool watching Fuchsia evolve. It will definitely support Android apps, otherwise google throws away their playstore monopoly.

Eiffel uses its own VM for interactive development, and compilation to native code via system C and C++ compilers. CIL and Java support is just a kind of integration support, the MELT VM is what matters.

Eiffel is a commercial language, with a GPL based license for open source projects.

It is also used in enterprise production code since the mid-90's, definitely more battle tested than Dart will ever be, which lets be honest it is struggling for survival.

Back to where this started: "is there any feature of Dart that is required by Flutter?"

This is me paraphrasing why the Flutter team think Dart is a good fit:

It's a familiar language for developers who have written JS, Java, C#, or C++. It has types to allow working on large codebases, and efficient AOT compilation. It has tooling for popular IDEs. Does subsecond hot-reload on iOS and Android (also more than just method bodies). It's performance, even on iOS dev mode is sufficient to do all of the layout and widget code. It's open source under liberal license which allows you to embed it your app.

Your claim: "There are plenty of programming languages that offer these applicabilities."

I don't think this is true. Even if you want to count Eiffel that's one, not plenty.

Nor could Eiffel have been used for Flutter since the GPL means you can't embed the VM in your app. Nor is it particular familiar for developers of existing mainstream languages.

Anyways, I agree that there's nothing "special snowflakey" about any of this technology, but no-one else, that I'm aware of, is shipping a language and toolchain that ticks all of these boxes at the moment. Hopefully someone will build this stuff for other popular stacks too.

(I am also aware of Eiffel. I remember hearing about it at uni back in the mid-90s when discussing CBD. I think it may be older than mid-90s too. I also don't think it would have been a very good choice for Flutter.)

Also what's with this whole "Dart struggling for survival" meme of yours. It comes off as kinda unhinged. Feel free to ignore the language. And people who like using it can happily ignore you.

Dart was dropped by Chrome and Angular teams, rescued from certain death by the AdWords team.

Without something like Flutter, the language has nowhere else to go.

The judge is how there regarding how Flutter adoption is actually going to take off on the mass market, outside a few agreements to show off at keynotes.

So seems similar to GWT which also saw little adoption outside of Google, and was used by the AdWords team. But here we are in 2018 and GWT is still ticking along with regular commits. I guess that means Dart is here to stay too.

And now Flutter is becoming popular and is being used by external developers. "Struggling for survival" is hyperbole today, and pre-Flutter, but agree this was true in the pre-AdWords days.

https://github.com/gwtproject/gwt/commits/master

> Hotswap on the JVM is very limited

It mystifies me why this has not been integrated into Sun's/Oracle's JVM and OpenJDK, since it's been available in other JVM implementations for a long time and is so obviously a hugely useful feature – with the agonizingly slow startup of Java applications you really need code reloading at runtime.

Anyway, the Android VM (ART) has Instant Run nowadays. It also doesn't support hot-swapping anything more than method implementations without restarting, but restarting on Android is not as painful as on the regular JVM.

https://developer.android.com/studio/run/#instant-run

Hopefully Flutter's popularity will bump the priorities of the other VM developers to improve code reloading.

The short answer is that the Flutter team wanted a language that was something like Dart, and the Dart team needed a killer app and was willing to put a lot of effort into satisfying Flutter's requirements.

It's unlikely that Flutter could have gotten that level of cooperation and influence over a more successful language, back when they were getting started and nobody had heard of them yet.

I spend most of my time with JavaScript, Obj-c and Java. It took me about 3 days to wrap my head around dart and start writing productive code.

I'd like to hear your opinions as well (e.g. how you manage states, what type of navigations (tab, stack, drawer) you used)

I suppose they're all more imperative and OO languages than not? Certainly they're more similar to each other than to Haskell or Go, for instance.

As for why Flutter uses Dart, this is the canonical answer: https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf

Kotlin strongly nudges the dev towards a more functional approach.

Even then it's miles away from Haskell. Kotlin is very close to Swift on the FP spectrum.

I got a reply here on hn awhile back with a similar question[1].

> Dart really is a big part of why the Flutter framework is as it is. Obviously you could design similar frameworks in other languages and have similar results, but there's really a very nice synergy between Dart's design and the Flutter framework, all the way down to small details like how garbage collection works in Dart vs how the framework happens to allocate objects.

So the rationalization seems to be performance.

[1]https://news.ycombinator.com/item?id=16476886

You're right, they are of course different. What I meant is that if you know any of those languages, your knowledge can be very easily mapped to Dart. I had experience with those langs before, and I was productive with Dart from day 1, it never felt like a problem to me. I'm just happy Google didn't go down the route of using JS like in RN :P