When they ask, find out what the real question is

[Peter Alcibiades]

The question is not going to be asked in a vacuum. You have to find out what 
the specific concern is, if there is one.  It may be just an item on a check 
list.  Or it may be related to policy on having control of the application in 
various circumstances, maintainability and so on.  Whatever, you have to find 
out what they really want to know.  

I bet that 90% of the time, when this question is asked, and the answer 'C++' 
is given, that is not the end of the matter either, but that questions about 
maintainability, source archiving, documentation start being asked.

On the open source issue, the customer is being asked to make a bet.  He is 
committing to an application written in a language that is (1) closed source 
(2) a minority language.   It may be a great bet, the risk reward ratio may 
be brilliant, but that is what it is.  There will be some customers who feel 
uneasy about this. They may essentially be asking questions about, what 
happens if you the programmer get hit by a truck tomorrow.  And what happens 
if Rev the company goes bust and the language does not find a buyer to 
maintain it?  What happens if it goes the way of Hypercard?

I suspect if the dialogue gets serious on the topic of the language, these are 
the concerns you have to answer.  But only start in on this when satisified 
that this is the issue, there is no point in suggesting difficulties.

Peter