Dart vs Erlang

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

Erlang has strong roots with the telecom industry in which concurrent processes are normal. It's designed to be concurrent, to be used for distributed computing and to be scalable.

Fault tolerance means that a system has the property to continue operating even though one or more components have failed.

For Erlang systems, this means that the system is kept running even if for example a user has to drop a phone call rather than forcing everyone else to do so.

In order to achieve this, Erlang's VM gives you:

• Knowledge of when a process died and why that happened
• The ability to force processes to die together if they depend on each other and if one of them has a fault.
• A logger that logs every uncaught exception
• Nodes that can be monitored so that you find out when they go down
• The ability to restart failed processes (or groups of them)

In a real-time system it may not be possible to stop the system in order to implement code upgrades. For these cases Erlang gives you dynamic code upgrade support for free when using OTP. The mechanism is very easy to understand and works as follows:

1. Start the app
2. Edit the code
3. Recompile

That's all that is needed, the app updates with the new code while it's still running and tests are run automatically.

Erlang is made to be parallel and distributed. Because it's very easy to write code that uses multiple processor cores, it's also very easy to write applications that span multiple servers.

Erlang has been used in production for more than 20 years now. During that time it has proven itself over and over again that works great in both small startups and large-scale enterprise systems.

Erlang has been used extensively by Ericsson themselves. For example, the AXD301 ATM, which is one of Ericsson's flagships is probably the largest Erlang project ever with more than 1.1 million lines of Erlang code.

Erlang's processes have very little overhead (about 500 bytes per process). This means that a huge amount of processes can be created, even on older machines.

Erlang's processes run in a complete independent way from the OS (they aren't managed by the OS scheduler neither). This means that programs written in Erlang will run exactly the same way regardless of the operating system or platform.