In the Adventurous Developer’s Guide to JVM Languages report we have covered quite an interesting programming language – Fantom. Fantom provides a lot of interesting features and it was a pleasure to give it a try. We had an opportunity to ask a few questions directly from Brian Frank and Andy Frank, the creators of Fantom and learn more about the language and their prospects on Java landscape.
RebelLabs: Make a 5 sentence pitch about Fantom :)
RebelLabs: How did you come up with the idea of a new programming language for JVM?
Brian: We were looking for a language which had the right mix of features to use for our startup, especially portability and modern support for concurrency. Finding all the existing solutions lacking, we built Fantom as a platform from which we were able to build our commercial software technology.
RebelLabs: What was the programming language that inspired Fantom the most?
Brian: Fantom is inspired by a whole mix of languages including Java, C#, Ruby, Python, Clojure, Eiffel, Self, and Lisp.
Brian: In a previous life, we built a product in Java, but had many issues selling the solution into .NET shops. So we designed Fantom to target both ecosystems. But as we began development of our current product, we started steering Fantom in a new direction with the goal of using one language and codebase for our backend running on the JVM and our front end running in HTML5 browsers. This has been a very successful strategy now for several years.
RebelLabs: Are you excited about the features (lambdas, defender methods) in Java 8?
Brian: Excited might be a stretch :-) Virtually every other modern language has had the basic mechanisms for functional programming for years now. But there are armies of programmers out there just using Java and still unfamiliar with these concepts, so I think it will be good to indoctrinate more developers to the functional style. We don’t see functional programming as a panacea, but it is a very useful tool in the toolbox.
RebelLabs: What are the features you would like to see in Java.next?
RebelLabs: How hard it is to get Java interop working for Fantom? What are the main challenges?
Brian: Fantom already has really good interop. But like all JVM languages which provide features not found in Java (like first class functions), care must be taken for Fantom classes to present a good API to Java-land. But I think the main use case for interop is for Fantom programs to consume Java libraries – and this is a great strength of Fantom as a JVM lang.
RebelLabs: If you had an opportunity to design Fantom from scratch again, what would you do differently?
Brian: There probably isn’t too much I would change actually. Fantom has grown over the years from feedback and usage by lots of very smart people. And I don’t think we’ve ever felt hamstrung to make a major improvement because of an old design decision. If I had to pick one thing I would change, it would be to make Fantom an expression-oriented language instead of a statement-oriented language. I would probably also use a more Java/C# like function syntax instead of the Ruby inspired syntax.
RebelLabs: Some JVM languages seem to have a bit different approach to the “billion dollar mistake” (ie null values). What is the rationale for Fantom to approach this?
Brian: Nullability is deeply baked into the Fantom type system. A type can’t contain null unless marked with the “?” character. So we have tackled this problem head-on. All of our APIs are clearly typed as accepting or returning null. So its a big feature in our static type system. But like all type system features, I see this as just one tool in the toolbox.
RebelLabs: Is there a particular aspect of Fantom you would like to emphasize?
Brian: By far the two most import aspects of Fantom are portability and concurrency. Being able to leverage one codebase for both HTML5 front end and a fast, robust JVM backend is a huge productivity booster. Software is complex enough already, having two separate languages, tools, and codebases for frontend vs backend only adds a new level of complexity to software projects. We leverage the type system to prevent shared mutable memory between threads and use the actor model for concurrency. This has proven to be a godsend in creating robust software – I can’t remember the last time I debugged a race condition or deadlock (always the worse bugs to debug!).
Andy The immutability and concurrency features of Fantom are definitely strengths that stand out.
RebelLabs: Programming language design is about compromises. Is there any feature that you had to drop because it didn’t fit your constraints or because of JVM limitations?
Brian: The JVM has been a great platform for running Fantom. But the JVM was definitely designed for the Java language. There are lots of irritating design decisions in the JVM such as the lack of function pointers or a true invokenonvirtual opcode. But with the latest work on method handles and invokedynamic, I think the JVM is really maturing as a platform for functional and dynamic languages too.
RebelLabs: It looks like that most of the recent JVM languages take advantage of static types. Have statically typed languages win the race?
Brian: I think the proponents of static languages promote type systems as a sort of religious issue. So many programming issues get cast as black or white, when the reality is grey. We have a more pragmatic approach to type systems. They are one tool in the toolbox. They are extremely helpful in documenting APIs and catching bugs for “code in the small”. But when you start to work with ad-hoc data or get into gluing different subsystems together, a static type system is not necessarily the most productive solution – so I feel its really important to have that dynamic escape hatch when its the better solution.
RebelLabs: How do you see the JVM languages landscape in 5 years?
Brian: I don’t think much will change over the next 5 years. I think Java will continue to be the main language used for the JVM. But it is exciting to see so many emerging new options for the JVM.
RebelLabs: In your opinion, how important is the toolset for the programming language (in respect to Fantom)?
Brian: Strong tooling and IDEs are critical for any programming language. I think early adopters tend to be programmers who like Emacs or Vi, where the tools aren’t as important. But tools are absolutely required for adoption by more mainstream programmers.
RebelLabs: Can you suggest any good reading for the wannabe language designers?
Brian: I think a great way to get involved with language design is to start reading code for compilers. I remember years ago, that I particularly liked the compiler for a .NET language called Boo. It inspired a lot of the design for Fantom’s compiler.