Re: What the company is missing ...
Professional grade is my term not yours, I meant a tool fit for a professional to use for a front end, in the example you quote.
I've written a few applications as.
1)Front end application implemented as some web interface (ruby/perl are 50/50 % split here)
2)Interface layer implemented as scripting language extensions in the same language as (1)
3)Backend end libraries in C & C++
Quick to develop, easy to enforce constrains in the API layer and access to your favourite scripting language for the glue.
language choices for 1 & 2 have largely been dictated by the client existing software stack.
For me I've not really seen much to choose between the current crop of scripting languages, they all more or less do the job within the contraints I've encountered. Then again perhaps we are thinking of different use cases.
I use ruby as a glue/scripting language, maybe some parsing/pre-processing or tools. But the code is more or less the same code I used to write in C i.e. I still use the self pipe trick and select in ruby ( it doesn't expose the pselect syscall, I can still use pseudo-terminals etc).
Nowdays, I'd only write in C/C++ to talk to hardware or if the code is something other than the usually (throwaway tools/sysadmin helper/fancy web app) that ruby seems to end up being used for.
The quality of people producing ruby code varies but I see ruby and C as complementing each other. I agree that given time to craft the work and a skilled worker, C and C++ and a sprinkling of assembler is all one really needs.
I'm glad I have ruby in my toolbox, I'm intensely grateful that it's not the only tool, I still don't see why it's a toy and not a tool ?