The Next Big Language

Note from 2014: The title is too sen­sa­tional, the ar­ti­cle’s scope too big, the analy­ses too shal­low. It was my first blog ar­ti­cle so I think it can be ex­cused :).

It is al­ready 2010 and one won­ders: What’s going to be the next big lan­guage for this decade? A lot of peo­ple al­ready tried pre­dict­ing it and I admit it gets a lit­tle bit old. Any­ways, this post is my take on it.

I won’t con­sider lan­guages that are mostly used in a par­tic­u­lar niche like Er­lang or PHP - even though they are ubiq­ui­tous in their re­spec­tive niche. In­stead I’m going to focus on gen­eral pur­pose lan­guages. As we all know C, C++, C# and Java are these big main­stream lan­guages of today with “re­cent” ad­di­tions Python, Ruby, Javascript and, es­pe­cially in the Apple world, Ob­jec­tive-C. These lan­guages are here to stay for quite some time. I’d say at least the next 15 years. C might be around even much longer than that.

It is great that pro­duc­tive and fun lan­guages like Python be­came main­stream. But these dy­namic lan­guages have their down­sides, too. Maybe it won’t be speed any­more in the fu­ture (or in other words: the speed dif­fer­ence will be­come ne­g­lec­table for most tasks) with pro­jects like Lu­a­JIT, v8, PyPy or Un­laden Swal­low. Still, the com­pile time cor­rect­ness of sta­tic lan­guages is some­thing that is very con­ve­nient for cer­tain tasks. As such, most of my pre­dic­tions are sta­t­i­cally typed lan­guages.

I want to add that I don’t be­lieve the next big lan­guage is a lan­guage that edges all the oth­ers away! There still will be other main­stream lan­guages even if only for legacy rea­sons and there still will be highly spe­cific niche lan­guages. How­ever, wouldn’t it be great if there was a lan­guage which in­cor­po­rated the flex­i­bil­ity of dy­namic lan­guages with the speed and the cor­rectnes of sta­t­i­cally typed lan­guages and had sup­port for a lot of par­a­digms with­out being a huge mess?

What do I ex­pect from a pro­gram­ming lan­guage?

Be­fore nam­ing the pre­dic­tions I want you to un­der­stand my met­rics. They are or­dered by de­scend­ing pri­or­ity. A good lan­guage should

  • be read­able
  • be un­am­bigu­ous
  • be con­cise
  • be ex­pres­sive with­out heavy­weight syn­tax
  • have one (canon­i­cal) way of doing things
  • be fast

All in all a lan­guage should feel like it helps you for­mal­iz­ing your thoughts in­stead of being a hin­drance. Busy­work code is not im­por­tant. En passent, the Zen of Python is a great guid­ing prin­ci­ple for what a good lan­guage should be like.

And now to the con­tenders:


Clo­jure is a dy­namic pro­gram­ming lan­guage that tar­gets the Java Vir­tual Ma­chine (and the CLR). It is de­signed to be a gen­eral-pur­pose lan­guage, com­bin­ing the ap­proach­a­bil­ity and in­ter­ac­tive de­vel­op­ment of a script­ing lan­guage with an ef­fi­cient and ro­bust in­fra­struc­ture for mul­ti­threaded pro­gram­ming. […] Clo­jure is a di­alect of Lisp, and shares with Lisp the code-as-data phi­los­o­phy and a pow­er­ful macro sys­tem. Clo­jure is pre­dom­i­nantly a func­tional pro­gram­ming lan­guage, and fea­tures a rich set of im­mutable, per­sis­tent data struc­tures. Source

This pretty much sums up Clo­jure but I still want to add some of my im­pres­sions. In my opin­ion the most prac­ti­cally use­ful fea­ture of clo­jure for day to day pro­gram­ming1 are the na­tive col­lec­tion data struc­tures, i.e. lists, vec­tors, maps, sets, that are all con­sis­tently ab­stracted after the idea of a head and a tail. I learnt to love to have such data struc­tures avail­able in a lan­guage while using Python. It makes you far more pro­duc­tive. This blog post comes to the same con­clu­sion.

An­other im­por­tant char­ac­ter­is­tic of Clo­jure is its ori­en­ta­tion to­wards con­cur­rency. It is im­por­tant be­cause our com­put­ers get more and more cores and using them ef­fi­ciently is a prob­lem. As Clo­jure is func­tional2, which makes rea­son­ing about con­cur­rency eas­ier since you don’t have shared state and side ef­fects, and has built in con­cur­rency fea­tures like STM, Agents and Atoms it is a good fit for the “con­cur­rent fu­ture”.

More­over Clo­jure is a Lisp and there­fore sup­ports Macros, a super easy syn­tax and Metapro­gram­ming. Al­though this is all nice and good (and pow­er­ful) and I came to ap­pre­ci­ate Lisps when I learnt Scheme in Uni­ver­sity not every­one likes Lisps - even if only be­cause of the “paran­the­ses”. This will be a stum­bling block for major adop­tion.

An­other dou­ble-sided sword is Clo­jure’s at­tach­ment to the JVM. On the one hand this boot­strapped Clo­jure’s adop­tion3 and gave Clo­jure a va­ri­ety of li­braries to work with. On the other hand these Java li­braries are not writ­ten with Clo­jure’s id­ioms and thus prob­a­bly feel not very fit­ting even though Clo­jure’s Java in­ter­op­er­abil­ity is great. And who knows where Java the plat­form is head­ing in the fu­ture after Or­a­cle’s ac­qui­si­tion of Java? But Clo­jure in Clo­jure may loose the bound be­tween Java and Clo­jure and make Clo­jure more in­de­pen­dant.

Con­clud­ing, I think Clo­jure will get even more mind­share and mo­men­tum than it has al­ready now. It seems to be a well thought out lan­guage that builds on proven grounds (Lisp, func­tional) yet still in­no­vates (struc­tural shar­ing, STM). There are still some show stop­pers, e.g. ed­i­tor/IDE sup­port, but they will van­ish even­tu­ally. Do I think that Clo­jure will be­come “the next big lan­guage”? Frankly, I don’t know be­cause even though Clo­jure is a gen­eral pur­pose lan­guage it is not the best fit for some prob­lems sim­ply be­cause it is dy­nam­i­cal and em­braces im­mutabil­ity.

Sum­ming up


  • great built in con­cur­rency sup­port
  • strong na­tive datatypes
  • func­tional
  • it’s a lisp
  • on the jvm + nat­ural in­ter­op­er­abil­ity with java


  • on the jvm
  • it’s a lisp
  • not that fast
  • not very be­gin­ner friendly




Go is ex­pres­sive, con­cise, clean, and ef­fi­cient. Its con­cur­rency mech­a­nisms make it easy to write pro­grams that get the most out of mul­ti­core and net­worked ma­chines, while its novel type sys­tem en­ables flex­i­ble and mod­u­lar pro­gram con­struc­tion. Go com­piles quickly to ma­chine code yet has the con­ve­nience of garbage col­lec­tion and the power of run-time re­flec­tion. It’s a fast, sta­t­i­cally typed, com­piled lan­guage that feels like a dy­nam­i­cally typed, in­ter­preted lan­guage. Source

You prob­a­bly heard about Go the Google spon­sored, Rob Pike pow­ered suc­ces­sor to C. I cer­tainly like Go’s phi­los­o­phy es­pe­cially the fact that Go wants to com­bine the ease of use and fun of dy­nam­i­cally typed, in­ter­preted lan­guages with the cor­rectnes and speed of sta­t­i­cally typed, com­piled lan­guages. Also, Go aims for min­i­mal­ism. In con­trast to other lan­guages Go has very few key­words4.

I also like the fact that con­cur­rency is built into the lan­guage in the form of CSP. In that re­gard Go is armed for the fu­ture just like Clo­jure. Go’s novel, “tol­er­ant” type sys­tem with it’s ad-hoc in­ter­faces seems to by very con­ve­nient, too.

How­ever I re­ally must say that Go’s syn­tax is some­how ugly. I don’t know why but it seems hard to read. Maybe it is be­cause I haven’t pro­grammed in Go and if I started I would ac­cus­tom to it. But the first im­pres­sion is not good.

Then there are some ques­tion­able de­sign de­ci­sions like no gener­ics, defin­ing the vis­i­bil­ity of a vari­able/func­tion by writ­ing the first char­ac­ter in low­er­case or up­per­case, no enums5 and no ex­cep­tions6.

To con­clude I think that Go has the po­ten­tial to be­come the next big lan­guage but not in its cur­rent form. I like some things and I don’t like oth­ers. I’m not yet sold on Go. But if it im­proves some of its de­sign de­ci­sions (like adding gener­ics) I be­lieve Go’s chances to truly be­come the next big lan­guage would more than dou­ble.

Sum­ming up


  • rel­a­tively small
  • fast com­pi­la­tion
  • ad-hoc in­ter­faces
  • con­cur­rency sup­port baked into the lan­guage
  • un­con­ven­tional


  • un­con­ven­tional
  • ugly syn­tax
  • ques­tion­able de­sign de­ci­sions




D is a sys­tems pro­gram­ming lan­guage. Its focus is on com­bin­ing the power and high per­for­mance of C and C++ with the pro­gram­mer pro­duc­tiv­ity of mod­ern lan­guages like Ruby and Python. Spe­cial at­ten­tion is given to the needs of qual­ity as­sur­ance, doc­u­men­ta­tion, man­age­ment, porta­bil­ity and re­li­a­bil­ity. The D lan­guage is sta­t­i­cally typed and com­piles di­rectly to ma­chine code. It’s mul­ti­par­a­digm, sup­port­ing many pro­gram­ming styles: im­per­a­tive, ob­ject ori­ented, and metapro­gram­ming. It’s a mem­ber of the C syn­tax fam­ily, and its ap­pear­ance is very sim­i­lar to that of C++. Source

You may re­mem­ber this sen­tence from the in­tro­duc­tion of this post.

How­ever, wouldn’t it be great if there was a lan­guage which in­cor­po­rated the flex­i­bil­ity of dy­namic lan­guages with the speed and the cor­rectnes of sta­t­i­cally typed lan­guages and had sup­port for a lot of par­a­digms with­out being a huge mess?

Well, in my hum­ble opin­ion D seems to take a huge step in that di­rec­tion. Al­though Go is going in that di­rec­tion, too, in the sense of com­bin­ing the flex­i­bil­ity and fun of dy­nam­i­cally typed lan­guges with the safety and speed of a sta­t­i­cally typed sys­tem, it seems to me that Go is a bit too sim­ple for its own sake. If you want to read a very in­ter­est­ing thread com­par­ing D to Go on the Go Mail­ing list here you go. But if you want to take the short route this sen­tence pretty much sums up the dif­fer­ent philoso­phies be­hind D and Go:

Go seems to aim for sim­ple as pos­si­ble while being fast, flex­i­ble, and fea­ture­ful enough. D seems to aim for fast, flex­i­ble, and fea­ture­ful as pos­si­ble while being sim­ple enough. Source

I re­ally like the fact that D is fea­ture­ful al­though many other point out that it is a dis­ad­van­tage. It is in­deed a dis­ad­van­tage if a fea­ture in­tro­duces more com­plex­ity than it pro­vides pro­duc­tiv­ity (I’m look­ing at you C++!). Turn­ing the last sen­tence in­side out gives: It is in­deed an ad­van­tage if a fea­ture pro­vides more pro­duc­tiv­ity than it in­tro­duces com­plex­ity (I’m look­ing at you D!). Let’s con­sider Python. Python cer­tainly is not a small lan­guage. Nev­er­the­less it is one of the most pro­duc­tive lan­guages around. See, that’s what I’m talk­ing about. With D you are not bound to one par­a­digm but can choose which par­a­digm to use for which prob­lem. D has built in unit test­ing sup­port which cer­tainly im­proves its adap­tion. To cut a long story short, go to the D Web­site to learn more about D’s fea­tures.

What shines from the out­side is ugly in­side. D has a bad rep­u­ta­tion. I gath­ered some rea­sons from var­i­ous com­plaints on the in­ter­net:

  • com­piler bugs
  • no up-to-date open source com­piler
  • stan­dard li­brary split (Tango, Pho­bos)
  • com­mu­nity feels not in­te­grated in the process of de­vel­op­ing D
  • back­wards in­com­pat­i­ble changeover to D2

So the con­sen­sus is that D the lan­guage is not bad at all but the lan­guage ecosys­tem is bro­ken. But what is a lan­guage worth with­out a vivid ecosys­tem? It’s prob­a­bly nice to look at but you can’t get any­thing done with it.

Sum­ming up I think D as a lan­guage has the most po­ten­tial to be­come the next big lan­guage. Un­for­tu­nately it’s ecosys­tem seems to be bro­ken and un­less it is fixed D has a hard time fight­ing for the throne.

Sum­ming up


  • real suc­ces­sor to C++
  • fea­ture­ful
  • fast com­pi­la­tion
  • multi par­a­digm


  • fea­ture­ful
  • gets a lot of hate
  • bro­ken ecosys­tem (?)
  • not in­no­v­a­tive/un­con­ven­tional enough




Now, these are lan­guages that don’t get a lot of pub­lic­ity and thus won’t take over any­time soon in con­trast to Go, D and Clo­jure. Nev­er­the­less it is in­ter­est­ing to see some more or less un­con­ven­tial LWA7.


I can’t say much8 about Rust other than it is a sta­t­i­cally typed pro­gram­ming lan­guage from Mozilla with a focus on sys­tems pro­gram­ming and some in­ter­est­ing new ideas9. To learn more about Rust have a look at this dis­cus­sion or this blog post.


I was tired when I clicked the link to Clay’s Home­page but the code snip­pets kind of made me awake again be­cause they looked so good and read­able. Clay is a generic pro­gram­ming lan­guage which aims to be a suc­ces­sor to C. Thus, Clay is as fast as C and has the same run­time over­head as C. On the other hand Clay has no garbage col­lec­tor, which is men­tio­nend as an ad­van­tage on the home­page. Yes, it is prob­a­bly (or not?) an ad­van­tage for sys­tems pro­gram­ming but not for gen­eral pur­pose pro­gram­ming. How­ever, I don’t think it would be im­pos­si­ble to make Clay have a garbage col­lec­tor if it ever gained much trac­tion. Here are some links/ar­ti­cles about Clay that get you in­formed.


I stum­bled over a link to OOC on red­dit I think. I didn’t read in­for­ma­tion about OOC thouroughly but from the out­side it looks quite nice. And if noth­ing else OOC has a good look­ing web­site ;).


As far as I un­der­stood BitC is a re­search lan­guage that com­bines low-level C with high level func­tional lan­guages like Haskell or OCAML. Its aim is noble but it seems BitC has a long way to go.


When­ever I read10 some­thing about Fac­tor it is praised and it is par­tic­u­larly pointed out that Fac­tor has an ex­cel­lent in­ter­ac­tive en­vi­ron­ment. As an out­sider Fac­tor looks weird to me but the en­thu­si­ats un­doubt­edly have a rea­son to like Fac­tor so there must be some­thing to it. Maybe some­day I’ll found out.


Lua is a light­weight multi-par­a­digm pro­gram­ming lan­guage de­signed as a script­ing lan­guage with ex­ten­si­ble se­man­tics as a pri­mary goal. […] Lua has a rel­a­tively sim­ple C API com­pared to other script­ing lan­guages. Source

Lua’s focus is to be an em­bed­d­a­ble lan­guage. Nonethe­less it is very pow­er­ful on its own since it is built on se­lected, flex­i­ble fea­tures. The Wikipedia ar­ti­cle about Lua says that its de­sign has been in­flu­enced by Scheme and I think it shows. To learn more about Lua’s de­sign you can have a look at this dis­cus­sion.

Often it is con­sid­ered a prob­lem by skep­tics that Lua does not offer a lot of li­braries like Python does that are very handy for gen­eral pur­pose pro­gram­ming. While it is true that Lua’s stan­dard li­brary is small, since Lua’s focus is to be em­bed­d­a­ble, there is a large repos­i­tory of li­braries at Lu­aForge or Pen­light. Still, de­spite being around for a long time Lua has not taken off as a gen­eral pur­pose pro­gram­ming lan­guage11. There are some opin­ions and dis­cus­sions (or here) as to why this is the case. On the other hand Python, Javascript and Ruby were around a long time, too, until they fi­nally gained trac­tion… Plus, there is Lu­a­jit. It makes Lua al­most as fast as C with con­sid­er­ably less code! If you don’t be­lieve me look at this bench­mark that re­lates code size and ex­e­cu­tion speed of a lan­guage (im­ple­men­ta­tion). Of course Lu­a­jit is ar­chi­tec­ture spe­cific but it’s still im­pres­sive.

In the not so dis­tant fu­ture I’m going to get my hands dirty with Lua. Then I can blog about my ex­pe­ri­ences with Lua and check if my im­pres­sions on Lua will prove to be true.

Who will win?

As you can see all three main con­tender lan­guages are made by prac­ti­tion­ers who saw mis­takes in the ex­is­tent lan­guages and who learned from these mis­takes. These lan­guages are thus made to get work done. Also, they aren’t de­signed with rad­i­cal and untested ideas. Each lan­guage has longer roots than it seems. Clo­jure’s roots are mostly Lisp and Scheme, D’s roots are mostly C++ and dy­namic lan­guages in gen­eral and Go’s roots are mostly C and some other lan­guages based on CSP. Ob­vi­ously their philoso­phies are quite dif­fer­ent be­cause of this.

The un­der­dog lan­guages, es­pe­cially Clay, seem to be very nice but un­for­tu­nately there is a rea­son why they are un­der­dogs and major adop­tion in the fol­low­ing years is un­likely.

As far as I am con­cerned my fin­gers are crossed for D al­though I’d be happy if any of these lan­guages gained trac­tion. It’s just that I found D’s code snip­pets read­able, I like D’s phi­los­o­phy and most im­por­tantly: there is a need for a suc­ces­sor to C++.

In the end it is of course not solely the lan­guage per se which will change the tack. Per­haps even more im­por­tant than the lan­guage de­sign is the lan­guage ecosys­tem, e.g. the li­braries, (com­pany) sup­port, mind share, he­roes etc. In this re­gard Go is ahead by a nose (Rob Pike, Google) but D has its stars (An­drei Alexan­drescu, Wal­ter Bright), too.

And even if none of the con­tenders will “win” - the pro­gram­mer will win in any case be­cause the in­no­va­tion, dis­cus­sion and com­pe­ti­tion that these lan­guages pro­voke im­prove our un­der­stand­ing of pro­gram­ming and may even in­flu­ence ex­ist­ing lan­guages to in­cor­po­rate new fea­tures.

Up­date: Lan­guages from the com­ments

I didn’t ex­pect this amount of feed­back so first of all: Thanks for the rich dis­cus­sion!

As I al­ready men­tio­nend sev­eral times in the dis­cus­sions it is im­pos­si­ble to do jus­tice to every lan­guage. But to do at least a bit more jus­tice to other lan­guages I de­cided to sim­ply list resp. link to lan­guages that were men­tio­nend in the com­ments as a wor­thy con­tender for the next big lan­guage but that were miss­ing in my blog post.

But be­fore doing that I want to adress all the com­ments that go like: “What about Javascript?”. I al­ready count Javascript as a big lan­guage as you can read in the in­tro­duc­tion of this blog post. With pro­jects like nodejs, com­monjs, jquery, the in­creased de­ploy­ment of Javascript en­gines into other soft­ware than browsers like Unity, the amount of work pushed into in­creas­ing Javascript ex­e­cu­tion speed by browser man­u­fac­tur­ers, the hy­poth­e­sis that every­body “knows Javascript”12 and the mere fact that Javascript is the de facto script­ing lan­guage of the web makes Javascript al­ready now a big lan­guage. Be­sides that just have look at the (con­tro­ver­sial) TIOBE Index. Javascript is at place 11 as of now.

As this is out of the way let’s go to the con­tenders from the com­ments (the source for the sum­maries is wikipedia):

F# is a multi-par­a­digm pro­gram­ming lan­guage, tar­get­ing the .NET Frame­work, that en­com­passes func­tional pro­gram­ming as well as im­per­a­tive and ob­ject-ori­ented pro­gram­ming dis­ci­plines.
Scala is a multi-par­a­digm pro­gram­ming lan­guage de­signed to in­te­grate fea­tures of ob­ject-ori­ented pro­gram­ming and func­tional pro­gram­ming.
Haskell is a stan­dard­ized, gen­eral-pur­pose purely func­tional pro­gram­ming lan­guage, with non-strict se­man­tics and strong sta­tic typ­ing.
Fan­tom is a gen­eral pur­pose ob­ject-ori­ented pro­gram­ming lan­guage that runs on the JRE, .NET CLR, and Javascript.
Cobra is an ob­ject-ori­ented pro­gram­ming lan­guage pro­duced by Cobra Lan­guage LLC. Cobra is de­signed by Chuck Es­ter­brook, and runs on the Mi­crosoft .NET and Mono plat­forms. It is strongly in­flu­enced by Python, C#, Eif­fel, Ob­jec­tive-C, and other pro­gram­ming lan­guages. It sup­ports both sta­tic and dy­namic typ­ing. It has first class sup­port for unit tests and con­tracts. It has lambda ex­pres­sions, clo­sures, list com­pre­hen­sions and gen­er­a­tors.

  1. func­tional fea­tures, im­mutabil­ity and na­tive con­cur­rency sup­port are all nice, but they are not needed for every prob­lem whereas data struc­tures are al­ways needed. 

  2. al­though not purely func­tional 

  3. es­pe­cially in cor­po­rate en­vi­ron­ments 

  4. If I re­mem­ber cor­rectly that’s also the case for Clo­jure and Lua and prob­a­bly a bunch of other (lesser known) lan­guages. But Clo­jure and Lua are dy­nam­i­cally typed whereas Go is sta­t­i­cally typed so it is not re­ally a fair com­par­i­son. 

  5. though you can al­most recre­ate them with the help of iota 

  6. though you can use defer/panic 

  7. Lan­guages with at­ti­tude ;) 

  8. there is no of­fi­cial im­ple­men­ta­tion of the lan­guage yet 

  9. for in­stance type­s­tate [PDF

  10. which is not often 

  11. though Lua is wide­spread as a script­ing lan­guage es­pe­cially for games 

  12. It is of course an ex­ag­ger­a­tion but there’s still the rumor that a lot of peo­ple are at least fa­mil­iar with basic Javascript and that there­fore it is eas­ier to find em­ploy­ees. 

Published: 17.10.2010 Last modified: 24.08.2014
Comment? Mail or tweet me.