Hacker News new | ask | show | jobs
by satvikpendem 1228 days ago
They've answered why Dart many times. It's a language that fits their needs, since it has JIT, AOT, compilation to JS and now WASM. Back then there weren't many languages that could do all that, and even today there aren't many. Kotlin (and other JVM languages) and TypeScript (and other compile-to-JS-only languages) are already out since they are not AOT, only JIT even now.

More importantly, it was a Google language that they could mold for their own needs, not so possible if it's an outside language like TypeScript. For example, early on, they asked the Dart team to create an AOT compiler since Apple does not allow JITted code apparently (not sure how React Native gets around this then), or maybe it didn't back then, and the Dart team was able to do it successfully for the Flutter team. Try asking the TypeScript team to do the same, it's next to impossible.

For what it's worth, Dart 3+ introduces more functional parts like records, patterns, and exhaustive pattern matching so you can use it in a functional style if you want once that ships. There is also fpdart, for full functional support, and for brevity of code, since Dart has the ability to generate code via macros (with build_runner), you can also use packages like functional_widget, flutter_hooks etc to achieve a very functional code style as well, React-like.

This is a great podcast/video episode on how Flutter came to be, from the early days to now, and how it used JS in the beginning but it didn't serve their needs, as well as how it used to be more imperative until a declarative React-like model was then made.

https://www.youtube.com/watch?v=xqGAC5QCYuQ

3 comments

> since Apple does not allow JITted code apparently (not sure how React Native gets around this then)

With React Native you have two options. Use Apple's own JavaScriptCore engine which has special JIT permissions, or use Meta's Hermes engine which runs as a bytecode interpreter.

In either case you can always drop down to native code (Swift/Objective-C (iOS), Kotlin/Java (android), or C/C++ (any platform)) which can be used for anything compute heavy.

No, the ability to JIT is not per framework (I'm unsure how that would work?), it's per process. Using JSC doesn't give you a JIT - now the JSC interpreter is very fast, so it's possible claims that they "need JIT" are incorrect (back when I worked on JSC it was a common belief from people that the JITs were magic fairy dust, and so would come in to anything with a data-less assumption that a JIT was needed), it's also possible that "react native" is using wkwebview in which case the content would be running in a separate web content process with a jit.
I don't think React Native is using WkWebView. But that the introduction of WkWebView which allows JIT was the source of my confusion. I was under the impression that JIT was enabled for any uses of JSC in iOS at that time. But it seems that is not the case.

So the situation with React Native is that you can either use JSC, Hermes (or I believe V8 in jitless mode). All of which are interpreters. On Android you can of course use JIT (with either JSC or V8).

> Kotlin (and other JVM languages) and TypeScript (and other compile-to-JS-only languages) are already out since they are not AOT, only JIT even now.

There is Kotlin Native now.

Sure, not ten years ago though when it was first starting. Doesn't Jetpack Compose work similarly to Flutter in that it draws every pixel? If so, Kotlin native could be used there to bring it to web and desktop perhaps.
Java fits all the bills and Google already has ample experience/tooling working with it, including a very great java to js compiler.
Java, again, is not ahead of time compiled, or at least did not have a good solution for that ten years ago. Even Android apps now run as AOT compiled apps with Android Runtime (ART), discontinuing the Dalvik VM.
Java had AoT compilers for more than 20 years, https://en.wikipedia.org/wiki/Excelsior_JET

If Google really wanted they could have wrote one.

The fact that Excelsior is dead probably says something.

There are AoT compilers for Java, but I'm not aware of any successful widely-used ones. Java and the Java ecosystem rely pretty heavily on class loaders and reflection which make AoT compilation very difficult. Java in its bones is designed to be a JIT VM language and you'll always be going against the grain if you try to statically compile it.

Dart was also initially designed to be a JIT VM language (by the same folks who made the HotSpot JVM) but without many of the pitfalls in Java that make AoT hard, and over time we have deliberately evolved the language (in breaking ways!) to make it much more amenable to static compilation.

Languages are not all interchangeable and some languages are better suited for certain implementation strategies than others.

GraalVM native is quite a big thing nowadays, and reflection is not really a problem for AOT, class loading is more so, but that is easily solvable by assuming a closed world (the way Graal does it). So you just simply list all the classes you plan to reflect on/load and that’s it.

> Languages are not all interchangeable and some languages are better suited for certain implementation strategies than others

Sure, but I don’t claim to replace SQL or Prolog with Java, but a regular old managed language which has zero unique features that would give it a reason to exist.

> If Google really wanted they could have wrote one.

Which they did, but for Dart instead.

Which has zero ecosystem and just reinventing the wheel.
> More importantly, it was a Google language that they could mold for their own needs, not so possible if it's an outside language like TypeScript. For example, early on, they asked the Dart team to create an AOT compiler since Apple does not allow JITted code apparently (not sure how React Native gets around this then), or maybe it didn't back then, and the Dart team was able to do it successfully for the Flutter team. Try asking the TypeScript team to do the same, it's next to impossible.

Replace TypeScript with Java above.