During the development of the framework, the one recurring question that the

Metasploit staff was continually asked was why Ruby was selected as

the programming language. To avoid having to answer this question on

an individual

basis, the authors have opted for explaining their reasons in this document.

The Ruby programming language was selected over other choices, such as python,

perl, and C++ for quite a few reasons. The first (and primary) reason that Ruby

was selected was because it was a language that the Metasploit staff enjoyed

writing in. After spending time analyzing other languages and factoring in past

experiences, the Ruby programming language was found to offer both a simple

and powerful approach to an interpreted language. The degree of introspection

and the object-oriented aspects provided by Ruby were something that fit very

nicely with some of the requirements of the framework. The framework's need

for automated class construction for code re-use was a key factor in

the decision

making process, and it was one of the things that perl was not very well suited

to offer. On top of this, the syntax is incredibly simplistic and provides the

same level of language features that other more accepted languages have, like

perl.

The second reason Ruby was selected was because of its platform independent

support for threading. While a number of limitations have been encountered

during the development of the framework under this model, the Metasploit

staff has observed a marked performance and usability improvement over the

2.x branch. Future versions of Ruby (the 1.9 series) will back the existing

threading API with native threads for the operating system the interpreter is

compiled against which will solve a number of existing issues with the current

implementation (such as permitting the use of blocking operations). In the

meantime, the existing threading model has been found to be far superior when

compared to a conventional forking model, especially on platforms that lack a

native fork implementation like Windows.

Another reason that Ruby was selected was because of the supported existence

of a native interpreter for the Windows platform. While perl has a cygwin

version and an ActiveState version, both are plagued by usability problems.

The fact that the Ruby interpreter can be compiled and executed natively on

Windows drastically improves performance. Furthermore, the interpreter is also

very small and can be easily modified in the event that there is a bug.

The Python programming language was also a language candidate. The reason

the Metasploit staff opted for Ruby instead of python was for a few different

reasons. The primary reason is a general distaste for some of the syntactical

annoyances forced by python, such as block-indention. While many would argue

the benefits of such an approach, some members of the Metasploit staff

find it to

be an unnecessary restriction. Other issues with Python center around

limitations

in parent class method calling and backward compatibility of interpreters.

The C/C++ programming languages were also very seriously considered, but in

the end it was obvious that attempting to deploy a portable and usable framework

in a non-interpreted language was something that would not be feasible.

Furthermore, the development time-line for this language selection would most

likely be much longer.

Even though the 2.x branch of the framework has been quite successful, the

Metasploit staff encountered a number of limitations and annoyances with perl's

object-oriented programming model, or lack thereof. The fact that the perl

interpreter is part of the default install on many distributions is

not something

that the Metasploit staff felt was worth detouring the language

selection. In the

end, it all came down to selecting a language that was enjoyed by the people

who contribute the most to the framework, and that language ended up being

Ruby.