I think when a new language like Kotlin is announced, every one's first thought is how is this different than X. In our case how is it different from Fantom?

I continue to be amazed by the proliferation of JVM languages. Part of me thinks this is a great thing. But at the same time, there seems to be a ton of work going into creating new things that don't seem have to meaningful differentiation. That said, I believe there is probably some very big philosophical differences between Fantom and Kotlin. I would say Kotlin is more akin to Groovy++, Gosu, or Java 1.8 with closures.

A language is as much what you leave out as what you put in. But syntax sugar tricks don't define a language because you can always add stuff like that without changing the basic semantics of the language. What really characterizes a language is the basic approach to fundamental issues like the type system, OO vs function paradigm, immutability, concurrency, standard library, modularity, composability, etc.

So here are some of my thoughts about what I think are major differences between Fantom and Kotlin:

Maturity

Fantom has been used in production for years and is available right now to use in projects. Kotlin isn't actually released, so until then we can't really evaluate its maturity. The problem with programming languages is that if you want to try out anything novel, you have to use the language extensively to see what works and what doesn't work. Fantom has been going through this process for years to become a pretty rock solid language and platform.

Type System

Kotlin seems to be following in the same basic philosophical path of Java, Scala, and most all other statically typed languages: the job of a static type system is to always prove that something is type safe at compile time. I believe Fantom is unique in our approach of type systems: we allow things which might work to be caught at runtime versus compile time. This is a pragmatic trade-off which years of use seems to validate: you can use a weaker but much simpler type system and still catch most errors at compile time. Fantom proves that there can be a sweet spot between static and dynamic type systems.

Immutability

From what I can tell it does not appear that Kotlin has immutable types which is of course a huge feature in Fantom. Perhaps Fantom's greatest design challenge over the years was figuring out how to combine immutability with an OO type system. The ability to enforce immutability at compile time is perhaps one of the greatest features of Fantom, and I wouldn't trade it for any other type system feature.

Concurrency

Kotlin seems to have no new or novel approach to concurrency. Clojure seems to be the only other language besides than Fantom which is directly tackling this problem as part of the language itself. Detour for Scala enthusiasts: Scala has the same shared mutable memory model as Java which is means you use locks or a library (it just so happens the built-in Scala libraries are really awesome :-) In Fantom the entire language, type system, and concurrency library is built around the notion of immutable types and making it virtually impossible to share mutable state between threads.

Modularity

I am curious to learn more about Kotlin modularity. It appears that they will have it built in, but that maybe it will be extensions to Maven? If so it might be the first JVM language other than Fantom to really embrace modularity. I continue to be amazed that modularity is an afterthought in software platforms. It is criminal that Java is only considering built-in modularity for 1.8 (almost two decades after Java was first created). Obviously this issue can be tackled by libraries like OSGi, Maven, etc - but its never the same as building your whole language from the ground up around modularity. In Fantom of course the idea of pods as the basic unit of modularity, dependency, reflection, etc is critical to the whole platform.

JavaScript and HTML5

Obviously another huge feature of Fantom is its ability to compile into JavaScript. And this is coupled with a fairly mature graphics and widget toolkit. My opinion is that Fantom is unrivaled in having an elegant API for building complex user interfaces for either the desktop or the browser. The web browser UX which Andy has built for SkySpark using Fantom is insanely awesome.

Language vs Platform

Always worth repeating my basic philosophy here: Fantom is designed as a platform onto itself which happens to use the JVM (IMO the best virtual machine). Fantom was not designed as a language for the Java platform. We have pretty great Java interop, but you can't rethink fundamental design issues if your primary goal is perfect Java interop. I think this is where Fantom diverges most sharply from other JVM languages which wish to use the standard Java libararies, but only replace the language. I believe in some respects this has been Fantom's challenge because it is really a new platform versus a drop-in replacement language. But Fantom's cathedral (vs bazaar) approach is what makes features like JavaScript support possible.

People seem to get caught up in language features and expressiveness of problems "in the small". But when it comes to productivity and building large scale software systems, platform architecture and its libraries have a much greater impact on productivity. The Java culture has generated a vast ecosystem of libraries - it is pretty awesome. But most of those libraries include APIs with ludicrously large surface areas which are difficult to learn, understand and maintain. The Java culture seems to place very little value on small, simple, and elegant. Even a small Java project requires pulling in dozens of large libraries just to fill all the gaping holes in the Java standard library. Consider all the things built into Fantom which most all other alternatives require using some add-on library: date/time API, historical timezone database, unit database, logging, feature rich I/O APIs, test framework, build engine, modularity, human readable/editable serialization, desktop/JavaScript UI framework, web framework (low level), web server, JSON, CSV, package management (soon), fandoc, etc. If we exclude the SWT jars, all of that crunchy goodness is bundled into a core runtime of only 3.1MB!

Future

Clearly there will be much competition for developer mind share in the years to come. I think there will be lots of niche opportunities and that Java will likely always have the lion share of that mind share. What really matters for languages like Fantom is to achieve a community of critical mass. Whether Scala or Clojure become mainstream or not, those language have achieved what I would consider well deserved critical mass. Fantom needs to increase its mind share and grow our own community who is out promoting the platform and building solutions.

Nice summary, Brian.

To be more specific, a major difference between Fantom and Kotlin is that Kotlin supports not just user defined generics, but reified ones. That's a pretty big innovation right there. Whether it's the right choice remains to be seen (I think erasure has a lot of good arguments going for it, and reified generics come with significant drawbacks while solving very few real world situations that I'm aware of).

There's also the fact that Kotlin should obviously have top notch IDE support (or at least, IDEA support, I'm hopeful for Eclipse as well).

The best way for you to take away one of Kotlin's main selling points would be to start working right now on a killer Fantom Eclipse plug-in :-)

Last time I used it (been a few months), tcolar's FantomIDE was solid...although with only one developer working on it in his spare time, it's not exactly going to be rocketing along in the new features department. :)

Fantom is on my watch list and visit the forum for updates almost daily. I loved it as soon as I saw it months ago yet could not jump in due to the lack of support in IDEA. IDEA has awesome support for Java, Groovy and JavaScript. I just cannot have two IDE's running side by side so I concluded I'd wait on Fantom. Type navigation, refactoring and quick API lookup are aids hard to put aside.

I so wish all IDE's had some sort of common plugin infrastructure ... unfortunately 3 plugins for NB, Eclipse and IntelliJ are pretty much three different projects and 3 completely different platforms to learn which is very time consuming.

date/time API, historical timezone database, unit database, logging, feature rich I/O APIs, test framework

IMO, Fantom have too many no-core APIs in sys pod. It's a little heavy to evolve.

>I believe Fantom is unique in our approach of type systems: we allow things which >might work to be caught at runtime versus compile time.

Objective-C also follows this philosophy. I agree that the felxibility is nice.