One of the most important advancements in software development lately has been the shift to asynchronous design patterns within a variety of software languages.
Since we’ve named our fledgling company after this mechanism, it seems appropriate that we explain the importance of choosing the right technology for the job.
Before we focus on the specifics when choosing the appropriate language its important to note that by tolerating poor technology choices early on in a project can cause massive technical debt. It’s an obvious point to make but something we feel very strong about. When that product needs scaling/maintenance/migrating the debt can sometimes feel like a total rewrite is needed (which is never a good idea) !
Put simply, the presence of asynchrony means the program doesn’t get held up (blocked) waiting for requests (to the outside network or disk) to complete. It is generally considered essential in user interfaces (as the whole program or app would appear to freeze), its presence in server side distributed architecture is as you might have guessed fundamental .
What about other languages such as Java and PHP? Effectively, it is much more difficult to implement this design pattern, which leads to slower performance and making the application much more difficult to scale.
This not only has to do with the language you choose, it also directly effects the choice of message queue, database and your choice hosting provider. While many developers might be happy with the easy option of using the message queue they are most used to, the question is will it scale appropriately if under massive load for the use-case at hand. That is why we are seeing a shift towards technologies such as Apache Kafka, database solutions such as Elasticsearch that auto shard and cloud PaaS providers who actually can scale when your product needs it to.
If your product will need to scale then consider your chosen technologies carefully at the beginning of a project. We are sure that you would agree that to incur a metric tonne of technical debt early on in the lifecycle a product is the last thing you need when it comes to maintaining it.