Чтобы понять причину выбора Ruby on Rails, нам нужно повернуть время вспять и взглянуть на техническую сцену 2012 года, эпоху iPhone 5 / Samsung Galaxy S3.

In 2012,

  • Java, Javascript, Python, PHP и Ruby заняли лидирующие позиции в создании крупнейшего сообщества разработчиков.
  • GoLang было всего 3 года
  • TypeScript был только что представлен
  • C # и .NET framework были довольно хороши, но вам пришлось заплатить дорогую лицензионную плату за Microsoft IIS Server, чтобы разместить его.

Тогда естественным выбором было выбрать один из 5 самых популярных языков * с хорошим сообществом разработчиков, сторонними библиотеками и стабильностью.

Это оставляет нам следующие варианты выбора и некоторые из связанных с ним соображений:

  1. PHP начинал как язык шаблонов для HTML. Если вы создавали веб-приложения в то время, скорее всего, вашим набором инструментов был PHP. Его сценарии / шаблоны создают множество плохих парадигм программирования, и простота освоения этого языка была палкой о двух концах. Среднестатистический новичок может выучить PHP за день и будет склонен делать много ошибок при работе с ним. Если ваша команда состоит из группы начинающих инженеров, которые все еще учатся в колледже (каковыми были мы), скорее всего, вы столкнетесь с множеством странных ошибок, которые время от времени выявляются, и которые чрезвычайно трудно отловить. Все могло бы быть иначе, если бы PHP 7.2 существовал тогда, а мы все были опытными разработчиками PHP.
  2. Java был типизированным языком. Если вы начали изучать веб-программирование из мира PHP / JavaScript, Java была довольно сложной задачей. Веб-фреймворки, которые его сопровождали, были в основном Java Server Faces (JSF), Struts и Spring framework. Если у вас был какой-либо опыт в их развитии, вы поймете, что скорость разработки была чрезвычайно медленной, наряду с крутой кривой обучения. Не помогает и то, что сам Java - язык, который довольно сложно освоить. (Был также фреймворк PLAY, который считался более простым в использовании, но в то время он не был достаточно зрелым с хорошим сообществом разработчиков)
  3. JavaScript на Node.js все еще находился на начальной стадии разработки. Мы чувствовали, что нужно больше времени, чтобы повзрослеть. Кроме того, поддержка Node.JS для Windows была выпущена только в июле 2011 года. Почему это важно? В то время Mac был чрезвычайно дорогим для среднего студента колледжа. Необходимость двойной загрузки вашего ноутбука создает дополнительные трения и не дает ему набрать популярность среди разработчиков, чтобы попробовать.
  4. Python VS Ruby - все сводится к выбору между стеком python или ruby ​​в конце дня. Для более глубокого сравнения и обсуждения эта статья довольно хорошо резюмирует.

В конце концов, мы выбрали Ruby on Rails из-за следующей философии, которую мы считали важной:

Сильная философия TDD

Нет множественного наследования

Выбор базового одноуровневого / многоуровневого наследования достаточно сложен, если вы хотите придерживаться хорошего шаблона проектирования наследования. Избежать проблемы ромба будет сложно, если вы смешиваете в своей кодовой базе как многоуровневое, так и множественное наследование.

В Ruby мы предпочитаем композицию наследованию за счет использования миксинов, даже несмотря на то, что недостатки могут заключаться в том, что поведение системы становится труднее понять, а методы, существующие в классе, возможно, придется повторно реализовать в другом классе (или требуются дополнительные усилия, чтобы преобразовать этот метод в миксин)

Надежный + динамически типизированный

  1. Строго типизированный язык делает язык более предсказуемым, более ранним обнаружением ошибок и, следовательно, меньшим количеством побочных эффектов. Потеря некоторой гибкости с большей предсказуемостью выгодна в долгосрочной перспективе.
  2. Языки с динамической типизацией легче читать. Период. (Конечно, мы всегда можем выбрать добавить статическую типизацию позже, если мы хотим повысить предсказуемость)

* C ++ / C не было в списке, так как в то время не было доступных хороших веб-фреймворков. Управление указателями было в значительной степени ручным процессом, и скорость итераций, необходимая для создания веб-приложений, делала его непригодным.