Чтобы понять причину выбора 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 самых популярных языков * с хорошим сообществом разработчиков, сторонними библиотеками и стабильностью.
Это оставляет нам следующие варианты выбора и некоторые из связанных с ним соображений:
- PHP начинал как язык шаблонов для HTML. Если вы создавали веб-приложения в то время, скорее всего, вашим набором инструментов был PHP. Его сценарии / шаблоны создают множество плохих парадигм программирования, и простота освоения этого языка была палкой о двух концах. Среднестатистический новичок может выучить PHP за день и будет склонен делать много ошибок при работе с ним. Если ваша команда состоит из группы начинающих инженеров, которые все еще учатся в колледже (каковыми были мы), скорее всего, вы столкнетесь с множеством странных ошибок, которые время от времени выявляются, и которые чрезвычайно трудно отловить. Все могло бы быть иначе, если бы PHP 7.2 существовал тогда, а мы все были опытными разработчиками PHP.
- Java был типизированным языком. Если вы начали изучать веб-программирование из мира PHP / JavaScript, Java была довольно сложной задачей. Веб-фреймворки, которые его сопровождали, были в основном Java Server Faces (JSF), Struts и Spring framework. Если у вас был какой-либо опыт в их развитии, вы поймете, что скорость разработки была чрезвычайно медленной, наряду с крутой кривой обучения. Не помогает и то, что сам Java - язык, который довольно сложно освоить. (Был также фреймворк PLAY, который считался более простым в использовании, но в то время он не был достаточно зрелым с хорошим сообществом разработчиков)
- JavaScript на Node.js все еще находился на начальной стадии разработки. Мы чувствовали, что нужно больше времени, чтобы повзрослеть. Кроме того, поддержка Node.JS для Windows была выпущена только в июле 2011 года. Почему это важно? В то время Mac был чрезвычайно дорогим для среднего студента колледжа. Необходимость двойной загрузки вашего ноутбука создает дополнительные трения и не дает ему набрать популярность среди разработчиков, чтобы попробовать.
- Python VS Ruby - все сводится к выбору между стеком python или ruby в конце дня. Для более глубокого сравнения и обсуждения эта статья довольно хорошо резюмирует.
В конце концов, мы выбрали Ruby on Rails из-за следующей философии, которую мы считали важной:
Сильная философия TDD
Нет множественного наследования
Выбор базового одноуровневого / многоуровневого наследования достаточно сложен, если вы хотите придерживаться хорошего шаблона проектирования наследования. Избежать проблемы ромба будет сложно, если вы смешиваете в своей кодовой базе как многоуровневое, так и множественное наследование.
В Ruby мы предпочитаем композицию наследованию за счет использования миксинов, даже несмотря на то, что недостатки могут заключаться в том, что поведение системы становится труднее понять, а методы, существующие в классе, возможно, придется повторно реализовать в другом классе (или требуются дополнительные усилия, чтобы преобразовать этот метод в миксин)
Надежный + динамически типизированный
- Строго типизированный язык делает язык более предсказуемым, более ранним обнаружением ошибок и, следовательно, меньшим количеством побочных эффектов. Потеря некоторой гибкости с большей предсказуемостью выгодна в долгосрочной перспективе.
- Языки с динамической типизацией легче читать. Период. (Конечно, мы всегда можем выбрать добавить статическую типизацию позже, если мы хотим повысить предсказуемость)
* C ++ / C не было в списке, так как в то время не было доступных хороших веб-фреймворков. Управление указателями было в значительной степени ручным процессом, и скорость итераций, необходимая для создания веб-приложений, делала его непригодным.