Add a 'Why Ruby?' section.

Author: rustyio

README.md

@@ -12,6 +12,8 @@ API functionality. As of July 2015, the FiveStreet team runs a
 SuperIMAP cluster processing ~400k emails per day for thousands of
 users.
 
+SuperIMAP is written in Ruby and open sourced under the MIT license. [Why Ruby?](#why-ruby)
+
 ## Contents
 
 * [Installation](#installation)
@@ -36,6 +38,7 @@ users.
   * [Manage a User](#apiv1connectionsimap_provider_codeuserstag)
 * [Operations](#operations)
   * [Process Types](#process-types)
+  * [Why Ruby?](#why-ruby)
   * [Environment Variables](#environment-variables)
   * [Scaling](#scaling)
   * [Monitoring](#monitoring)
@@ -369,11 +372,11 @@ updating the user (ie: a PUT request.
 
 #### Process Types
 
-SuperIMAP consists of 3 different processes:
+SuperIMAP consists of 3 different processes, all written in Ruby / Rails:
 
-+ 'web' - Serves the admin interface and the API.
-+ 'imap_client' - Handles the task of connecting to IMAP providers and listening for email.
-+ 'worker' - Processes background jobs generated by the 'imap_client' process.
++ `web` - Serves the admin interface and the API.
++ `imap_client` - Handles the task of connecting to IMAP providers and listening for email.
++ `worker` - Processes background jobs generated by the 'imap_client' process.
 
 #### Environment Variables
 
@@ -429,6 +432,24 @@ Apart from keeping an eye on these metrics, SuperIMAP should need no other regul
 
 You may also want to keep an eye out for any failing Delayed Job tasks. You can view these from the Admin site.
 
+#### Tracer Emails
+
+SuperIMAP has the ability to give you useful monitoring information
+through "tracer emails". The system will send a specially formatted
+email to an account, wait for the incoming email, and log the
+results. The logs can be accessed through the "Tracer Logs" tab.
+
+To enable Tracer Emails, navigate to a user and check the "Enable
+Tracer" checkbox. It is recommended that you create a few dummy email
+addresses to use for tracer emails.
+
+By default, a cluster of three tracers are sent every ten minutes from
+each `imap_client` instance to a random tracer-enabled user managed by
+that instance.
+
+Keep in mind that this could generate a lot of email. Three emails
+every ten minutes works out to ~430 emails per day.
+
 #### Performance
 
 SuperIMAP's architecture makes judicious use of system resources:
@@ -464,23 +485,62 @@ users requires just 10 database connections, uses about 3GB of RAM,
 and has a 0.50 load average. The work queue usually sits near 0, with
 a latency of < 0.5 seconds.
 
-#### Tracer Emails
-
-SuperIMAP has the ability to give you useful monitoring information
-through "tracer emails". The system will send a specially formatted
-email to an account, wait for the incoming email, and log the
-results. The logs can be accessed through the "Tracer Logs" tab.
-
-To enable Tracer Emails, navigate to a user and check the "Enable
-Tracer" checkbox. It is recommended that you create a few dummy email
-addresses to use for tracer emails.
-
-By default, a cluster of three tracers are sent every ten minutes from
-each `imap_client` instance to a random tracer-enabled user managed by
-that instance.
-
-Keep in mind that this could generate a lot of email. Three emails
-every ten minutes works out to ~430 emails per day.
+#### Why Ruby?
+
+At first glance, and from a purely technical point-of-view, Ruby is a
+poor choice for an application like SuperIMAP. SuperIMAP is highly
+concurrent, and Ruby is bad at concurrency.
+
+Specifically, the `imap_client` process spans what could technically
+be described as a "boatload" of threads (2 threads per connected user,
+plus a handful of other threads). Ruby threads are heavyweight, so the
+interpreter has to burn significant resources just to create and
+schedule the threads before it can do any real work.
+
+Using Erlang, Go, or Rust (all of which support lightweight threads
+and actor-style programming) would have made the concurrent bits of
+SuperIMAP less tricky to write, and would have required fewer
+computing resources, possibly allowing a single box to handle tens of
+thousands of active users.
+
+So, why Ruby? A few reasons:
+
++ **FiveStreet uses Ruby** - The primary goal of SuperIMAP is to power
+  a critical part of FiveStreet's application. FiveStreet is built and
+  maintained by a small team of Ruby engineers. The entire FiveStreet
+  application is written in Ruby. Adding a language would force the
+  team to spend dozens of hours learning a new stack and maintaining a
+  new development environment.
+
++ **Low barrier to entry** - A secondary goal of SuperIMAP is to become
+  a healthy open-source project. Based only on language popularity, it
+  is more likely that another team can use, troubleshoot, and contribute to
+  a Ruby-based SuperIMAP than an Erlang/Go/Rust-based SuperIMAP.
+
++ **The concurrency is not complicated** - The concurrency in SuperIMAP is
+  fairly straightforward -- one parent process, many child
+  processes. It's a little painful to solve the problem in Ruby, but
+  not impossible.
+
++ **For us, the cost savings are small** - FiveStreet's SuperIMAP
+  cluster currently runs on three commodity servers and happily handles
+  thousands of users. It's possible that if SuperIMAP were written in
+  a different language, we could handle the load on a single machine,
+  saving us a few hundred dollars a month. Not worth changing our
+  stack for it.
+
++ **Ruby has mature IMAP and OAuth 2.0 libraries** - Ruby has a
+  [built-in IMAP library](http://ruby-doc.org/stdlib-2.0.0/libdoc/net/imap/rdoc/Net/IMAP.html),
+  and a
+  [widely-used OAuth 2.0 library](https://github.com/intridea/oauth2). As
+  of 2015, the IMAP and OAuth 2.0 libraries for other languages are
+  [far](https://github.com/alexcrichton/oauth2-rs)
+  [less](https://github.com/boorad/erlimap)
+  [mature](https://github.com/mxk/go-imap).
+
+Side Note: This was a deeply considered choice. I (Rusty Klophaus, the
+author of SuperIMAP) spent about 4 years writing Erlang
+professionally. It's a fascinating language
 
 ## Appendix