What exactly do you need in a server-side language these days? Most of the interaction is done on the client, in javascript. Your web service should just be res

What exactly do you need in a server-side language these days? Most of the interaction is done on the client, in javascript. Your web service should just be responsible for handling basic request/response, CRUD operations and delegating to other more specialized systems when the need arises, which can be written in the most appropriate language given the problem domain and tools/libraries available. More often than not what dictates language choice is supporting libraries that you'd rather not rewrite from scratch. How good are they, how long have they been around? etc... For that, its often just easiest to use anything non-blocking to serve as the main handler that communicates to your other services. For me, I use node but there are other choices if you don't like javascript. Most of the time it's not worthwhile to switch to a language just because IBM deems it suitable. I've picked up more than a few freelance gigs where IBM have botched the job and grossly overcharged for something that could be done simply. My clients appreciate my honesty, openness, and simplicity of work. What they really mean when they say "Swift is ready for the enterprise" is that THEY are ready --- they have developed all the sales materials, support orgs, and hired the "correct" developers (in this case Swift ones) to run their gambit on as big of fish as they can.