The Functional View of the New Languages
Written by Eugen Kiss   
Monday, 09 April 2012
Article Index
The Functional View of the New Languages
Corporate-backed languages


Let’s be honest for a moment though: There is no corporation behind Disciple (nor Idris). This isn’t a problem per se but it means that building an ecosystem around a language (including a user base) will take much longer than the other way round. It eventually worked out for languages like Python or Ruby but it took them quite a while. So, I’m remaining unhappily skeptical if at all or when there will be a big enough ecosystem so that one can use the language for all the tasks which can be accomplished with a mainstream language like Java today. With that in mind let’s take a look at the following corporate backed programming languages:

Rust is a safe, concurrent, practical, curly-brace, block-structured expression language. It supports a mixture of imperative procedural, concurrent actor, object-oriented and pure functional styles. Rust also supports generic programming and metaprogramming, in both static and dynamic styles.

Rust is backed by Mozilla. In some of my previous posts I already mentioned my exciteness about Rust. Not long ago Rust v0.1 has been released so I had the chance to play a bit with it. I actually implemented quite a bit of the aforementioned project and it was fun. It felt like the perfect blend of an imperative language like C and a functional one like Haskell or OCaml while still feeling really lightweight. I especially like the structural recordsinterfaces (like type classes in Haskell) and the separation of namespaces without overloading the .-operator. Rust also has some more or less unique features regarding the control of memory layout, even though I did not make much use of them I acknowledge them to be an advantage.

Unfortunately, one could feel that it’s a 0.1 release. The tutorial for example does not address the typestate system. This was inconvenient as the compiler complained about some typestate stuff and I could not figure out how to solve it. Interestingly, there is some discussion about changing the typestate system in a way that it will be friendlier. Indeed, it seems that a lot of syntactic and semantic decisions are still in a state of flux. Plus, there were some usability problems like defining recursive records, updating immutable records and an inconsistent standard library.

Another thing I don’t like is that I suspect that compilation to JavaScript would never be a serious goal for Rust as Mozilla is heavily invested in JavaScript and sees JavaScript as the scripting language and Rust as the language behind the scenes. In any case, I’d love to write Rust code that would be compiled to JavaScript.

Despite the above problems I really liked Rust, I think it has great potential and I’d love to give it another try in the future.

Let’s turn our attention now to three languages that are closer to Java: DartCeylon and Kotlin.

Dart is a new class-based programming language for creating structured web applications. Developed with the goals of simplicity, efficiency, and scalability, the Dart language combines powerful new language features with familiar language constructs into a clear, readable syntax.

Dart is backed by Google. When Dart was presented the first time publicly I must admit that I was a bit underwhelmed. I learned to understand its design constraints, and given some familiarity with it, its design makes sense. Still, I feel Dart is too reluctant with regard to the introduction of some language features. There are already enough articles that criticize Dart,  because of the optional type system, no null safety or the privacy model.  I agree with some of the criticisms although I can’t help but feel that a lot of the negative sentiments against Dart have no foundation or arise from sheer ignorance.

Nevertheless, even though I miss a lot of features that e.g. Rust or Kotlin have, generally, I like Dart since Dart really focuses on being a viable alternative to JavaScript with libraries already designed to work with the Browser, IDE support from day one and the ability to use Dart on the server as well.

Ceylon is a general-purpose, imperative, statically-typed, block-structured, object-oriented, higher-order language featuring a syntax similar to Java and C#, and a type system based on the notion of principal types.

Ceylon is backed by RedHat. To be frank, I’m just listing Ceylon here for completeness sake and because it is another example of the aforementioned stream of new programming languages. Goalwise it is quite similar to Kotlin although broadly there is more focus on immutability. On the whole I find Kotlin better designed think it has more potential, although that does not mean that I find Ceylon bad.

There are other (JVM) languages which have similar goals to Ceylon and Kotlin but have for one reason or another not managed to become a significant mainstream Java alternative yet lthough there are niches where some of these languages excel:  HaXeXTendGosuFantomGroovy,ScalaClojure, …

Kotlin is a codename for a statically typed programming language compiled to JVMbyte code and JavaScript.

Kotlin is backed by JetBrains. Kotlin has language features commonly found in languages like Haskell or ML like algebraic datatypes and higher-order functions. On the other hand Kotlin supports language features commonly found in object-oriented / imperative programming languages. In some way Kotlin blends the two worlds like Rust does without becoming as complex as Scala and leaning a bit more to the imperative and object-oriented side of things.

Kotlin is able to interoperate with Java which implies that Kotlin will have access to Java libraries and frameworks. At the same time Kotlin focuses on being able to be used as a JavaScript alternative and there is even work on an LLVM backend. Like Dart, Kotlin should therefore support using it as a server as well as a client-side language. And since JetBrains is behind Kotlin - Kotlin will have great IDE support.

Kotlin seems to generally make most of my wishes true - of course not without some trade-offs. I also tried to implement the aforementioned project in Kotlin and although I didn’t get very far, simply because most of the features that would have been great for that project weren’t implemented yet, I could already see that the eventual program would be equally elegant as Rust.

There is a lot of stuff not yet implemented in Kotlin but the suggestions and ideas are there and they seem very promising. Altogether, I find that Kotlin finds the sweet spot just between being innovative / brave enough to introduce new syntax and semantics to encode common programming patterns and being familiar enough to get going with it quickly. I especially like the “zero-overhead null safety” in Kotlin which provides null safety without needing to use an option type. There are a lot more interesting things to find out about Kotlin (e.g. builder syntax) so take a look at their website if you’re interested.

Conclusion and comments

Again, all these listed languages are not in a production ready state yet but I’m going to check back in approximately six months and I hope that by then most of the rough corners will have been polished. I think it obviously came across that I like Kotlin and Rust best and so naturally I hope that these will be extra polished by then.

This article first appeared on the website run by Eugen Kiss as a blog and resource centre. Eugen is a Computer Science Student at Leibniz Universität Hannover. He is particularly interested in programming languages, web programming, game programming and software development techniques.

To read more of his posts visit






or email your comment to:


To be informed about new articles on I Programmer, subscribe to the RSS feed, follow us on Google+, Twitter, Linkedin or Facebook or sign up for our weekly newsletter.



Last Updated ( Monday, 09 April 2012 )