Dart vs Utrecht Haskell Compiler

Dart is a single threaded programming language. So if any piece of code blocks the execution of the program, the program practically freezes. To avoid this Dart makes use of asynchronous operations which let your program run without getting blocked. This is done through Future objects.

A Future is an object which represent a means for getting a value at a certain point in the future. A function may invoke a Future and when that happens, two outcomes can be achieved:

1. The function is unable to return a value, so it queues up work to be done and returns an uncompleted Future object.
2. Or later when a value is available to be returned, the Future object completes with that value.

Dart includes a truly comprehensive core library, making it unnecessary to include disparate, external resources for basic functionalities Other than reducing the need to pull in various 3rd-party utilities this also ensures that all Dart code looks and feels the same.

Out of the box, the developer gets core libraries to help with: async, collections, strings, regexps, conversions, formats, file I/O, math, typed data, and more.

Dartium (Chromium derivative) is a browser with integrated Dart VM, which allows you to run and debug native Dart code during development for short edit-reload cycles. Only for testing on other browsers and deployment is transpiling to JS necessary.

Dart has a lot of tools available which help with developing Dart applications. Some examples of those tools include:

• pub - package and dependency management and build tool
• analyzer - static syntax analysis with linter, quick fixes, autocompletion support for easy IDE integration
• test - powerful and flexible testing framework and test runner
• dev_compiler - generate reusable JS instead of tree-shaken minified JS output (work in progress)
• dartfmt_ - source code formatter
• server-side VM
• observatory - a powerful tool for profiling and debugging running Dart code (for Dartium and Dart server code)

In Dart many browser differences (subtle differences and also missing features) are abstracted away or polyfilled. When Dart is transpiled to JS the output works on all supported browsers. There is usually no need to load polyfills or to consider browser differences during development. No need for libraries like jQuery to make the same code work the same on all browsers.

The language will look familiar to Java developers, easing the learning curve.

And yet, while it's similar, it has some nice syntax facilities to avoid common boilerplate code found in Java. Code is terser, yet readable.

Dart has an optional type system which makes Dart a great language for prototyping. It encourages developers to gradually evolve their programs without worrying about types first.

Dart was designed to be as expressive as possible. Ahead-of-time compilers can compile Dart code to efficient machine code. This is especially important when deploying to mobile where you don't want (or can't) use a JIT.

Strong mode applies a more restrictive type system to Dart to address its unsound, surprising behavior in certain cases.

Generators, also known as semicoroutines, are also a generalization of subroutines.
Generators are primarily used to simplify the control of iteration behavior of a loop, the yield statement in a generator passes a value back to a parent routine.

A generator is very similar to a function that returns an array, in that a generator has a certain number of values. But instead of building and returning an array that contains all the wanted values, a generator returns them one at a time, this saves memory and allows the caller function to start processing the first few values immediately.

Dart to Javascript compiler (dart2js) generates very high quality source code with very high optimization. The output code is also very readable and easy to understand.

Dart does not just compile to JavaScript, it also compiles to native code on mobile platforms like iOS and Android as demonstrated by flutter.io

No need to learn any new semantics, it's just a switch to a different compiler.

UHC uses a printf-like syntax for its FFI, which is flexible enough to minimize the need for wrapper functions, when, e.g., calling methods on objects. It also supports %*, for working with functions that take arbitrary parameters, such as concat.

UHC also has support for wrapper imports and dynamic imports, for passing Haskell functions as callbacks to Javascript, or dealing with curried Javascript functions, respectively.