Our Universe is expanding every day — and I mean this in the sense of our “programming universe” (though the other, ad literam interpretation is true as well, since our actual physical Universe is expanding indeed). Every meetup and every website I come across advocates a new framework, a new architecture, a new language, a new tool. It becomes quickly mind-boggling how to keep up with the rate of this expansion.
And as such, in a forever-expanding Universe, the question quickly pops up: do I need to pay attention to framework xyz? Or do I need to invest in language abc? Or do I need to deploy this certain platform / tool / etc? There is, of course, no silver bullet for this answer. But what this prompts a lot of times is an even deeper question: is my language, or framework, or platform holding me back? Do I need to switch? And of course the natural evolution is: do I need to adopt a new framework or a new language? This is a bit I want to touch upon in this blog post.
Through the Endeavor network I get to mentor a lot of entrepreneurs; some want my thoughts on strategy, some on their managerial approaches but since my background is in tech, often, some of the discussions end up being around tech or tech stack. And this is where the above question ends up surfacing quite often.
Advantages of being polyglot
“Right tool for the right job” is a rule that most engineers are familiar with; or in other words, you give someone a hammer and everything starts looking like a nail.
Being polyglot allows you to benefit from multiple tools — to expand on the above. Do you have components in your stack where parallelism and high throughput are the utmost concern? Then it makes sense to embrace the likes of Go, or Scala or Java. Or if your needs are even stricter, perhaps you are in need of a real-time system, maybe go a bit more hardcore with C++.
If however you are more interested in fast prototyping and iteration and you are prepared to sacrificed a bit of the performance in favor of faster iteration, then perhaps Pyton, or Ruby or Javascript is a better choice.
The good thing about taking a polyglot approach is that you can play each language at its strength: you can focus on optimization where it is needed but not be burdened by it when your needs are different.
The downside
The downside of taking this polyglot approach is that this comes with different requirements from an infrastructure as well as skillset point of view. In most cases each language comes with its own requirements or recommendations in terms of deployment — and your infra teams have to be able to support that.
Secondly, as I said, with a polyglot approach you have a poly-skills need also: you will have to hire engineers with different skillsets for each language. There are a lot of great engineers out there who are polyglot but even so you will find it harder to transition engineers in between teams, and each such transition will come with a learning ramp, so that you cannot easily reassign anymore engineers from project A to project B, if the 2 projects use different programming languages.
The other downside is interfacing 2 systems written in 2 different languages: when everything is written in one language is very easy to use library A in project B, or access project C from project D; things become a bit different when being polyglot. This is where standards come in and APIs and SDKs — and often you have to readjust your architecture a bit to make this possible.
For instance, write everything in C++ and you can easily include code and libraries in any of your project and reuse existing code. Add Javascript for instance into the stack and that goes away: now you have to wrap up some of your C++ code into a service of some sort, perhaps provide a REST interface to the outside, so you can finally access that from Javascript. Not a bad thing to after all, but you are paying a cost for being polyglot!
Advantages of poly-framework
Typically, when talking about poly-frameworks, we are talking in the context of the same programming language. As such, one immediate advantage of this is that code reuse is much, much easier to achieve — be it simply include some header file in your new project, or reference a jar produced by another project or include an NPM package into your ES6 code.
Also, since we are talking same language, it makes it much easier to transition engineers from one project to another: suppose your project A needs more engineering muscle and for a few months you need to reassign some of the engineers from project B to it. This becomes a much easier transition because the language, the library, the build tools, the debugging and so on are the same. (Of course there is still a learning curve regarding any frameworks used in A but not used in B as well as the business context, but by and large this will be a much quicker transition than in the polyglot case above.)
Also your infrastructure in most cases will not be faced with different requirements for CI pipelines, deployment and so on, and you can focus more of your engineering efforts into actually building components rather than building infra for them.
The downside
In the case of a poly-framework approach you are banking on a single programming language. This presents the danger of such a language loosing traction with engineers — and this can risk making your product very difficult to maintain, as well as making it increasingly difficult for you to hire technical talent.
Look at PHP for instance: it is still around and there are tons of websites built still on top of WordPress (I’m one of them!) which is still a very viable solution for a blog. However, outside of that and perhaps a few other projects, I haven’t seen that many companies employing this language in a commercial project. Embracing this route will probably see you with a very limited talent pool.
Similarly, Ruby on Rails, has seen a lot of traction in the early days, as it allows for very quick prototyping, but experiences such as Twitter has shown it makes it difficult to scale so nowadays companies think twice before going dow this route. This lead to Ruby still being an awesome scripting language, but Rails perhaps not so much. Building a full solution on Ruby might be problematic.
You are effectively putting all of your eggs in one basket, if that basket falls on the floor you are in a tough spot; to translate this in the case of a single language poly-framework, if the language loses popularity you have a lot of code to migrate to something else.
Conclusion
Right tool for the right job — there is no silver bullet here as I mentioned before. Your choices will vary depending on your needs.
