How many languages do you speak?
By: Meytal Segal, Tech Lead @ZOOZ
We all try to learn new languages. When we visit different countries with different languages, we try to learn some words in their local language. We try to communicate with the locals. Sometimes it’s part of the experience and a challenge when the locals know only one language, their own. So we adapt and learn their language for the success of our trip.
What about programming languages? How many of those do you know? Have you tried learning more than one? Are there any cases when one language is preferred over another? Or is it more important to be an expert in one programming language, to maintain technological consistency within the company or to fit the technology to the scenario?
Choosing your language
At ZOOZ we built our system on a microservices architecture. So it doesn’t really matter in which language the service is written, the communication is done via API calls. This means each service can be coded in a different language.
Our legacy system is a huge monolith written in Java. When architecting our newly built microservices system, we decided to evaluate a switch to a different language. We wanted our services to have small footprints, easy to bootstrap and maintain, with a short learning curve and a large active community.
So we started on a quest to find the best language for our needs.
The first “test-run” services were written in Scala, go and node.js. That allowed us to experiment and learn the basics of each language — while evaluating which languages best meet our aforementioned criteria.
With time, Javascript and node.js became our preferred technologies to write microservices. We started to write inner shared packages and had our own internal npm repository. Node.js is light and has a large community, so it is easier and faster to develop new features. As for Scala, it is very similar to Java and has its own complexities, so our usage of it is limited.
However, despite this current preference, when a new service comes along we also consider the coding language we want to use (this is always part of the design phase).
There is no automatic decision to go the node.js way.
For instance, recently we had to write a new major service which utilizes Kafka. However, we encountered many issues with Kafka-node, the Kafka driver for node.js. One of the issues encountered was the inability to recover after the broker is down — in which case the consumers got stuck and the producers could not write.
We also noticed that the Kafka driver we were using was not maintained and had a lot of open issues. We could not afford ourselves to use a poorly maintained Kafka driver with a lot of open issues for this new critical service.
So why not fix the driver ourselves and hand it back to the community? That’s what node.js is all about! It looked like this package was abandoned a long time ago and had a pretty lost list of open issues. We estimated we didn’t have the capacity and specific expertise to revive it.
We decided to find the best technology for the service.
If we were to look for new node.js packages, why not check other languages as well? After some research and gathering knowledge from within the company, it resulted in two finalists for us to test — Python and Scala.
Both languages have well maintained drivers. Python is considered an easy language to learn. However, it is more complex to support concurrent transactions in Python and we didn’t have much time to invest in research. Additionally, the knowledge we had in the company, led us to believe it is not the best fit for the solution. Also, Scala has two strong web application frameworks “Play” and “Spring”. That required more research in order to choose one of them. So we decided to narrow down the research and focus on Scala. Eventually we chose to implement the service in Scala with “Play”.
We wanted to broaden our knowledge and make the right choice for each service, but the research was limited in time. We had to consider not only he technological needs but also the business needs of the company.
By knowing multiple languages, we can contribute to the open source projects we are using. For example, knowing Java, we were able to contribute to Kafka. We found an issue with the brokers discovery in Kafka, fixed it and submitted a pull request*.
Knowing Go allowed us to contribute to the Vault project by HashiCorp. In the latest version they required using super user, which does not meet our security requirements. After consulting with HashiCorp, we decided to submit a pull request to fix it.
Writing microservices in different languages has some challenges — mostly around maintaining the services or adding new features. Not all of the developers “speak” all the languages. In such cases, the developers need to learn the language before working on a task in an unfamiliar language. This obviously adds complexity to the task, but on the other hand, keeps our developers challenged and helps them grow and gain more skills.
What about modifying existing microservices?
We received a request for a new feature that required us to modify several microservices, written in node.js and typescript. This feature also included UI modifications in React.
Although all the affected microservices technologies were Javascript-based, it still had a learning curve for the engineers working on the feature.
Each language has a different architecture and its own intricacies. It’s like knowing Spanish and being able to understand other latin languages, but not actually being able to speak them fluently.
The team was very excited for the opportunity to learn new languages (typescript and React) and eager to face the challenges that came along with them.
The learning curve
In practice, this meant we had to allocate some learning time at the beginning of each task.
However, for some tasks we did not allocate enough time in the assumption that adding our simple code wouldn’t be too complicated. Reality was different though.
We also assumed that typescript is very similar to Javascript and node.js. We were wrong about that, which led to a delay in our timelines. This experience taught us not to underestimate the cost of moving between different languages.
Each language has its own nuances, and it’s critical to get to know them. When you want to do things right, take the time to learn. Exactly like when you come to a new country with a language that is foreign to you — you don’t want to accidentally swear at the people you meet…
Working in an environment of multiple languages, keeps the developers in a constant learning mode, allowing them to develop new skills. Such environment offers many challenges and opportunities, for better or worse.
Using the best technology for the scenario can help you write better code that will be ideal for your needs. Using a language that is new to you, will have some overhead. That should not stop you from using it, if it is the right thing to do. But don’t forget the learning process to get there effectively.
Visit us at www.zooz.com
