Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

JVM Languages Report extended interview with Fantom creators Brian and Andy Frank

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.

DOWNLOAD THE PDF



RebelLabs: Make a 5 sentence pitch about Fantom :)
Brian: Fantom is an elegant, next generation language with a strong focus on concurrency and portability. Immutability is deeply baked into Fantom’s type system and concurrency is enforced using the actor model. Fantom was designed from the ground up for portability and has production quality implementations for both the Java VM and JavaScript/HLTML5. Fantom takes a pragmatic approach to style with a focus on static typing, but easily allows dynamic programming. It is an object oriented language, but includes first class functions and uses closures for many of the standard APIs.

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.

RebelLabs: How did the idea appeared to support multiple backends (.NET, JavaScript)?
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.

Andy:The JVM platform is pretty mature at this point. Its the JavaScript VMs that I think we’ll see (are seeing) the most exploration on. With all these languages now compiling to JavaScript – browser VMs are seeing a similar pattern as the JVM. So it will be interesting to see how that effects new language design and features – and how developers build and deploy applications over the next few 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?
Brian: I see the two cornerstones of Fantom as being the most important for any next generation language: portability and concurrency. To me, it seems extremely non-productive for most software projects to have one codebase in JavaScript for the front end and an entirely different codebase for the backend (often in Java, C#, Ruby on Rails, PHP, etc). Concurrency in most mainstream languages is completely broken – where memory between threads is shared and programmers have to explicitly remember to lock data structures for concurrency. Languages like Go and Clojure are really interesting in this respect.

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.

DOWNLOAD THE PDF