Why Fantom?

I can not lie. I like Fantom.

I'm even a little evangelical about it, as you probably know if we've spoken. But why?

Yes, you can read the official Why Fantom as written by the creators, but that's nothing more than an un-inspired feature list. (Sorry guys!) So here I'm gonna tell you why, as a previous hardcore Java programmer, I'm now a Fantom convert.

1. Fantom is Boring

The number one reason why I like Fantom is because it's boring. There's no denying it. The language is pragmatic and dull.

Fantom is not a new dynamic fad for hipsters. It is not excitingly esoteric and it does not explore new programming paradigms in language extensions. Instead, Fantom is safe, statically typed and predictable, which lets me put all my energy and effort into writing exciting applications!

It means I'm debugging my code, not the language.

2. The API - It Just Works!

Java is old. Even Java 1.3 was tunring into bloatware but now, several revisions later, the API is huge and extremely unwieldy. Java always did have a knack of making simple things, hard. Lets take an example, reading a text file into a String:

Java:

BufferedReader br = new BufferedReader(new FileReader("file.txt"));
try {
    StringBuilder sb = new StringBuilder();
    String line = br.readLine();

    while (line != null) {
        sb.append(line);
        sb.append("\n");
        line = br.readLine();
    }
    String everything = sb.toString();
} finally {
    br.close();
}

You're messing around with BufferedReaders, FileReaders and InputStreams and that's before you've considered stream closing and system dependant character encoding!

Fantom:

File(`file.txt`).readAllStr

BOOM! Job done.

Want it system independent?

BOOM! Fantom is UTF-8 by default baby!

Fantom ships with a thoughtful and concise API that handles all those day-to-day tasks. Every corner of the core API is overflowing with useful methods. Useful being the key word.

Sure, Java has Apache commons, but most of it feels like "uncommon" usage and just an excercise in completeness.

3. Type Inference - Less Code

Why waste time telling the compiler what it already knows?

Java:

String name = "Mr Dude";

Fantom:

name := "Mr Dude"

Fantom isn't dynamic, it has types. And in the above snippet, name is a sys::Str. How does the compiler know? Because "Mr Dude" is a Str! Fantom can infer object types from what you assign to them. It's not rocket science.

Now lets apply this to lists and maps...

Java:

Map<Integer, String> map = new HashMap<Integer, String>();
map.put(Integer.valueOf("1"), "Value");

Lists and Maps in Java? Well, there's an entire Collections Framework for that! Knock yourself out with Collections, Sets, Lists and Maps, all sorted (or not) and all with a prolific number of implementations. Gee! Which do you use? Still not sure? Look to Apache, they have their own Commons Collection Framework!

"Argh! But I just want a bag of stuff?!" I hear you cry! Enter Fantom.

Fantom:

map := [1: "Value"]

BOOM! Job done.

Your default choices are List or Map No discussions. No frameworks. No brainer.

"But what of concurrency, threads and mutable state?" I hear you cry. Well...

4. Concurrency - Not An Issue

Java:

In Java there frameworks, articles and JSRs all dealing with the nebulus paradigm that is concurrency and shared mutable state. Working knowledge of the Java memory model and dudutious use of the volatile keyword are all required just to safely pass data from one thread to another.

Fantom:

Concurrency is not an issue.

I know, I know, it's hard to believe! But trust me on this, it's not. Fantom employs the Actor model for sending messgaes between threads but it goes beyond that. It simply does not allow mutable state to be sharted between threads. Not in messages and not in static data. To facilitate this, the concept of immutability and const classes are build into the language.

NPEs? Not here mate!

Null Pointers... sigh. Every Java developer has been plauged by the dreaded NullPointerException or NPE. Even the inventer, Tony Hoare has publically apologised for inveting them, citing it The Billion Dollar Mistake Java has classes and frameworks attempting to eradicate them - if you choose to use them. You can't even autobox safely without NPEs!

Enter Fantom: Int myInt BOOM! No nulls allowed! Want nulls? Int? myInt BOOM! We got those too!

What this means is, nulls are allowed, but you have code specifically for them. Everything is non-null by default. this doesn't eradicate NullErrs, but it goes a long way towards it!

Serialisable

Reflection

Closures