What should be my lingua franca of programming?

In a fast paced business environment with fast changing requirements, the tools for expressing and constructing a program become extremely vital for the productivity of the programmer. Given this assumption, the primary of these tools, the choice of programming language becomes extremely essential for productivity. Having worked in C and C++ and having seen a host of different languages I have formed a vague idea of where I am headed next. My attempt is to find out which language should be my lingua-franca of programming.

I am a clear advocate of the horses for courses philosophy, however, it is also important to work with a language that best shapes my thinking. I have here a list of languages I am acquainted with and hopefully a choice emerges and hope that one of these quickly becomes an arrow in my quiver (that I am able to build at least something substantial and useful with it). I had scribbled down the following languages and their pros and cons and hope to master one of them by the end of the year (a 10000 hours later…). Each of these languages have already been used in production and proved their value well already for other companies.

Here is my humble attempt to deconstruct the pros and cons of each language and use one of them before jumping headlong into one.


The grand daddy of all the “Programming in the Large” languages. In spite of its quirky syntax (read non-C typish), it is a revelation to work in a language where there is no mutability. In fact, once I worked in Erlang, it has forever changed my way of thinking about data problems. My typical PHP or Python code is now littered with a lot of small functions returning tuples where earlier I was prone to over-engineer with a lot of classes.

Killer app

  • ejabberd (/mongooseIM) – XMPP
  • CouchDB
  • Riak


  • Immutable programming model
  • Modules + Function overloading
  • Good set of BIFs
  • Interop with C (performance optimization)
  • Robust and scalable with OTP
  • REPL


  • Weird syntax (non Cish) – strict naming conventions (might be a win actually) – Elixir might be a big win here actually!
  • Low real world usage (might be an offshoot from above)
  • Slow
  • Not so great plugins for common usecases (webapps) – mysql


Scalable language or Scala we call is one of those languages which target the JVM directly. And being a hybrid language, it has found good reception among codistas.

Killer app

  • Play
  • Twitter – Finagle
  • Typesafe platform


  • Java interop – so support for Netty is directly available – Batteries included
  • LISP + Object oriented + Functional = multi-paradigm language
  • REPL
  • Touted as the future of Java
  • Compiles to Java bytecode so almost as fast as similar Java code


  • New language
  • Multi-paradigm – philosophy of 1 language – many ideals
  • Mix of immutable (val) and mutable (var) – tries to be too many things to many people


Go is a new language from Google which seems to have a C type syntax as well as the fundamentals of programming in the large systems.

Killer app

  • Docker
  • Google Infrastructure


  • Looks like C – small learning curve
  • Compiled
  • Backed by Google
  • Battle tested
  • Performance close to C
  • Goroutines


  • Not used by a lot of companies – hard to find developers in the market
  • Still very recent and not fully battle tested


Coming with a LISP syntax and a immutability as a core tenet it is a refreshing take of LISP in a JVM. Created by Rich Hickey, its driven very strongly by its creator, the language is quite opinionated.

Killer app

  • Datomic
  • Clojure Script


  • Java interop – Batteries included
  • LISP syntax – almost
  • REPL
  • Touted as the future of Java
  • Rich Hickey’s philosophy
  • Channels


  • New language
  • Lisp Style


My lingua franca now. It is very neatly done language and the fact that it is objects (dicts) all the way through is extremely refreshing.

Killer app

  • Django


  • REPL
  • Good / Fixed syntax
  • Simple modules
  • Batteries included approach – powerful glue, scripting and even a general purpose language
  • pip


  • Lacking multicore support
  • STM
  • Green threads


While not being in the same league as these full-fledged languages, Lua is one of those languages that can quickly turn an extremely well performing C / C++ code and turn it into a powerfully scriptable system without losing any of the performance

Killer app

  • Open Resty
  • Game programming systems


  • C / C++ support
  • Performance / Speed


  • Not a full-fledged language. Any errors bubbles up from the base language directly into Lua


All said, there are a few features I like in a programming language I like working with …

  • REPL
  • Modularization of code without having to resort to using classes. This is where PHP loses out for me.
  • Installable modules. Batteries included approach.
  • Variables naming with hyphen instead of underscores or camelCase. Feels more natural
  • Function naming with question mark. Makes reading and building boolean returning functions ending with a ? a natural read.
  • Garbage collection. I have seen C, C++ and Erlang’s immutability and any language that does not have me worrying about the trivial pursuit of hanging pointers is a big win!
  • Homoiconic systems. It becomes very easy when we start thinking about data and code not as two separate lines of thought (storage, DRY, versioning) but as two varying types of storage semantics only. Where processing (code) and data systems can both crash and need to be restored on demand, it becomes extremely useful when the code itself can be used to express infrastructure, data, configuration and other systems.
  • Clear and convention driven programming style. Telling me that it will work the way it looks (WYSIWYG) is simply a huge win. Quite simply, Erlang excels here for me. So does Go and Python.

My only crib. I wish Elixir was in the Python syntax instead of Ruby (of course taking nothing away from Ruby – its an extremely natural language – just a bit too Englishy and flexible for my taste).

Mental model of languages

“The better decision maker has at his/her disposal repertoires of possible actions; checklists of things to think about before he acts; and he has mechanisms in his mind to evoke these, and bring these to his conscious attention when the situations for decision arise.” 
(Herbert Simon, Nobel Laureate)

C’s mental model is of blocks of memory. C makes you go bare metal – there is a block of memory address blocks underneath!

Python’s underlying mental model is of dicts. Almost everything is a dict or a dict with superpowers!

Erlang’s mental model is of processes. Everything is around handling these processes, monitoring them, how they behave.

LISP’s mental model is of Lists. Everything is a list – function definition, function invocation, data … everything IS A list!

PHP makes you think in terms of HTML output (just kidding).

There is a line I remember – A language that does not fundamentally affect the way you think is not worth learning. Hmmm… time to do some serious work in these languages?

Language vs VM Wars!

Rant follows

Erlang has a weird syntax but again not that far away from being an acquired taste. Python was weird when I started. So was Perl and PHP not so much since. C, C++, Java are all the normal ‘looking’ languages.

These days when I keep coding in Python or PHP, I keep missing the enforced standards of Erlang…

  • first class processes
  • monitoring oriented programming
  • immutable variables
  • first class functions
  • light weight message passing
  • behaviors and OTP

However all of this goes for a toss when I start looking at long term hiring and building a team that can work in Erlang for the long term. And then when I saw Elixir it was neat epiphany. Will there be a time when we will move away from languages and to the Language Virtual Machines.

  • JVM has Java, Groovy, Clojure, Scala and many more
  • BEAM already has Erlang, LFE and Elixir

Now undoubtedly having immutable values gives a huge power to having a pauseless GC and the BEAM is probably better for it. Had the syntax been more “normal” looking, Erlang has many many ideas that definitely need to be heard and learnt by all. It is sad that Erlang does not have the batteries included approach of other languages (I am looking at you Python), but I think where infrastructure and message architecture is involved Erlang is the best bet for now. Except when a class or a struct is involved it is very rare that we try to reuse a variable for more than one purposes. So with some programmer discipline we can ensure that a variable is never used more than once. In that case can the GC of non-Erlang languages be more efficient?

There are so many ifs and buts but it would be nice to see a solid language succeed.