At the company I recently joined, development for the product I'm now working on is done in a home-grown language with no applicability beyond this product team.
We're going to be advertising for new developers shortly, but I expect that this will take a long time because of the language.
Clearly, there will still be significant opportunities for our new hires to develop transferable skills alongside the specific language and business domain, but what can we do to make the roles more likely to attract candidates with a few languages under their belts already who are both willing to learn and capable of learning a new language quickly?
Some clarification for questions asked in comments and answers:
The product and language have been around for decades and are HUGE both in scale and complexity. Back in the day, the intention was for a whole suite of products to be developed in this language but for reasons lost in the mists of ancient history this never happened. Conversion to a mainstream language would probably be a five year project and new features must be developed in the mean time, so we need developers willing to learn the language.
It's not based on any other language I know of. It's a highly efficient way to express business logic for our particular domain. It's supported by an in-house tools team and we have people with decades of experience on both sides of the tools/apps divide.
Several people asked about transferable skills. To my mind, the language you use for software development, its syntax and grammatical quirks, are only one part of your job. Problem-solving, analysis, estimation, team-working, architecture, functional and technical design, peer-reviewing, refactoring, source code management discipline, defect analysis, debugging, self-testing, Agile working practices, resilience and professionalism are all transferable skills or attributes that the successful applicants will develop during their time in post. It's also my view that learning a second language makes learning languages three and beyond easier.
What attracted me to my role (I've not been a developer for some time) was the chance to help a product team get better at Agile and develop my own Agile expertise at the same time - very different set of issues and enticements from the developer recruitment question.