A common first reaction to Fantom is "nothing really new or novel". Its an interesting comment because this is by design. Fantom is not an academic language designed to experiment with novel programming language features. Rather we set out to build a pragmatic language which would elegantly solve the problems software engineers face on a daily basis. You might say that Fantom is deliberately designed to be a boring language.

This basic philosophy is exemplified by what is bundled into Fantom by default:

• module system
• build script framework
• unit testing
• documentation tools
• basic web framework and web server
• desktop UI framework
• support for common formats: xml, json, csv

Its probably safe to say that most applications today are web applications. Consider the complexity of putting together a basic development and deployment environment for a web application in Java. In Fantom we strive to make these fundamentals a tight, seamless part of the core platform. And we eat our own dog food - we ship our SkyFoundry analytics application as a 7MB zip file with no dependencies other than the JVM (and over half of that is the SWT jars).

But just because Fantom is designed to steer clear of concepts which haven't been proven out in existing mainstream languages, I think we have actually broken some new ground:

OO Immutability

I believe Fantom has done some really great work to make immutability a fundamental aspect of its OO type system. In all mainstream languages today, immutability is something the developer has to enforce himself. In Fantom, immutability is strictly enforced by the type system at compile time, with extra enforcement occurring in the runtime.

We've taken a pragmatic approach to allow mutable data structures to be used where performance and convenience matter. But we strictly enforce immutability when sharing data between threads.

The only JVM language I am aware of that supports built-in immutability is Clojure. Clojure has has a really cool design for immutability and concurrency, but Clojure isn't an OO language (that's a feature :-). Designing a language which cleanly combines OO and immutability has been a process which has taken a long time to get right. Consider all the details the community has hashed out to truly ensure that once an const class instance is constructed it is truly immutable:

• const classes
• const fields
• it-blocks to allow configuration of objects without annoyingly huge list of constructor parameters
• using functions such as Field.makeSetFunc to allow reflection code to construct immutable objects through an it-block constructor
• special handling in serialization to handle const classes
• auto-coersion of mutable collections into immutable versions
• compiler and runtime checks for allowing both mutable and immutable closure functions

Where ever you might sit on the debate of OO versus functional programming, there seems to be a pretty good consensus that immutable data structures should be preferred when possible. This is even a good practice followed in the Java world. If you like writing and working with immutable data structures, you will love how immutability is deeply baked in the Fantom language and libraries.

Static/Dynamic Hybrid

I believe Fantom is unique in its hybrid approach to static and dynamic typing. Fantom is generally a statically typed language with the same performance as Java. However Fantom embraces dynamic typing through a range of features all designed to work seamlessly together. The most important aspect of our hybrid model is two different method call operators. The . dot operator is statically type checked at compile time and the runtime dispatches as a normal Java method call. But Fantom also has the -> dynamic invoke operator which skips compile time checking and dispatches at runtime using reflection. Other features such as auto-casting are designed to let you write code seamlessly using both static and dynamic paradigms.

This hybrid design gives you the best of both worlds. In general Fantom performs as well as Java code and provides mostly the same sorts of compile time error checking as other static languages. But when you need to escape the confines of static typing then dynamic programming is all there too. Dynamic programming is really great for working with untyped data (like sql) or coding up your tests.

Text Serialization

Most mainstream languages support serialization. What is novel about Fantom is that it supports a human readable/writable text format like JSON, but with the OO typing like Java's serialization. Its been interesting to watch the movement from XML to JSON. I believe JSON is a much simpler and better format for data structures (as opposed to XML's focus on documents). When we pass data structures around it is really useful to know that a scalar is a boolean, integer, float, or string - JSON captures this, where XML doesn't.

Where JSON is a bit weak is that all objects are essentially untyped hash maps. In Fantom we maintain the type of objects so that object trees can be round-tripped (serialized and deserialized) with no loss of fidelity. Consider these two simple examples:

// JSON
{
  title: "Something"
  viewCount: 123
  timestamp: "2010-05-25T11:20:55.506-04:00",
}

// Fantom
acme::Article
{
   title = "Something"
   viewCount = 123
   timestamp = sys::DateTime("2010-05-25T11:20:55.506-04:00 New_York")
}

Both formats are easy to read and easy to parse. But if working in Fantom, then having that extra type information lets us keep all our nice OO typing. Fantom's serialization is particularly useful when working with the FWT since widget trees can be easily read/written as serialized data structures:

// deserialize from string and open a window
"""fwt::Window { content = fwt::Label { text="hi" } }""".in.readObj->open

Since serialization is fully supported in JavaScript too, this lets you pass serialized FWT widget trees as text files over HTTP and have them instantiated in a browser using Fantom's JS support.

Concurrency

Fantom concurrency is based on the Actor model. Actors are hardly novel and they seem to be gaining steam as the preferred model for higher level concurrency (as opposed to manual locking). For those developing software in Java or C# using manual locking, it is hard to overstate how much more productive it is write concurrent code using actors versus toiling over manual locks, code paths, deadlocks, and race conditions. Actors take a bit more thought in your up-front design, but are way more robust at runtime. In the last two years, I haven't had to debug a single race-condition or deadlock in my Fantom code (our SkyFoundry codebase is heavily concurrent).

What makes Fantom's concurrency model unique is how it tightly integrates with other language features such as immutability and serialization. The Fantom type system requires static fields to be immutable, forcing all data sharing between threads to use actor messaging. Actors require that messages are either immutable or serializable. Immutable messages are safely and efficiently transfered between threads. Mutable data is serialized to make a safe snapshot before transferring to another thread. Fantom was designed from the very start to support safe actor based messaging.

Closing Thoughts

There are lots of other interesting aspects to Fantom which separate it from other mainstream languages. But the features discussed above tend to be the ones which really elevate productivity over a language like Java. But in the end, what we hope makes Fantom great is the whole development experience - a complete platform with elegant APIs for software engineering.

we ship our SkyFoundry analytics application as a 7MB zip file with no dependencies other than the JVM

This is one of my favorite aspects of Fantom. You drop it in your system, and it Just Works. Everything has a home (even per-app resources configuration files).

A thought that came to me earlier today was Fantom's spin on the motto "batteries included". I don't know of any other language that came packaged with everything you need to build a robust web application for its initial release. Fantom really feels like more of a platform than a language. All the tedious choices you would normally have to make -- what logging library to use? what web server to use? what widget library to use? what build system to use? -- all of these choices have amazing defaults (and all XML-free, written in pure Fantom!)

I think one of the most novel aspects of the language is how it straddles the boundary of static and dynamic. I think it can just as easily be viewed either as a static language with an escape hatch or a dynamic language with sanity checking. (Though personally, I think it's easier to sell it as dynamic, because of the generic-love out there and because it's friendly like a dynamic language).

Again, great job guys. We're all looking forward to that 1.0 release so we can go spam Reddit ;)

Just chiming in with my congratulations as well. And while I definitely get it in the context of this blog post, I think Fantom is anything but boring - lots to be excited about! I'll be right there with tactics to cheerlead the 1.0 release.

I thought that, when I first looked a Scala (nothing new ;-) but even under the hood you got a few exciting ideas like Unit type being part of the core system.

Even Oracle/Sun and the JCP didn't dare to get that into the language or specs.

As maybe better known to French (former) EG members of JSR-275, against Java Fantom does have potential to become "Fantomas" (http://en.wikipedia.org/wiki/Fantomas)

Crap alex is a spambot... Also found the ad in context hillarious.

LOL, but why does it post about facebook?