To some people learning a new programming language is an excess best avoided. Why, oh why, they argue, do we need yet another language?
Don’t we have enough already?
Aren’t the existing tools getting the job done?
And then there are those tireless seekers who jump at the opportunity of trying new things and stumbling upon gems. To them, learning is an end in itself, and they don’t need much convincing to burn away their weekends building a console-based card game in that obscure, new language.
No matter which camp you belong to, there is something beyond debate: we all want to spend time on something that will have a bright future.
For the people in the legacy camp, their favorite existing language already has tons of momentum and will continue to have a bright future. To them, I must remind that their now-mature preferred development toolchain was once “kool-aid” that many refused to drink. And so it is today; new technologies are added to solve new problems or to ease the pain of development.
If something does this radically enough, chances are it will continue to snatch mindshare and reach the top. When that happens, you don’t want to be left behind. 🙂
And to those who like to run with the shiny stuff, a warning: having fun is essential as a programmer, but we must be careful not to waste our energies aimlessly.
Sure, Brainfuck is an incredibly twisted, puzzle-like, fun little language, but you’re unlikely to benefit by pursuing it seriously. You want something that is new, sensible and has a solid foundation.
How these languages were selected
Language selection is an intimidating job, especially when new languages are being considered for future benefits in employment and satisfaction. Every language author is firmly convinced they’ve built the perfect language possible and solved all the problems there are to answer. How, then, do you cut?
For this post, I focused on a few parameters to keep my search within reasonable boundaries.
I specifically avoided languages that are very, very new.
New, I mean languages less than 5-6 years old as of writing, and especially those that haven’t reached stability (1.0 release, that is). This, unfortunately, rules out some real gems like Crystal, But I do hope to come back to this and write about its success some day. 🙂
For me, 5-12 years is the sweet spot, which is when a language has stabilized, and more refinements are being worked out. Now, of course, there are exceptions to this rule, and these will be considered where applicable.
Strong Community Interest
This one is a no-brainer, but often gets ignored when we get excited about something new. Now, for many people, the backing of a large company is enough precedent for success, but it’s not always true.
Yes, Apple’s Objective-C and now Swift thrived because these were the only options in a highly controlled ecosystem, but Facebook’s D and Hack (an ugly take on an already ugly language, in my opinion) remain little more than experiments.
The ideal combination would be a language backed by a large, stable company and exploding in popularity (like React).
But the meat of the matter is still the community. If a language is not creating a buzz, and there are not enough devs to educate and popularize, it’s not going to climb out of its GitHub grave.
Focused, well-defined USP
The third thing I’m looking for is a clear-cut goal for the language. For example, a better version of PHP that fixes naming issues and compiles to native PHP doesn’t work for me.
Honestly, I’m bound to dismiss syntax-only improvements immediately. History has shown that usefulness trumps friendliness when it comes to languages, so if all a new languages focus on is a more pleasant experience, I’m afraid it won’t make this list.
Clear, consistent syntax
Yes, I know. I just said that syntax doesn’t matter. Well, to be precise, I said that “syntax-only improvements” don’t matter. But that said, syntax remains one of the significant factors in programmer productivity and maintainability, so it’s something that’s bound to feature in my calculations here.
Along with syntax comes the idea of consistency. Function naming, module structuring, etc., are key things a language can’t afford to get wrong. It’s 2018, for God’s sake, and another PHP-like language design would be a shame for all of us. So, without further ado, let’s get started with our top five recommendations.
To the folks at the MIT, the languages available for data science were a compromise at best. Python, for all its clarity and popularity, lacked native constructs for dealing with data objects. Also, being an interpreted language, Python was slow for them (not the libraries, mind you, as they are mostly written in C).
But perhaps the biggest turn-off was the clunky concurrency model, and the lack of a parallel computing model, the latter of which is a staple in super-computing.
As a result, Julia was born.
Julia reached its stable release on 29 September 2018, barely a few days before this article was written (talk about timing!). Here’s what the official website has to say about its capabilities:
Julia excels at numerical computing. Its syntax is great for math, many numeric datatypes are supported, and parallelism is available out of the box. Julia’s multiple dispatch is a natural fit for defining number and array-like datatypes.
Syntax-wise, Julia can be seen as a combination of Python and C. Yes, it’s probably the first time a language has aimed at both these qualities and succeeded.
To keep matters simple, Julia doesn’t enforce strict typing, and yet is blazing fast. Here are some benchmarks:
As you can see, Julia is slightly worse than C but blows Java and Python out of the water. And what sort of eye-candy does Julia offer?
Well, here’s the implementation of a function for calculating the hypotenuse of a right triangle:
Finally, while most of the Julia ecosystem is heavily tilted towards mathematical work, I do believe it has a bright general-purpose future.
It’s the first language in my knowledge that has first-class support for parallel computing, so it will no surprise to see it gaining more popularity in the Web and IoT domains.
If you’ve tried the new Firefox browser releases, you know that finally, after years of working, it’s looking like they might be able to take away some market share from Chrome.
If the browser feels light and snappy and renders quickly, it’s all thanks to the language Mozilla specially developed: Rust.
To say that Rust has a bright future will be a lie; the language is already a massive success, and if you’ve not heard of it yet, it’s because its area of application is specialized, and its goal scary: replacing C++! Yes, we finally have a language that not only is capable of doing this but is already doing it.
For people frustrated with C++’s over-burdened design and memory management challenges, Rust comes as a breath of fresh air.
Here’s what a Rust program looks like:
Concise and elegant, in my opinion. Rust follows the functional programming approach, which makes your code more composable and there are no object-oriented hierarchies to wrestle with.
So, what gives Rust the courage to go after C++? It’s the new memory model. Rather than relying on the old new()/delete() dance, Rust introduces the idea of Ownership.
Rather than allocating and accessing memory directly, Rust variables “borrow” from each other, with strict restrictions placed by the compiler. The overall concept is too complicated to explain in a few words, so feel free to check out the official docs to learn more.
The point is, this results in 100% memory safety without the need of a garbage collector, which is a big deal.
Rust has taken the system programming world by a storm. It’s already supported on some platforms, powers browsers and rendering engines are quickly replacing C/C++ code on production systems, and is being used to write operating systems.
Sure, it’s not everyone’s cup of tea to create another browser or device driver, but Rust is already spreading itself to other domains. We already have several fully functional, ridiculously fast Web frameworks in Rust, and more and more application libraries are being developed.
Honestly, if you’re interested in an exciting future, Rust is the perfect language and now is a perfect time. Rust is a plane that has taken off, but there’s still time to get on board as it heads for the stars!
Learn Rust from Dmitri Nesteruk.
Among languages that focus on developer happiness, the first place has been permanently reserved for Ruby. It’s a language that reads like poetry and has enough shortcuts to reduce mental friction by order of magnitude.
No wonder, then, that the Rails framework continues to dominate full stack development for serious developers and startups. But not everyone was happy with Rails, especially one of its core developers – José Valim. I think the creator himself best explains the genesis of this language in an interview:
It is a long story, but I will try to make it short and sweet. Back in 2010, I was working on improving Rails performance when working with multi-core systems, as our machines and production systems are shipping with more and more cores. However, the whole experience was quite frustrating as Ruby does not provide the proper tool for solving concurrency problems. That’s when I started to look at other technologies and I eventually fell in love with the Erlang Virtual Machine.
I started using Erlang more and more and, with experience, I noticed that I was missing some constructs available in many other languages, including functional ones. That’s when I decided to create Elixir, as an attempt to bring different constructs and excellent tooling on top of the Erlang VM.
And behold, Elixir was born!
Just like Scala improves upon the Java language but targets the same virtual machine underneath (the JVM), Elixir too takes advantage of the decades-old, battle-proven Erlang virtual machine.
Now, a discussion on Erlang is beyond the scope of this article, but the minimum you should know is that it’s the telecom industry’s best-kept secret: if our phone networks are much more reliable than our Web-based systems, it’s all thanks to Erlang.
In even simpler terms, what it means is this. If you’re building a real-time system like chat, Elixir is much, much less RAM hungry and stable than Ruby (or PHP, Python, and Java, for that matter).
A machine that runs Ruby and maxes out at, say, 10,000 concurrent connections, can easily handle 200,000 when using Elixir and still have enough RAM to run 2D games!
Syntax-wise, Elixir shamelessly copies Ruby, and its dominant Web framework, Phoenix, shamelessly copies Rails. I’d say that’s a good thing, too, because along with Laravel, Grails, Masonite, etc., we are reaching a point where all languages have Rails-like frameworks which can ease the transition. Some might scoff at the “lack of originality,” but least I’m not complaining.
Finally, Elixir is one of those technologies that are refreshing, pleasant, and damned practical. Several Ruby (and even non-Ruby) shops are moving to Elixir, and big companies like Pinterest are using it in production with extremely satisfying results.
Many people think that Node.js was a makeshift attempt at concurrency and would soon be replaced by Elixir. I have to say I agree with them. 🙂
In 2017 I/O, Google unleashed a bomb upon the unsuspecting crowd. The company formally announced Kotlin as the primary language for Android development, sending shock waves through the industry.
Now, that Google has been actively looking to replace Java comes as no surprise after being bitten by an Oracle lawsuit; however, the adoption of Kotlin was somewhat unexpected, and there’s still a good chance Google will come out with its virtual machine soon. For the time being, though, Kotlin is enjoying a surge.
Kotlin was developed by JetBrains, a company better known for its suite of insanely good code editors. One of them, IntelliJ IDEA, forms the bedrock of the Android Studio. The design goals of Kotlin are safety, conciseness and 100% interoperability with Java.
More than anything else, the Kotlin compiler works extra hard to eliminate any null-pointer exceptions that are so common in the Java world. It also takes down the proverbial Java verbosity quite a bit, which will come as a relief to many.
Here’s a wonderful code comparison between Java and Kotlin:
The Kotlin code is significantly shorter and much less cognitive overload to plow through.
But let’s get one thing clear: Kotlin is extremely unlikely to replace Java, though it is rapidly becoming a quick favorite. I believe that ten years down the road, small- to medium-sized teams will look no further than Kotlin, while large groups will continue using Java purely because of legacy reasons.
That said, Kotlin has an extremely bright future as it does everything that Java does, can merge with Java code without anyone noticing, and is much more pleasant!
God knows I had to restrain myself for this spot! Everything inside me was screaming “Elm! Elm!”, but no matter how revolutionary its ideas are, or how divine the syntax, Elm is yet to be seen as a mainstream alternative for front-end work. 🙁 Anyway, let’s move on to what is mainstream: TypeScript.
There are excellent chances that you’ve heard of TypeScript: Angular was the first framework to embrace it from version 2 onward, and people were quick to take note. That’s because TypeScript adds some much-needed and some fantastic superpowers to the most famous programming language in the world.
Here are the enhancements that TypeScript brings to the table:
✓ Strong typing: Finally, a string is not a number, and a number is not an object, which is not an empty array!
✓ Classes and Modules: Yes, classes are standard in ES6, but they’re included in TypeScript as well, besides a neat module system.
✓ Type inference: For complex types, the type can be figured out easily by the compiler, saving you some headache.
✓ Async/await: The async/await keywords and patterns are fundamental, so no more messing around with Promises and Callbacks!
Namespaces, generics, tuples . . . I could go on and on, but it should be sufficient to say that TypeScript converts one of the worst development experiences into one of the best.
The impact of TypeScript cannot be denied. It pushed similar attempts like Google’s Dart out of the field (though it’s attempting a comeback through Flutter, a mobile development framework), and opened the eyes of JS developers to the benefits of stronger types.
You might be surprised to know that the creator of Node.js, after publicly regretting his creation, is working on a new runtime (there’s no official website at this time; just the GitHub repo) that has TypeScript as its primary language.
Conclusion and disclaimer
Specific languages are gaining as much popularity as the ones in this article, but have not been included in the list for various reasons. Here’s a quick look:
- Golang: Already established as mainstream, if not very popular, language. I do believe at this point Golang has several competitors that will keep its market share low.
- R: R is already hot among data scientists, and it’s unlikely to attract application developers much. Besides, we must not forget that machine learning libraries are slowly making their way into all major languages (for God’s sake, even PHP has them now!), so all you need to do is wait for some time. 🙂
- Swift: Apple has an iron grip on their ecosystem, and Swift is the only language available there. No doubt, earlier Objective C was the rage, as is Swift now. I consider it is cheating and so refuse to include it here. 😀
The future is always uncertain, and one way to go about your career is to stick to what’s already working and refuse to get “distracted.” If you do that, Java, PHP, Python, Ruby, etc., are all excellent languages to stick with. However, for some of us, the norm isn’t enough. They want to go out and explore and bet big on the future. If you fall in the latter camp, one of these five languages should be on the top of your to-do list.
Finally, when trying to assess a language, don’t let the effort included overwhelm you, because it’s not that much. If you already know a couple of programming languages, you can learn any of these within two months max, by spending 5-6 hours a week. Whereas the happiness and monetary returns that can be generated in the future will be several times more.
Did I miss some critical language here? Or maybe I’ve got something wrong about the languages listed here? If so, please, please leave a comment and help me improve. 🙂