Initial thoughts on Fantom

Recently I started playing with Fantom language. So far my reaction is "Wow!". Its a beautiful language with a lot of cool things. I also ran into a few gotchas, but none that falls in the category of "ugly!".


Here are the things I really liked about the language (not necessarily in any order):
  1. Before any technical merits, the first thing I liked is the documentation. Most of the time, when I look for some documentation for a open source project, they notoriously suck. Fantom is the second project whose documentation I really liked and found my way around most of the time. (The first one is SLF4J.)
  2. The language is statically typed, with room for dynamically invoking methods on objects using a mechanism called "trap".
  3. One central theme I observed in the language is being able to reliably create an immutable objects ("const" classes). This simplifies a lot of analysis when it comes to concurrent programming. Also the language supports creating immutable Lists and Maps.
  4. The language has a few forms of literal expressions that the compiler understands and creates objects for you. For e.g. Map, List, Uri and Duration have equivalent literal forms. One of the places where supporting literal forms aces is during serialization. Any object that is serialized is humanly readable (There is provision for overriding this as well!). Likewise you can create objects from string literal forms that can either be read from a file or just constructed by the program on the fly. What that means? One particular case I can think of is ease of creation of test data.
  5. Any field you specify is automatically accessed through getter and setter generated behind the screen. If you want, you can add more checks and behavior to the getters and setters.
  6. For concurrency, the language provides Actors framework. This is one level of abstraction above thread. In short: actors respond to messages and these messages are immutable. In a way, it simplifies the thinking about concurrent programming.
  7. The language supports anonymous function blocks. i.e. functions are objects too! That helps you in having some neat and cool patterns in your code. Like "10.times { ... }" or "aList.each { ... }". That also means the language supports closures.
  8. The language has mixins support. Its a useful concept when you want to assemble behavior on a type.
  9. Java Annotations equivalent is called as facets. You can decorate a field, method or a type with facets. BTW, fields and methods are called as slots in Fantom. I guess that term came from Smalltalk.
  10. You can use any of the Java classes just by adding a "using ..." statement. That gives you enough power and you wouldn't be missing any libraries that you may not find in Fantom.
  11. The code you write runs in JVM, CLR and (almost in) JavaScript. The work to have full support on JavaScript is actively underway.

Okay. Now the gotchas.
  1. You cannot control how many actors you want to be simultaneously active. The language takes care of it for you. Sometimes, you may want to have control on this one.
  2. There is no single queue and multiple consumers paradigm in actors. Either the producer can keep enqueuing the work in the same actor's queue or enqueue work with multiple actors in a round-robin fashion. In a circuitous way, you can implement this.
  3. The way a a collections member field (a List or a Map) is serialized and deserialized, hmm ... still I am not quite clear. I need to read about that section again.

Please understand that these gotchas may not be true, as I am a beginner and may be doing things in a wrong way.

Above everything else, I like the community of Fantom. Those guys are just amazing in terms of responding to my questions and helping to understand the concepts. I hope to write more about my adventures in Fantom-land. Stay tuned.

Comments

Anonymous said…
"Slots" come from things like CLOS and Self; Smalltalk has methods and attributes.

Popular posts from this blog

The mysterious ORA-03111 error

Note on allocationSize parameter of @SequenceGenerator while using JPA

xVM's vboxmanage.exe command