This year, however, I am not in the mood of doing it. There are several reasons why. The first one is that this year there have not been a lot of movement on the new programming languages. I am sure there are a lot, but no one got enough attention to make into a list. Therefore, I am concerned that I will just starting to repeat myself talking about the same stuff.
Yes, things happened, but not so much thing to make a full post worth. Clojure got finally a new release (but it may be late). Elixir continue to have new great releases. Nim is still the eternal “new awesome thing” that struggles to explode in the wild. Rust is no more “new and promising”, it got significantly better than last year and it will be much better in the new one.
Second, and most important, these year I did not look a lot in new directions. I think the goal of our new year should be to stop looking for new languages and get better on the one you already know. This does not mean that you should not learn anything new, on the contrary, there are tons of new concepts that you may not know that you can try to incorporate into your already favorite language.
Maybe you don’t know, but many of your favorite major languages such as C++, Java, C#, Python and even PHP, have introduced several optimizations and new features. I am not talking about “just syntactic sugar”, but real step forward brewed in the exciting cauldron of experimental and/or functional languages.
So, in conclusion, the most promising programming languages of 2018 are the one you already know.
…But… because you want to learn something new and I don’t want to leave you completely click-baited, I will leave here one of the “new” concept that are permeating “old” languages that you should definitely check out.
I swear to the Gods. No one in 2018 should feel the pain of handling
nil, and company. Modern language should not have
nulls as a “jolly value that inhabits every type”. And if they have, they should automatically handle them, or at least make them easy and straightforward to manage. Can you imagine how disappointing would be for a new designed language to constantly check for nulls? (cough… cough… Go…)
There are several reasons why nullable types (especially implicit ones) are wrong. They are exception to types system, and so they can be passed everywhere, and so you need to check everywhere. I will not go over them. There are already tons of resources for this. The bottomline is that null should be a last resort kind of thing, not the default state of our type semantic.
Fortunately, this concept is now well understood. Even Java and C++, the capitals of Null-Country, have introduced solutions to the billion dollars mistake. C++’s
std::optional and Java’s
Optional<T> are beautiful examples of one of the ways to solve this problem. They are technically monads (oououuh! Scary mooooonads), but you don’t have to know that! Just use them.
An optional type is a structured value that can be something or be null. The first advantage is that it is explicit. A
String is not an
Optional<String>. Therefore, you cannot pass by mistake something that “may not be a
String” to something that want a
String. Second, an
Optional<String> is not an
Optional<Int>, and therefore even the
null parts of the
Optional objects cannot be mixed and matched. Third,
Optional are explicit type-encoded nullable types and therefore you can summon the power of monads to do the only really interesting thing we them for in programming: chain “things containing things” to work with them as if we were working with their content. In other words, you can chain together
Optional<X> to work on
X in a transparent way. You don’t have to check that are not null at every single step.
This may appear confusing, useless and blah. But, trust me, try it. This is huge and one of the most important thing I ever grasp on programming.