I love Ruby - But how bright is Ruby's Future?


#1

I’ve been trying to pickup Ruby for a few months now. I’ve written a few
good programs that help me at work with SAN/Unix Administration. I’ve
also run into a few dificult(for me) programming problems. I like to
figure things out on my own so I never post questions in forums like
this, this probably contributes to my bad programming skill, but that’s
besides the point.

I’m at a point where I’m asking myself if it is worth the trouble for me
to learn Ruby. How many people are really writting Ruby? Are there any
truly robust, good applications being written in Ruby? How well are Ruby
libraries being maintained? I know there is a lot of documentation for
Ruby but I find it hard to find very specific docs. Python seems to have
a whole lot more doc and many more books exist for Python. Does Python
have a greater following. I love Ruby but I don’t want to waist my time
with a laguage that may not have a future.

I don’t really care about learning 10 programming languages. My brain
wouldn’t be able handle it. I want to learn 1 or two languages and learn
them well. I know Pascal very well, I know Perl pretty well, now I
would like to get away from Perl and so I started out leaning Python. I
think Python is ugly and not very fun to write. I then jumped into
Ruby(a whole lot of fun!) but I don’t get the warm and fussies about
Ruby’s lasting power.


#2

On Jun 4, 2006, at 10:09 PM, Hector wrote:

time
Ruby’s lasting power.
Have you seen the press on Ruby On Rails?
Linux Journal
Business Week
Wired
News Week
…and many others

It is certainly a hot topic now.

And, others are talking about Ruby (the Language) now.
Leo Laporte talks about it on his KFI The Tech G. show - says it’s
his favorite language.
Plus it is used in almost every major corporation - whether they know
it or not.

The press hype may die down, but the infrastructure that is being
built (and the fact that people like the language) pretty much secure
Ruby’s existence for some time to come.

Relatively speaking, it is new compared to Python. That is most
likely the reason
that there is less documentation. But, there are about 20 books
poised for
publication on Ruby and Ruby on Rails.

Stay tuned, you have made a good choice.

Jim F.


#3

On 6/4/06, Hector removed_email_address@domain.invalid wrote:

libraries being maintained? I know there is a lot of documentation for
Ruby(a whole lot of fun!) but I don’t get the warm and fussies about
Ruby’s lasting power.

Python probably does have a greater following, but is that the
deciding factor? Java has a bigger following than Python, and I’m
fairly sure that C can beat Java on that. If ‘largest following’ were
everything, we’d all still be listening to ABBA or the Village People
(thank God we aren’t).

Does it matter?

If Ruby helps you with something today, odds are it can help you with
something tomorrow. If there’s never another release, will that
change that fact?

If you like what it does now, use it now. If you like the next
upgrade (if there is one), use that. If not, contintue to use it as
it is.

If you don’t like it does now, well then, why would you care what it
does in the future (for that matter, why would you ask the question)?

In a nutshell (or any shell of your choosing), Ruby is what it is.
You either like it, or you don’t. Let that decide whether you use it
or not.

NOT Posted via http://www.ruby-forum.com/.


#4

On Jun 4, 2006, at 11:09 PM, Hector wrote:

for me

I don’t really care about learning 10 programming languages. My brain
wouldn’t be able handle it. I want to learn 1 or two languages and
learn
them well. I know Pascal very well, I know Perl pretty well, now I
would like to get away from Perl and so I started out leaning
Python. I
think Python is ugly and not very fun to write. I then jumped into
Ruby(a whole lot of fun!) but I don’t get the warm and fussies about
Ruby’s lasting power.

The first thing I’d say here is that Ruby just got the cover of both
Dr. Dobb’s and Linux Journal, which is a pretty big statement of how
far it’s reaching. Can’t say the same for many languages. As for
materials, it’s worth it to note that (1) Python’s a little older,
(2) Ruby started in Japan so there’s a lot of Japanese documentation
out there that hasn’t been translated yet.

But I think the most important thing you should note is how much fun
you have programming in Ruby. If you’re enjoying it, you can trust
that a lot more other people do too. And that’s a REAL “killer
app”. (David Heinemeier H. of ruby on rails talks about
happiness a lot in this respect)

-Mat


#5

On 6/4/06, Hector removed_email_address@domain.invalid wrote:

I’ve been trying to pickup Ruby for a few months now. I’ve written a few
good programs that help me at work with SAN/Unix Administration. I’ve
also run into a few dificult(for me) programming problems. I like to
figure things out on my own so I never post questions in forums like
this, this probably contributes to my bad programming skill, but that’s
besides the point.

It never hurts to ask. If you’re running into some roadblock that’s
keeping you from getting work done, chances are someone else ran into
it previously and you’re likely to ge an answer in an hour or two on
this forum.

I don’t really care about learning 10 programming languages. My brain
wouldn’t be able handle it. I want to learn 1 or two languages and learn
them well. I know Pascal very well, I know Perl pretty well, now I
would like to get away from Perl and so I started out leaning Python. I
think Python is ugly and not very fun to write. I then jumped into
Ruby(a whole lot of fun!) but I don’t get the warm and fussies about
Ruby’s lasting power.

Actually, you should never get complacent about a language’s ‘lasting
power’. Always be ready to learn a new one.

To address your question: I’ve been programming in Ruby since early
2001. Back then it was like pulling teeth to convince management to
let you use it. First you had to educate people as to the existence
of Ruby and then you had to educate them as to it’s capabilities,
stability, viability, etc. Had you posted your question back then you
would have probably gotten a lot of answers that told you not to worry
about ‘lasting power’, if Ruby’s doing the job for you then go ahead
and use it (and that’s still good advice).

Fast forward to 2006: Last week I decided that I wanted to generate
some C++ files from some XML files using Ruby/REXML. That meant that
Ruby had to be part of the build process and environment. A few
emails were sent and some discussion ensued with the result being that
by the next day Ruby was now part of our build environment. People in
the group keep coming to me and asking what’s the best way to learn
Ruby (if they don’t already know it). I’ve already seen PickaxeII
books appearing on people’s desks. People have either heard of Ruby
and would like to learn it, or they have already started learning it.
It’s a big change from 2001. Your question had a lot more validity
back then, but now it’s not really an issue.

Ruby is now mainstream; time to learn Io :wink:

Phil


#6

On Jun 5, 2006, at 9:14 AM, Francis C. wrote:

Many capable Rubyists that I know are of the opinion that nothing
matters
but the joy of programming Ruby. True enough as far as it goes, and
that
alone will drive significant acceptance of the language. But not as
fast or
as far as I would like. I realize I’m throwing down a gauntlet
here, but the
Pythonists have been better at this than we have so far.

Not sure what “this” is. Corporate acceptance?
-Mat


#7

Mat, your statements are right on the money. To the extent that
developers
enjoy using a language, they will use it, when they are at liberty to
choose. But I think it’s important not to lose sight of the fact that
programmers in corporate environments are not always free to so choose.
The
Ruby community has some way to go in meeting the desiderata of the
relevant
decision makers who are not developers and for whom the joy of
programming
is a secondary concern. The degree to which we embrace this challenge as
a
community will have a lot to say about whether we will be able to use
our
favorite language in more and more places.

Many capable Rubyists that I know are of the opinion that nothing
matters
but the joy of programming Ruby. True enough as far as it goes, and that
alone will drive significant acceptance of the language. But not as fast
or
as far as I would like. I realize I’m throwing down a gauntlet here, but
the
Pythonists have been better at this than we have so far.


#8

I’m still new to the language myself, but I’m comming at it as an
enterprise
web developer (Java/.Net).

The killer app for Ruby, for me at least, is Rails. Rails has got so
much
right with regards web development it makes you question how Sun got it
quite so wrong… or at least not as good. However, I can’t see big JEE
houses switching to Rails any time soon.

There are two aspects of Ruby that destroy Rails for enterprise
computing.
The good news is, that they are both fixable.

The first is performance. Ruby might be the same age as Java, but Java
developers are 10 a penny and that means that Ruby is more expensive,
both
in terms of the hardware required to run it, and people required to
develop
it. In order for it to get its foot in the door it needs to massively
reduce
its TCO.

If Ruby’s performance could get close to Java then the reduced
development
costs would be enough to justify the risk of taking on another new
language.
The most obvious way of doing that is to compile it. I know there are
projects to do this already to CLI, bytecode and machine code. My two
cents
is that Ruby should aim for something like Obj C or LISP: native code
with a
heavy reliance on a portable runtime environment.

The biggest mistake I think Ruby could make in this respect is the
continue
to rely on third party groups to add this much needed functionality.
Choice
is good, but it makes it even harder for enterprise to latch on to
something
as they have to sit down and evaluate each solution or worse hire
consultants to tell them which solution to take… shudder.

The second is the effect of soft/duck typing on the IDE. Theology aside,
code completion reduces the learning curve, reduces bugs and increases
productivity. All of these things are a Good Thing ™. I fully
understand
that for a complete novice that intelligent IDEs can hinder overall
understanding, but no more than garbage collection - and what high
productivity language would be without that?

Would allowing the language some syntactic sugar to merely decorate an
object with a type, which could be completely ignored by the runtime,
really
be that much of a bad thing?

I know Ruby isn’t necessarily going after the enterprise market, but
it’s so
neat that I think it would be a waste if it didn’t.

What makes it so unique is that the syntax scales with the project. No
one
would routinely write a shell script in Java as they would in Perl, but
no
one would think that writing a word processor in Perl would be a good
idea
either. Ruby fits for both… at least syntax does.


#9

On Jun 5, 2006, at 9:35 AM, Tom M. wrote:

development
costs would be enough to justify the risk of taking on another new
language.
The most obvious way of doing that is to compile it. I know there are
projects to do this already to CLI, bytecode and machine code. My
two cents
is that Ruby should aim for something like Obj C or LISP: native
code with a
heavy reliance on a portable runtime environment.

Everything I’ve heard so far points to Ruby having similar
performance to Java, but I’m no expert. The availability of
programmers is a bit of a catch 22 problem. But I think the previous
“joy” argument will help fix this to a certain extent. And the
(IMHO) rest can be covered by lowering barrier to entry, which the
ruby community works on daily.

The biggest mistake I think Ruby could make in this respect is the
continue
to rely on third party groups to add this much needed
functionality. Choice
is good, but it makes it even harder for enterprise to latch on to
something
as they have to sit down and evaluate each solution or worse hire
consultants to tell them which solution to take… shudder.

I feel like the ruby community is essentially all third party
groups. But I agree that a rally behind a particular software
package does make the decision process easier. I think there should
be a balance. Diversity is natural. Java has a wealth of competing
tools, if .Net had a stronger community, I’m sure it would too.

runtime, really
be that much of a bad thing?

RDT is making some good headway on code completion. Personally, I
find that type hinting leads to slower, more bug prone development
because it’s one more thing for the developer to think about. Decent
code completion is possible without adding rigidity to the typing
system. But I suppose if a particular IDE wanted an easy way to
implement it, they could do it by way of special comments.

either. Ruby fits for both… at least syntax does.
Personally, I dig the closures. But that’s just me :slight_smile:
-Mat


#10

Well, you’re going to get a lot of…um, “passionate” responses to your
specific points, so I’ll keep it high-level. You’ve made a very good
case
that corporate IT needs a better programming language, but Ruby isn’t
it.
One way to summarize your argument is that Ruby would be better accepted
if
it were more like Java in specific ways. But Ruby is fundamentally
different
from Java in both essence and detail. We still haven’t answered this
question: do the things that make Ruby unique qualify it or disqualify
it as
an enterprise development language? Are corporate developers ready for a
fairly serious change in the way they work? Especially since many of the
younger CS grads have never thought in any language but Java.

If we try to make Ruby an incrementally better Java as a way of driving
corporate acceptance, we’ll fail at both goals.

I don’t understand what you mean when you say that “syntax scales with
the
project.”


#11

Tom M. wrote:

The first is performance. Ruby might be the same age as Java, but Java
developers are 10 a penny and that means that Ruby is more expensive,
both
in terms of the hardware required to run it, and people required to
develop
it. In order for it to get its foot in the door it needs to massively
reduce
its TCO.

Hi Tom, I just wanted to respond to these two points.

Although no one is arguing against improved Ruby performance, I think
you overestimate the hardware issues. I find I am quite comfortable
developing Rails code on my 6 year old laptop. However, I wouldn’t even
consider developing a non-trivial Java application on the same hardware.
Although I’m talking develement and not production deployment, I think
you will find that true across the board.

Justin Gehtland had some numbers on comparing Ruby performance with a
similar Java webapp. You can read about it here:
http://blogs.relevancellc.com/articles/2005/04/04/some-numbers-at-last
(looks like relevance has changed their blog software and some of the
postings lost all formatting … the words and numbers are all there,
you just have to read carefullly, sorry). The summary is that the
unoptimized versions of the Ruby and Java apps had very similar
performance, and that it was very easy to tune the Ruby version with
selective caching options.

The assertion that Ruby cost more in terms of people is an interesting
one as well. Although I don’t have numbers for myself, Stewart Halloway
has published some figures for his consulting company. They offer both
Ruby and Java services and charge 10% to 50% less for Ruby jobs over
Java jobs. And this is after paying Ruby developers more (about 10%).

You can read about Stewart’s findings here:

http://blogs.relevancellc.com/articles/2005/12/19/ruby-rails-put-your-money-where-your-mouth-is
http://blogs.relevancellc.com/articles/2005/12/20/bidding-projects-with-ruby-rails-take-2

– Jim W.


#12

Tom M. wrote:

There are two aspects of Ruby that destroy Rails for enterprise computing.

I personally don’t think that Ruby needs to be “enterprise” in order to
have a bright future.

The good news is, that they are both fixable.

I think there is a temptation for newbies, especially those that are
experienced in other languages (like myself), to want to mold Ruby in
some way that is familiar to them.

Although this is natural, I think trying to keep a beginner’s mind is
important, because it will enable one to really learn something new and
appreciate it for its differences without imposing one’s experiential
biases. If I wanted something like Java or .NET, I’d just use Java or
.NET.

The first is performance. Ruby might be the same age as Java, but Java
developers are 10 a penny and that means that Ruby is more expensive, both
in terms of the hardware required to run it, and people required to develop
it. In order for it to get its foot in the door it needs to massively
reduce
its TCO.

Above you disregard the cost of development itself (and
maintenance/enhancement), which should be included in TCO.

Although I agree that Ruby can be faster, and I’m certain it will be
with YARV/Rite, IME, typically the performance bottleneck is the backend
DB, not the application server. I’m not in production yet, but right
now, Ruby is fast enough for me.

If Ruby’s performance could get close to Java then the reduced development
costs would be enough to justify the risk of taking on another new
language.

Reducing development costs can make a significant difference and there
is risk in playing it safe (i.e. opportunity costs if one believes that
Ruby/Rails will provide a technological advantage).

The biggest mistake I think Ruby could make in this respect is the continue
to rely on third party groups to add this much needed functionality.

Take a look at YARV/Rite.

The second is the effect of soft/duck typing on the IDE. Theology aside,
code completion reduces the learning curve, reduces bugs and increases
productivity. All of these things are a Good Thing ™. I fully understand
that for a complete novice that intelligent IDEs can hinder overall
understanding, but no more than garbage collection - and what high
productivity language would be without that?

IMO, one cannot separate the “Theology” from the argument. If one
believes that duck typing improves productivity and the language
overall, then its impossible to remove it from the context of the
discussion. It’s one of the things that makes Ruby, Ruby.

But regardless, I think the tools side is moving forward. IMO,
ActiveState has a good IDE for Ruby; Arachno is good too. Although it
doesn’t look like an “IDE”, Mac users seem to really like TextMate.

My personal opinion is that Ruby shouldn’t worry about tools; I
appreciate that the emphasis in the community is less on tools and more
about the language, frameworks, etc. Tools vendors are smart, IDE’s are
a mature discipline, so I have confidence they’ll find ways of making
Ruby accessible to newbies.

Would allowing the language some syntactic sugar to merely decorate an
object with a type, which could be completely ignored by the runtime,
really
be that much of a bad thing?

My initial reaction is: yes, it would be a bad thing. I trust those
that know Ruby a lot better than me to make decisions about language
direction.

I know Ruby isn’t necessarily going after the enterprise market, but
it’s so
neat that I think it would be a waste if it didn’t.

I personally think it’s more important for the Ruby community to be
focused on solving real-world problems than to try to market itself to
anything.

Certainly a real-world problem is: how to get my organization to use
Ruby. I personally believe there will be business opportunities for
those motivated enough to capitalize on providing Ruby services for the
Enterprise (whatever those things are…). Book publishing is one
aspect of it, training is another, web hosting, consulting, etc. I
believe it’s happening now and will continue to do so.


#13

Phil T. wrote:

Actually, you should never get complacent about a language’s ‘lasting
power’. Always be ready to learn a new one.

I don’t agree with this statement.

You should look very hard at a language (just like the owner of this
thread is doing), to make sure you are making the right choice.

Many developers, Project Managers, etc., have lost thier jobs because of
making the wrong development choice.

Look at Kylix and C++Builder X, they fit the bill when they where
released, but now people are scrambling to find a replacement (or a new
job).

I’m also fighting these same concerns.
Here’s my list…

  1. No native OS threads.

  2. To get the fully benefit from Rails, your database has to have a
    specific naming convention. (Makes it impossible to migrate to RoR from
    something else).

  3. No generic database drivers built into Rails for databases other than
    the top 3 and open-source databases. (Makes it impossible to migrate to
    RoR if you use a different database)

  4. Slow performance.

  5. Kind of a hack job to get it to work with Apache. (But this could
    also be my lack of knowledge)

I still love the language, but I do have reservations.


#14

On Jun 5, 2006, at 11:22 AM, ReggW wrote:

  1. No native OS threads.

I hear this argument a lot. I do web development, so I rarely worry
about threads at all. What’s the problem here that it makes so many
people’s lists?

  1. To get the fully benefit from Rails, your database has to have a
    specific naming convention. (Makes it impossible to migrate to RoR
    from
    something else).

You can configure ActiveRecord to a certain extent. It sounds like
you might want to investigate it more before saying “you have to”.
You could also use rails w/o ActiveRecord if you really wanted to.

  1. No generic database drivers built into Rails for databases other
    than
    the top 3 and open-source databases. (Makes it impossible to
    migrate to
    RoR if you use a different database)

I think you’re wrong here. I’m seeing stuff in the rails wiki for
Oracle, SQL server, Sybase…

  1. Slow performance.

“Fast enough” seems to be the going mantra.

  1. Kind of a hack job to get it to work with Apache. (But this could
    also be my lack of knowledge)

I haven’t had a lot of luck here either.


#15

On 6/5/06, ReggW removed_email_address@domain.invalid wrote:

Phil T. wrote:

Actually, you should never get complacent about a language’s ‘lasting
power’. Always be ready to learn a new one.
I don’t agree with this statement.

I’m not sure why you don’t agree, because your example (Kylix &
C++Builder) very much agrees with what Phil said.

You should look very hard at a language (just like the owner of this
thread is doing), to make sure you are making the right choice.

If you’re planning on making it your primary programming language, sure.
I don’t get to spend a lot of time programming in Ruby with my current
job, but my Ruby has definitely informed and improved my C++ (and
congealed my hate of that language).

[…]

Look at Kylix and C++Builder X, they fit the bill when they where
released, but now people are scrambling to find a replacement (or a
new job).

Actually, neither was a problem, nor are they really problems. Just
because a tool falls out of favour does not mean that the tool was bad
in the first place. Java will fall out of favour, just as COBOL has.
That’s inevitable. The trick is to be an agile enough to recognise when
something new has to be done.

  1. No native OS threads.

This is less a problem than you might imagine. However, it will be
addressed with YARV/Rite. (In fact, Ko1-san is possibly planning on
making it possible to have Ruby’s green threads run on top of OS
threads. Last year’s YARV presentation suggested that it might even be
possible in the future for a green thread to migrate across OS threads
for performance reasons.)

  1. To get the fully benefit from Rails, your database has to have a
    specific naming convention. (Makes it impossible to migrate to RoR
    from something else).

This isn’t a Ruby problem. It is, however, still possible to migrate.
You will have to do a little more work, but you can override the
defaults for ActiveRecord and once overridden, all of the rest of the
benefits still apply.

  1. No generic database drivers built into Rails for databases other
    than the top 3 and open-source databases. (Makes it impossible to
    migrate to RoR if you use a different database)

This is more a matter of applicability; if most folks don’t need it,
they won’t create it. Maybe it would be worth talking to the vendor
about this.

  1. Slow performance.

This is often claimed, but never conclusively proven in a way that is
generally applicable and generally applicable to the language. Yes, Ruby
has points where it is slow. But performance is not an absolute
measurement; it is a relative measurement. There are definite places to
get improvements from the language, and many of these will be
addressed by YARV (which I’ll finally be able to play with!).

  1. Kind of a hack job to get it to work with Apache. (But this could
    also be my lack of knowledge)

I can’t answer this, but I suspect that it’s a knowledge thing.

-austin


#16

I don’t think any programming language is guaranteed to run
forever. A programming language is mortal. Consider assembly language.
It was widely used at first, but it was soon surpassed by C. Later,
people started to learn C++ because it is a successor of C and it has
object oriented programming feature. Later, Java stroked the earth.

Recently, Bruce A. Tate wrote a book titled ‘Beyond Java.’ In that book,
he said that Java may face a death sooner or later, and java programmer
have to consider other alternatives. Interestingly, he took Ruby as an
example. That means that RoR and Ruby certainly seems to be promising.

I agree with you that Python is not fun, but it has lots of users and
documents and websites about it. In fact, ‘a good language’ does not
imply ‘a succeeded language.’ Many other factors like community affects
the fate of a language, and python has some strong points that Ruby
doesn’t have.

To be frank, I would recommend you to learn C++ or Java if you want to
become an application programmer. If you want to be a system programmer,
C is the best choice. If you care a lot about web programming, I
recommend
Ruby/Java/.NET. If you want to learn some language which glues well with
existing language like C, C++ and want to write some simple apps, I
would recommend Python.

I myself am learning Python after I finished basic grammars and
techniques
of Ruby, and I’ve found interesting posts at comp.lang.python in which
people
talk about Python’s future with regard to Java. They also consider Java
as
fairly prominent while Python’s future as murky.

But who knows the future? haha.

Sincerely,
Minkoo S.


#17

On 6/5/06, Mat S. removed_email_address@domain.invalid wrote:

On Jun 5, 2006, at 11:22 AM, ReggW wrote:

  1. No native OS threads.

I hear this argument a lot. I do web development, so I rarely worry
about threads at all. What’s the problem here that it makes so many
people’s lists?

From a web perspective it even has the potential for performance issues.
Because there are no native threads, its very easy for a system call
(file
or socket handling most commonly) to block the entire Ruby process, not
just
the current ruby thread. Thanks to the ease of IPC in Ruby it can be
less
of an issue, but is definitely something that potentially affects many
people’s views of ruby.

than

  1. Kind of a hack job to get it to work with Apache. (But this could
    also be my lack of knowledge)

I haven’t had a lot of luck here either.

Correction, getting RAILS to work with Apache is a pain. While pure CGI
or
mod_ruby may have performance issues in many cases, it is far from
difficult
to set up. But given the size and complexity of the Rails environment
it
has significant performance requirements, that go beyond the ability to
use
CGI or mod_ruby, but that isn’t entirely the failing of Ruby.


#18

Correction, getting RAILS to work with Apache is a pain. While
pure CGI or
mod_ruby may have performance issues in many cases, it is far from
difficultto set up. But given the size and complexity of the Rails
environment it
has significant performance requirements, that go beyond the
ability to use
CGI or mod_ruby, but that isn’t entirely the failing of Ruby.

Hi

I’ve gotten Rails to work with Apache and FastCGI VERY much without
pain. Getting Tomcat to play with Apache is much harder in my opinion.

/O


#19

Because there are no native threads, its very easy for a system call
(file
or socket handling most commonly) to block the entire Ruby process, not
just
the current ruby thread.
<<<<<<<<<<<<

Try it. You’ll find that your statement is false. There are a lot of
reasons
why one might want native-thread support in Ruby but not blocking a
whole
process on a file or socket i/o isn’t one of them.


#20

On 6/5/06, ReggW removed_email_address@domain.invalid wrote:

Phil T. wrote:

Actually, you should never get complacent about a language’s ‘lasting
power’. Always be ready to learn a new one.

I don’t agree with this statement.

You should look very hard at a language (just like the owner of this
thread is doing), to make sure you are making the right choice.

It may be years before you know if you’ve made the ‘right’ choice.

If you do happen to choose ‘wrong’ (whatever that might mean for you)
you can always go back and learn another language(s). It’s not like
you’re locked into some binding contract or something.

Many developers, Project Managers, etc., have lost thier jobs because of
making the wrong development choice.

Perhaps it’s not because they made the ‘wrong choice’ but more because
they weren’t willing to learn new things?

Look at Kylix and C++Builder X, they fit the bill when they where
released, but now people are scrambling to find a replacement (or a new
job).

Those are tools, not languages. If they know C++ well, they’ll be fine.

Phil