IMO it's better to think of programming languages in the same way as frameworks in cases like this: because they are. Frameworks present a tradeoff in many area

IMO it's better to think of programming languages in the same way as frameworks in cases like this: because they are. Frameworks present a tradeoff in many areas, but the big ones tend to be solving issues specific to some domain, and the "framework cost" which is needing to work within the constraints and expectations of the framework. Typically the hard part about learning a new programming language is not learning the syntax, it's learning the semantics and the standard library, something that you will pay some amount of when adopting a framework. Maybe to a lesser degree, but most programming languages tend to have consistent semantics around core things like control flow. If you want my personal opinion, I think you'll spend more time getting cut by the razor sharp edges of `mmap(2)` (or whatever the Windows equivalent is) than picking up Elixir, must less the difficulty in handling edge cases such as extremely high load and network failures. Elixir (or rather, BEAM + OTP) is built specifically with the problems you will face in mind, and it would be naive to not at least take a serious look at it. I'll also add, that while I don't know the specifics of your system, message broker/passing systems tend to have very hard boundaries with serialization in-between, making it easy to build polyglot systems. Edit: also w.r.t. picking up a new language, I'm referring to the cost of a team picking up a new language, not you as an individual :)