Like an artisan, a developer must know how to use the proper tools. For him it means mastering the chisel, the saw, being able to carve the wood and make something beautiful. For us it means being a polyglot or, at least, being well versed on algorithms and similar and stick with one language. And, well, make things that broke only a small amount of time. For me, the former option is more suited, so I tried to learn a set of languages that could, in my opinion of course, cover the most use case and minimize the efforts I should put to solve possibly difficult problems. So let's list them and see why I did choose them.

Ruby: the first love

Well, they say that the first love is hard to forget, so here I am, with Ruby. Ruby is a language that has no gray area: you love it or you hate it with passion. I write code since I was 13, when with a friend of mine we learned Pascal and after a while we bought a book on VB6 (don't judge me, it was a looong time ago). Mind you, we didn't know anyone with a computer science background or someone who could teach us, but we studied with passion instead of playing with other kids for entire afternoons. Eventually my friend (who's still a dear friend of mine) grow out of this, but my love for computers didn't fade. But the first time I really felt at ease with a language was a long time after my first experiences. In the meantime I wrote a lot of code in a lot of languages, and every language gave me something, but nothing felt "complete" in a sense. And then I found Ruby. The thing that sold me Ruby immediately was it's expressiveness. Writing code was, for the first time for me, just like writing english. I was amazed. I tried other scripting languages before Ruby, like Python, but never had that spark that I had with Ruby. Then I started writing web applications with Rails, and made it a full time job. And here I am, almost 5 years after I wrote my very first line of Ruby code. That feeling became less strong with time, but Ruby remains a language that I suggest to people who ask "What should I learn?", because if you are just starting you don't need to go fast, but write code and be generally happy; that's the only way that programming could grow on you. I still use Ruby and I value it (in fact our core application is written in Ruby), and it's still my go-to language if I want to mockup something fast or if I have to do some light scripting.

C: old, but gold

One of the languages that I learned before learning Ruby was C. C is a mighty beast: the amount of control and power that gives you feels unlimited, but you have to tame it before, or it will bite your ass, hard. What I always loved about C is that it let you do mistakes; this could be seen as an issue, but I thinks thats very important, because it forces you to think before doing. Ages ago (not really so long ago, but it gives the story emphasys) I also worked as a security consultant but I also did CTFs and similar, and most of the issue of C programs where trivial mistakes, like buffer overflows or format string passed as an external parameters and not cleaned. Those mistakes where really easy to make (an <= instead of < for example, or ++i instead of i++ in the wrong context) and to fix, but are often overlooked. I'm always being meticolous (funny story, outside of development I'm really not meticolous at all), and I think that C was the language that shaped me and made me the developer I am today. Just recently I had the opportunity to write again some C, and I find out one thing that I didn't expect: I missed writing C. So I decided to exercise again my C-skills and I finally had the opportunity to write some C code in production and rewrite some old library that I did write years ago. So now C is again in my toolbox, and I think that I will never let it go again.

Rust: the new kid in town

I've been always fascinated by system language, as I implied in the previous paragraph, so when I read on the official site that there was a new language that "[...] runs blazingly fast, prevents segfaults, and guarantees thread safety", I had to try it! I won't lie to you: Rust is as frustrating as it gets. More so that I started before the 1.0 API stabilization. Every day a new API (I'm exagerating again, it wasn't like this but sure it felt like it), and new paradigms. I got fed up pretty quick and gave up trying, promising myself I would give Rust another possibility, but only after 1.0. I kept my promise and I'm glad I did! Rust has given me a lot of satisfaction, even if I had to fight with the borrow checker (it's not that bad, it forces you to write correct code, so it's really useful). I'm playing with Rust anytime I can (at the moment I'm writing a safe wrapper on libpcsclite), and I really think that I will use it in production as soon as I can.

Elixir: On the shoulder of giants

Not so long ago, a smart guy named Jose Valim, long time rubyst and Rails contributor, decided that liked the concept behind Erlang, but not his ergonomy. So he did what every other smart guy would have done in his place: he wrote the language he wanted. He his a rubyst, so he wrote a language that feels familiar with Ruby (it's not Ruby, just as much Phoenix is not Rails; I don't mean it so don't try to read between the lines, you are warned), but with the power of Erlang. And so Elixir was born. Erlang was born to be a robust, functional language, with a lovely framework, the OTP, that make possible writing distributed, fault tolerant and self healing code out-of-the-box. It's not alchemy or black magic, but a set of well crafted ideas that have passed the test of time. It's not an easy task to think like an erlanger (it's the right name?), but once you start breaking down a problem in a subset of smaller problem that could be represented by indipendent process, you are set. Starting with Elixir, you feel like you won't need ever a GenServer or a Supervisor, then you write everything using a GenServer and you are just like holyshithowilivedwithoutthatuntilnow, but at last you find your balance, and learn to use the OTP with cognitio causae, and every small piece of the puzzle starts to fit. Unfortunately is not very good at crunching number, but writing web applications has been a blast with Phoenix. The performances (coming from Rails) are astonishing but it's still very easy to start with. When you start measuring pages rendering in damn µ-seconds, you can stop focusing on making an applications tolerably slow and start to focus on functionality instead. We rewrote our websocket solution from Faye to Phoenix and we are really happy with the predictability of the performances and the resource usage. With Faye we would, from time to time, experience strange issue, when the application stopped responding without really crashing and we won't be able to solve the issue, because, well, Javascript.

Go: Need for speed

For our product we need to print from the browser, and in the design phase we underestimated this issue, thinking it would be a piece of cake, focusing on other problems instead. When the time did come, and we realized how fucked up this problem is, it was too late. Luckily we found an awesome product, jZebra, that satisfied this requirement and so we could focus on the next problem in line. Little did we know at the time that our nightmare just began. That was the time when people started to realize that having a bugged (I would say broken) VM that could access the filesystem inside the browser is not a good idea. And so the browsers started to lock the JVM plugin, and reset the security model at every single update. Whenever there was an update of the browser in the morning we would curse loudly and patiently wait for the tons of phone call from our clients on how to reset the security permissions on Java in the browser. This have been going for a long time when finally I got fed up and decided to eradicate Java from our solution. The only problem was that I had an approximate idea on how to tackle the problem, but no idea on how to do it, because it poses some challenges that where not easy to face. We need the solution to work seamlessly everywhere, we need it to be simple to deploy and we need it to be simple to mantain. At the time I was starting to explore Go, and happened that the day that I got fed up with Java I had my editor opened with Go code and was alone in the office. I said to myself "fuck it, I will rewrite this in Go so I could get rid of this spawn of Satan". And in a single day, with no prior knowledge of Go, I was able to build a working prototype that could print from the browser using javascript and an HTTP endpoint listening on the local machine, communicating with the printer on the 9100 port. I was so happy that I phoned almost immediately to my business partner and I told him only "Just listen" and started a print job. He understood almost instantly what I did from the printing noises and said "You really did it?", to which I replied "of course I did, did you thought that I was joking before?" and we both started an heartfelt laugh of relief. The nightmare was over. We perfected the mockup and got a finished product in a week. And we where never happier to not hear the phone ring.

Javascript: A necessary evil

We mainly write web application, so we have no choice on that: Javascript IS a necessary evil for us. I entertained the idea of introducing Elm for quite a long time, but every time that I think about it, I discard the idea because is not wise at a business level. We already use a lot of languages, and introducing another one could be overwhelming for my collaborators (we are a small shop), who would see yet another language imposed on them. Nobody should be forced to learn something he doesn't want to or he would hate it with passion. I hate Javascript, I simply think that is not a well designed language. ECMAScript 2015 is trying to solve the issue and I really appreciate some features that it introduces, but I don't think I will never be able to really love JS for all the pain it caused me.

Wrap it up

As you can see, every language that I use as of today I've started using it out of a necessity and kept using it because it make sense to me. I use Ruby because sometimes I need to write something fast and at this point it is like a second language to me. I use C because sometimes I need to write something low level and a library in C is a smart choice for speed and easyness of integration. I use Rust because I think that it could be a valid C substitute in some applications, as writing simple microservices that need to run without the risk of becaming a trouble. I use Elixir because sometimes I need to write a web application that run fast and it's easy to write, and should not crash and burn at every request, nor use all the resource on the machine unwisely. I use Go because from time to time I need to write something that should run seamlessly on every platform and be easy to cross compile; the fact that is also fast is a big plus. I use Javascript because I have to.

That said, being a polyglot works for me, but I don't think it's everyone solution to all the problems. I happen to need to work on various level or on various domains, hence the need to be flexible. But, at a young developer, starting to wet it's feet in this ocean of knowledge, I would suggest to choose a language that fit with the domain he is working with and stick with it. Being a polyglot is really taxing, you have to keep up with \(N\) languages at the same time and you cannot let one slip, or you won't be up to speed so easily as you could be using only one or two languages.