Thoughts on Upcoming Programming Languages

Up­date Simon Mar­low men­tioned this ar­ti­cle in a Google+ post, there was a lively red­dit dis­cus­sion about this ar­ti­cle and this ar­ti­cle was pub­lished on i-programmer.​info. Also, one of the peo­ple work­ing on rust shares my sen­ti­ment on Kotlin.

Haskell’s Weak­nesses

Apart from cod­ing in Java for uni­ver­sity pro­jects and briefly check­ing out the one or other lan­guage I’ve been toy­ing around with Haskell since round about one year. Some of the im­pres­sions I had on Haskell can be found in my pre­vi­ous post Ex­pe­ri­ence Re­port: A Mas­ter­mind Sim­u­la­tion in Lua, Java & Haskell. I’ve had a lot of praise in re­spect to some of Haskell’s virtues but at the same time I ac­knowl­edged its warts. The more I pro­grammed and thought about the things I want to cre­ate the more pre­cise my ideas of what I want from a lan­guage be­came and the big­ger the warts seemed to me.

One of the neg­a­tive things I pointed out pre­vi­ously was the dread­ful record syn­tax. Ac­cess­ing (nested) fields is a night­mare and up­dat­ing them even more. Not even lenses come close to the syn­tac­tic ease of field ma­nip­u­la­tion of con­ven­tional pro­gram­ming lan­guages in my opin­ion. What’s even more tragic: every­body in the Haskell com­mu­nity is aware of this but de­spite end­less dis­cus­sions for years a so­lu­tion is not to be seen on the hori­zon yet.

Lazy eval­u­a­tion by de­fault has bit­ten my arse in every sin­gle pro­ject thus far - and there weren’t all that much pro­jects nor were they par­tic­u­larly com­pli­cated. Some­times I searched eight hours for the source of a space leak. Other times I had to re­ally dig around the in­ter­net to learn how to force a com­pu­ta­tion so that I could mea­sure the time of said com­pu­ta­tion. Each time I in­creased my “de­feat­ing lazi­ness skills” but for the next “lazy” chal­lenge my skills weren’t good enough and I had to play the role of a de­tec­tive again which in fact wasn’t as fun as it sounds what­so­ever. And even though I ac­knowl­edge that there are beau­ti­ful things / the­o­ret­i­cal ad­van­tages that are al­lowed by lazi­ness, per­son­ally, I find it to cost more than it helps and I find it telling that even the bright­est Haskell hack­ers have to tackle so much with space leaks. One of Haskell’s cre­ators has ac­tu­ally re­leased slides with the title The next Haskell will be strict. At any rate, I’m not the only per­son that dis­likes lazi­ness by de­fault and there is a lot more that could be said about this topic.

I don’t have the source for the fol­low­ing para­phrased quote but I’ve read it a cou­ple of times in the Haskell mail­ing list:

Haskell makes some easy things harder and some dif­fi­cult things eas­ier

In some sce­nar­ios I wished for the good old for loop in­stead of e.g. a fold which is ar­guably as “low-level” as a for loop or some not-so-clear com­bi­na­tion of some local or in­line func­tion de­f­i­n­i­tions and com­po­si­tions of sev­eral com­bi­na­tors. Now I know you can mimic for and while loops in Haskell but then you are in monadic land and any­how - they are syn­tac­ti­cally and se­man­ti­cally not quite the same. What this point ac­tu­ally boils down to is that I want a lan­guage where im­mutabil­ity as well as mu­ta­bil­ity are treated like first class cit­i­zens. Let’s be hon­est: if you want to do some things that are easy in con­ven­tional, im­per­a­tive or “un­pure” lan­guages pre­pare for a syn­tac­tic and se­man­tic over­head of con­cepts in Haskell. It’s not that it’s too hard to un­der­stand how to do it in Haskell but rather too cum­ber­some in my opin­ion. Here’s a sen­ti­ment that I stum­bled upon on one of the soon-to-be-pre­sented lan­guages (Dis­ci­ple) and that I share fully:

We still think the Monad type class is use­ful, and we sup­port it as well. How­ever, when writ­ing Haskell pro­grams we’ve found that most uses of Monad are for IO, and to man­age the in­ter­nal state of the pro­gram. In Dis­ci­ple, we use ef­fects for state-based func­tions be­cause it’s more con­ve­nient, and re­serve Monad for things that def­i­nitely want a non-stan­dard no­tion of se­quence, like parser com­bi­na­tors. Source.

There are other prob­lems that could be talked about like

  • the over­whelm­ing­ness and con­fu­sion of new con­cepts: con­duits, it­er­a­tors, enu­mer­a­tors etc.
  • pack­age de­pen­dency hell (which I ex­pe­ri­enced fully)
  • stan­dard li­braries could be more con­sis­tent (e.g. only map, not fmap…)

How­ever, I think I made some of my dis­sat­is­fac­tion with Haskell clear and in light of that I hope it is eas­ier to un­der­stand how I judge the later pre­sented lan­guages.

A New Hope

Due to the prob­lems I ob­served about Haskell I fi­nally un­der­stood the ap­peal of lan­guages like OCaml, Scala or F#. Broadly speak­ing, they are sim­i­lar to Haskell in that they em­pha­size func­tional par­a­digms but they are strict, have first class sup­port for mu­ta­bil­ity (apart from im­mutabil­ity) and im­per­a­tive pro­gram­ming par­a­digms. Of course each of them comes with its own bag­gage of new con­cepts and ecosys­tem-wise there are quite a lot of dif­fer­ences. So far I’ve tried to play a bit with Scala again, but.. I can’t re­ally point my fin­ger on it but I can’t like the lan­guage. It’s prob­a­bly be­cause Scala seems to be even quite a bit more com­plex than Haskell and there seem to be so many ways to achieve a task. F# seems to be too .NET cen­tric and OCaml seems to have its share of own prob­lems but that doesn’t mean that I don’t want to check it out some­day.

I think now is a good time to ex­plain that I had a small to medium pro­ject in mind that I wanted to im­ple­ment as el­e­gantly as pos­si­ble. In order to com­pare the dif­fer­ent lan­guages I tried to im­ple­ment it in some of them. I first started with Haskell. Al­ge­braic datatypes, im­mutabil­ity, the help of the type sys­tem, au­to­mat­i­cally de­rived type classes, type classes in gen­eral and some syn­tac­tic virtues of Haskell made the be­gin­ning of the pro­ject re­ally pleasent. How­ever, when it came to state shuf­fling monadic code paired with the un­for­giv­ing record (up­dat­ing) syn­tax I soon felt that the el­e­gance was gone. Next in row was Java. Iron­i­cally, using the “un­sexy” Java lan­guage I al­most fully im­ple­mented my pro­ject which hasn’t been the case for the Haskell ver­sion al­though I re­ally felt that miss­ing sup­port for al­ge­braic datatypes, im­mutabil­ity, null pointer safety, first class func­tions & clo­sures, con­cise­ness and the in­ter­lock­ing of name­spaces, classes & files made a lot of things un­nec­es­sar­ily cum­ber­some and un­clear. For in­stance, I had to man­u­ally pro­vide copy, equals & hash meth­ods, I had to make classes like Pair due to a lack of tu­ples, had to cre­ate classes where a sim­ple clo­sure would have suf­ficed etc. Still, the un­cum­ber­some way of writ­ing down con­trol flow, post-fix ac­cess­ing of meth­ods/fields on a class, great IDE sup­port and first class field ma­nip­u­la­tion sup­port made up for the weak­nesses, that is, just so much that I still had mo­ti­va­tion to al­most fin­ish the pro­ject. I also tried to im­ple­ment it with Scala but I ran into some prob­lems that I could not solve el­e­gantly so I didn’t get very far.

Wouldn’t it be great to com­bine the best parts of lan­guages like Java and lan­guages like Haskell with­out cre­at­ing a lan­guage that is as com­plex as Scala? Wouldn’t it be great if the lan­guage would sup­port com­pi­la­tion to JavaScript and had li­brary sup­port for cre­at­ing stuff in the browser di­rectly from the start? And other sub-wishes: great IDE sup­port, cor­po­rate back­ing, learn­ing ma­te­r­ial, vivid com­mu­nity, data-bind­ing / re­ac­tive pro­gram­ming sup­port.

Well, it turns out there are some in­ter­est­ing new al­ter­na­tive pro­gram­ming lan­guages that make some of the wishes true or at least are able to im­prove some of the afore­men­tioned pain points. Let me just list them and af­ter­wards talk a bit about each:

Idris & Dis­ci­ple are quite close to Haskell. I don’t ac­tu­ally know much about each of them apart from them being syn­tac­ti­cally sim­i­lar to Haskell but strict-by-de­fault. I only read about their fea­tures on their re­spec­tive home­pages.

Idris is a gen­eral pur­pose pure func­tional pro­gram­ming lan­guage with de­pen­dent types. De­pen­dent types allow types to be pred­i­cated on val­ues, mean­ing that some as­pects of a pro­gram’s be­hav­iour can be spec­i­fied pre­cisely in the type. It is com­piled, with eager eval­u­a­tion. Its fea­tures are in­flu­enced by Haskell and ML.

I never used a de­pen­dantly typed lan­guage but what I un­der­stood broadly is that you can en­code more prop­ertiers about your pro­gram sta­t­i­cally in the type sys­tem. The ad­van­tages notwith­stand­ing, this seems to lead to far­reach­ing im­pli­ca­tions re­gard­ing the prac­ti­cal use­ful­ness of a lan­guage with re­spect to gen­eral pur­pose pro­gram­ming. Idris wants to find the sweet spot be­tween prac­ti­cal­ity & power of the type sys­tem. In any case, I mostly listed the lan­guage here as a re­minder for me to check it out some­time.

Dis­ci­ple is a di­alect of Haskell that uses strict eval­u­a­tion as the de­fault and sup­ports de­struc­tive up­date of ar­bi­trary data struc­tures. Dis­ci­ple in­cludes re­gion, ef­fect and clo­sure typ­ing, and this extra in­for­ma­tion pro­vides a han­dle on the op­er­a­tional be­hav­iour of code that isn’t avail­able in other lan­guages. Pro­grams can be writ­ten in ei­ther a pure/func­tional or ef­fect­ful/im­per­a­tive style, and one of our goals is to pro­vide both styles co­her­ently in the same lan­guage.

Dis­ci­ple is not a de­pen­dantly typed pro­gram­ming lan­guage. It is very sim­i­lar to Haskell in that it even claims on its home­page that a lot of al­ready writ­ten Haskell pro­grams would be valid Dis­ci­ple pro­grams al­beit with some minor mod­i­fi­ca­tions here and there. The char­ac­ter­is­ing fea­ture of this lan­guage seems to be an ef­fect sys­tem. With­out un­der­stand­ing what an ef­fect sys­tem is or how this or that is im­ple­mented one can still take a look at the lan­guage overview on Dis­ci­ple’s home­page and learn that seem­ingly the main com­plaints of mine re­gard­ing Haskell above are solved in Dis­ci­ple. I.e. strict eval­u­a­tion by de­fault with op­tional lazy eval­u­a­tion, first class mu­ta­bil­ity sup­port, first class field ma­nip­u­la­tion sup­port. Dis­ci­ple seems to be great at first glance.

Let’s be hon­est for a mo­ment though: There is no cor­po­ra­tion be­hind Dis­ci­ple (nor Idris). This isn’t a prob­lem per se but it means that build­ing an ecosys­tem around a lan­guage (in­clud­ing a user base) will take much longer than the other way round. It even­tu­ally worked out for lan­guages like Python or Ruby but it took them quite a while. So, I’m re­main­ing un­hap­pily skep­ti­cal if at all or when there will be a big enough ecosys­tem so that one can use the lan­guage for all the tasks which can be ac­com­plished with a main­stream lan­guage like Java today. With that in mind let’s take a look at the fol­low­ing cor­po­rate backed pro­gram­ming lan­guages:

Rust is a safe, con­cur­rent, prac­ti­cal, curly-brace, block-struc­tured ex­pres­sion lan­guage. It sup­ports a mix­ture of im­per­a­tive pro­ce­dural, con­cur­rent actor, ob­ject-ori­ented and pure func­tional styles. Rust also sup­ports generic pro­gram­ming and metapro­gram­ming, in both sta­tic and dy­namic styles.

Rust is backed by Mozilla. In some of my pre­vi­ous posts I al­ready men­tioned my ex­cite­ness about Rust. Not long ago Rust v0.1 has been re­leased so I had the chance to play a bit with it. I ac­tu­ally im­ple­mented quite some bit of the afore­men­tioned pro­ject and it was fun. On first glance, Rust felt like the per­fect blend of im­per­a­tive lan­guages like C and func­tional like Haskell or OCaml while still feel­ing re­ally light­weight. I es­pe­cially like the struc­tural records, in­ter­faces (like type classes in Haskell) and the sep­a­ra­tion of name­spaces with­out over­load­ing the .-op­er­a­tor. Rust also has some more or less unique fea­tures re­gard­ing the con­trol of mem­ory lay­out but I did not care much about them al­though I ac­knowl­edge them to be an ad­van­tage.

Un­for­tu­nately, one could feel that it’s a 0.1 re­lease. The tu­to­r­ial for ex­am­ple does not ad­dress the type­s­tate sys­tem. This was in­con­ve­nient as the com­piler com­plained about some type­s­tate stuff and I could not fig­ure out how to solve it. In­ter­est­ingly, there is some dis­cus­sion about chang­ing the type­s­tate sys­tem in a way that it will be friend­lier. In­deed, it seems that a lot of syn­tac­tic and se­man­tic de­ci­sions are still in a state of flux. Plus, there were some us­abil­ity prob­lems like defin­ing re­cur­sive records, up­dat­ing im­mutable records and an in­con­sis­tent stan­dard li­brary. An­other thing I don’t like is that I sus­pect that com­pi­la­tion to JavaScript would never be a se­ri­ous goal for Rust (?) as Mozilla is heav­ily in­vested in JavaScript and sees JavaScript as the script­ing lan­guage and Rust as the lan­guage be­hind the scenes (?). In any case, I’d love to write Rust code that would be com­piled to JavaScript. De­spite the above prob­lems I re­ally liked Rust, I think it has great po­ten­tial and I’d love to give it an­other try in the fu­ture.

Let’s turn our at­ten­tion now to three lan­guages that are closer to Java: Dart, Cey­lon & Kotlin.

Dart is a new class-based pro­gram­ming lan­guage for cre­at­ing struc­tured web ap­pli­ca­tions. De­vel­oped with the goals of sim­plic­ity, ef­fi­ciency, and scal­a­bil­ity, the Dart lan­guage com­bines pow­er­ful new lan­guage fea­tures with fa­mil­iar lan­guage con­structs into a clear, read­able syn­tax.

Dart is backed by Google. When Dart was pre­sented the first time pub­li­cally I must admit that I was a bit un­der­whelmed. I learned to un­der­stand its de­sign con­straints and in light of them, i.e. above all fa­mil­iar­ity, its de­sign makes sense. Still, I feel like Dart is too re­luc­tant in re­gard to the in­tro­duc­tion of some lan­guage fea­tures. There are enough ar­ti­cles that crit­i­cize Dart. Be it be­cause of the op­tional type sys­tem, no null safety or the pri­vacy model. And I agree with some of the crit­i­cisms al­though I can’t help but feel that a lot of the neg­a­tive sen­ti­ments against Dart have no foun­da­tion or arise from sheer ig­no­rance. Nev­er­the­less, even though I miss a lot of fea­tures that e.g. Rust or Kotlin have, gen­er­ally, I like Dart since Dart re­ally fo­cuses on being a vi­able al­ter­na­tive to JavaScript with li­braries al­ready de­signed to work with the Browser, IDE sup­port from day one and the abil­ity to use Dart on the server as well.

Cey­lon is a gen­eral-pur­pose, im­per­a­tive, sta­t­i­cally-typed, block-struc­tured, ob­ject-ori­ented, higher-or­der lan­guage fea­tur­ing a syn­tax sim­i­lar to Java and C#, and a type sys­tem based on the no­tion of prin­ci­pal types.

Cey­lon is backed by Red­Hat. To be frank, I’m just list­ing Cey­lon here for com­plete­ness sake and be­cause it is an­other ex­am­ple of the afore­men­tioned stream of new pro­gram­ming lan­guages. Goal­wise it is quite sim­i­lar to Kotlin al­though broadly there is more focus on im­mutabil­ity. On the whole I find Kotlin bet­ter de­signed and per­son­ally at­tribute Kotlin more po­ten­tial al­though that does not mean that I find Cey­lon bad. Not at all, it’s great but the com­pe­ti­tion is great as well. Maybe I should use the op­por­tu­nity and list some other (JVM) lan­guages which have sim­i­lar goals to Cey­lon & Kotlin but have for one rea­son or an­other not man­aged to be­come a sig­nif­i­cant main­stream Java al­ter­na­tive yet al­though there are niches where some of these lan­guages excel: HaXe, XTend, Gosu, Fan­tom, Groovy, Scala, Clo­jure, …

Kotlin is a co­de­name for a sta­t­i­cally typed pro­gram­ming lan­guage com­piled to JVM byte code and JavaScript.

Kotlin is backed by Jet­Brains. Kotlin has lan­guage fea­tures com­monly found in lan­guages like Haskell or ML like al­ge­braic datatypes & higher-or­der func­tions. On the other hand Kotlin sup­ports lan­guage fea­tures com­monly found in ob­ject ori­ented / im­per­a­tive pro­gram­ming lan­guages. In some way Kotlin blends the two worlds like Rust does with­out be­com­ing as com­plex as Scala and lean­ing a bit more to the im­per­a­tive & ob­ject ori­ented side of things. Kotlin is able to in­ter­op­er­ate with Java which im­plies that Kotlin will have ac­cess to Java li­braries & frame­works. At the same time Kotlin fo­cuses on being able to be used as a JavaScript al­ter­na­tive and there is even work on an LLVM back­end. Like Dart Kotlin should there­fore sup­port using it as a server as well as a client side lan­guage. As if by de­f­i­n­i­tion - since Jet­Brains is be­hind Kotlin - Kotlin will have great IDE sup­port.

Kotlin seems to gen­er­ally make most of my wishes true - of course not with­out some trade-offs. I also tried to im­ple­ment the afore­men­tioned pro­ject in Kotlin and al­though I didn’t come very far sim­ply be­cause most of the fea­tures that would have been great for that pro­ject weren’t im­ple­mented yet I al­ready could see that the even­tual pro­gram would be in the same el­e­gance ball­park as Rust. Con­cern­ing the unim­ple­mented fea­tures: in­deed, there is a lot of stuff not yet im­ple­mented in Kotlin but the sug­ges­tions and ideas are there and they seem very promis­ing. Al­to­gether, I find that Kotlin finds the sweet spot just be­tween being in­no­v­a­tive / brave enough to in­tro­duce new syn­tax & se­man­tics to en­code com­mon pro­gram­ming pat­terns and being fa­mil­iar enough to get going with it quickly. I es­pe­cially like the “zero-over­head null safety” in Kotlin which pro­vides null safety with­out need­ing to use an op­tion type. There are a lot more in­ter­est­ing things to find out about Kotlin (e.g. builder syn­tax) so take a look at their web­site if you’re in­ter­ested.

Con­clu­sion & Com­ments

Again, all these listed lan­guages are not in a pro­duc­tion ready state yet but I’m going to check back in ap­prox­i­mately six months and I hope that by then most of the rough cor­ners will have been pol­ished. I think it ob­vi­ously came across that I like Kotlin & Rust best and so nat­u­rally I hope that these will be extra pol­ished by then. Maybe you won­der why I didn’t men­tion any cur­rent or up­com­ing dy­namic pro­gram­ming lan­guage? Per­son­ally, I came to the con­clu­sion that a type sys­tem helps tremen­dously when cre­at­ing, mod­i­fy­ing & main­tain­ing pro­grams. Any­way, I didn’t think I’d write that much but alas, I did. I hope it was a bit in­for­ma­tive at least. This post is per­sonal opin­ion so please don’t take things I’ve writ­ten here as ab­solute.

Published: 04.03.2012 Last modified: 21.12.2013
Comment? Mail or tweet me.