O Di

1. Аналогию с самими языками проводить не стоит. Аналогию стоит провести для платформ.
Платформы вроде .net и java, которые разрабатывались для энтерпрайза, разумеется лучше для него подходят. И не важно даже, десктопное у вас приложение или веб-сервис. Важно, что в платформе есть поддержка нужных стандартов и технологий с гарантией качества от производителя.
С другой стороны, многие компоненты таких платформ это closed-source. Поэтому, если вы не банк, а стартап, то для веб-сервиса выбирайте
Ruby или Python.
Социальную сеть можно сделать много на чем, но я бы делал на рельсах или джанге. А вот функционал сбербанк-онлайн я бы делал на ASP.NET MVC (т.е. на C#) или на джаве (на спринге например). Однако, тот же близзовский battle.net написан на спринге (сервер когда-то случайно отдал мне stack-trace после ошибки).

Хотя, имхо, некоторые ключевые элементы дизайна языка все-таки влияют на возможность его применения в крупных проектах. Например, я считаю, что писать крупные проекты на языке со статической типизацией намного проще. Однако это вопрос очень холиварный.

2. Нет, не будет. Не должно быть, если точнее. Для пользователя язык общения с сервисом - HTTP. Если в современном веб-фреймворке нельзя нормально абстрагироваться от используемой технологии, это плохой фреймворк.

3. На PHP много чего нельзя сделать. Вернее, КАК БЫ можно все, но нормально можно только веб. Именно поэтому для меня он не язык, а какой-то шаблонизатор - слишком у него дурная история и связь с веб (что нехорошо для языка общего назначения). Конечно, современные веб-фреймворки его очень хорошо причесывают, что даже можно работать с ним, но мы же о языках говорим..

4. Для веб-проектов между Ruby, Python и PHP человек бы выбирал исходя из своих умений. У каждого языка своя экосистема (библиотеки, пакетные менеджеры, серверы приложений/плагины для веб-сервера) и довольно непросто знать все сразу. Именно поэтому все расходятся по своим лагерям и просто работают. Первичный выбор языка часто определяет его популярность. Лет 5 назад Руби всех рвал за счет Рельсов, сегодня Питон и PHP подтянулись в плане экосистемы, поэтому ситуация уже другая.
Если человек таки сумел познакомиться с разными языками, он выберет тот, в котором ему проще мыслить. Модель ООП, статическая/динамическая типизация - все это определяет ощущения КОНКРЕТНОГО человека от КОНКРЕТНОГО языка.

5. PHP учится быстрее всех, но если вы не знаете других нормальных языков, лучше его не учите - испортитесь как программист. Python и Ruby учатся примерно одинаково. Изучение C++ - совсем другая история, я бы не ставил его в один ряд с Питоном - этот язык несколько другого уровня и требует других (более глубоких) знаний о вычислительной технике (т.е. он 100% учится дольше, чем Python).

Еще есть java, go - они тоже очень популярны.

И на том и на том пишутся замечательные вещи!

Go очень просто использовать - практически как замена C/C++, только более быстр в разработке. Сильно набирает популярность, достаточно низкоуровневый, чтобы на нем писать системные утилиты и большие распределенные системы. У него есть минусы (дебаггер например), но и плюсов очень много (дебаггер редко нужен).

Java - отдельный вопрос, на нем очень удобно писать очень большие проекты, но кривая вхождения очень высока. Сам язык достаточно простой, но знание фреймворков (библиотек), как раз и составляет то, за что платит работодатель, и очень достойные деньги. Это, сильно не совру, один из самых высокооплачиваемых и рентабельных языков программирования.

Что касается PHP - изначально язык создавался для простых проектов для WEB, как замена CGI, но вроде бы как вырос, появились объекты... Но, дальше WEB он не развивается.

Что касается Ruby - хороший язык, большая инфраструктура (фоеймворки/библиотеки), куча всего понаписано, куча коммерческих сайтов и государственных, типа портала госуслуг Москвы, если не ошибаюсь. Немного медлителен интерпретатор, но это не повод за него не браться. На мой личный взгляд - основное неудобство, постоянный поиск нужной версии библиотеки при пересборке проекта.

Python - отличный язык, очень богатая инфраструктура, куча коммерческих применений. На нем можно делать большие, очень большие, проекты. Очень легок в освоении. Я предпочитаю что-то быстро напрототипировать в питоне, а потом и переписывать не хочется.

Сам программирую на Python, C, Java, PHP.
Относительно неплохо разбираюсь в Ruby и Go, на уровне влесть в чужой проект и поправить ошибку.

Мои фавориты - Java, Python. Присматриваюсь к Go.

На ленту вопросов отдельного тега можно подписаться по ссылке https://toster.ru/rss/tag_questions/###, где решётки - id тега (напр. про Google).

Использую докер-контейнеры как легковесные виртуалки, которыми куда проще манипулировать. И куда меньше душит жаба для конфигов типа "на этой виртуалке будет работать только nginx, на этой только php-fpm, на этой только postgre, эта будет шарить статические файлы для nginx и php-fpm, тут будет лежать кэш, тут загруженные пользователями файлы, а тут база данных"

Всем хорош Django, все у него есть, но...
Django - это коробочный продукт, со всеми достоинствами и недостатками, присущими коробочным продуктам. То есть внутри большой коробки, называемой Django, есть много других коробочек, содержимое которых прекрасно состыковано с самим продуктом и с другими коробочками. Поэтому разработчик на Django чувствует себя вольготно. А если у него возникает проблема, то большое комьюнити всегда поможет.
Я разработал на Django только один проект. Возможно, будь проект простым, я до сих пор бы использовал Django. Но проект оказался неожиданно сложным. Написание кода для обработки данных из некоторого количества таблиц с довольно запутанными связями показало мне, что у Django, несмотря на его популярность, совершенно никудышный ORM. Используя Django, я половину обращений к таблицам реализовывал в чистом SQL, а затем стыковал результаты с данными полученными с помощью ORM. У меня все получилось. Но осадок остался. Поэтому следующую версию того же проекта, и все последующие тоже, я написал на Flask, используя в качестве ORM небезызвестный SQLAlchemy.
Я не жалею времени, потраченного на изучение Django. Это хороший опыт. Те, кто используют Django, чувствуют себя защищенными. Они часть большого дружного сообщества, где можно найти любую поддержку.
Но я также не жалею, что я ушел от Django. У Django вся магия ( регистрация, авторизация, работа с сессиями и многое-многое другое) спрятана под капотом, я просто подключал компоненты и использовал их. Используя Django, я делал многие вещи автоматически, совершенно не задаваясь вопросом как эти вещи работают. Уйдя от Django, я лучше стал понимать то, чем занимаюсь каждый день.
Можете мне поверить на слово, на Flask-е возможно писать очень большие проекты, с большим количеством кода. При этом реализация всей магии ложится на Вас. Это просто вопрос доверия. Используя Django, Вы доверяете всю магию Django, не используя его, Вы доверяете всю магию себе.

Никак :)
А если серьезно, то придётся писать все под Bootstrap. Вот и задайтесь вопросом - подходит ли макет "который не под bootstrap" под те нужны, с которыми Вы хотите использовать Bootstrap. Да и нужно оно ли Вам? Неподходящий макет, например, имеющий другую сетку, создаст Вам много головной боли :)

Для внедрения CI последовательность достаточно проста:
1. VCS. Для начала внедрите git, не обязательно сложности с gitlab. Для 3 человек хватит и приватного репозитория на bitbucket.
2. Приемочные тесты. Берем фреймворк для тестирования (я люблю Codeception, но их много и других), и напишите пару приемочных тестов на критические части (оплата, регистрация напр.).
3. Юнит-тесты. Покройте юнит-тестами основные части проекта (для первой итерации хватит и 5-10% покрытия кода).
4. Автоматизируем. Определяемся с CI, настраиваем ее, настраиваем хуки репозитория и уведомления о success/fail-билдах по почтам разработчиков.

Коротко можно описать так: должен быть гит, и должны быть тесты.
Теперь до непрерывного деплоя рукой подать. Скорее всего, когда вы до этого дойдете, вы уже будете примерно представлять как лучше организовать этот процесс, потому что здесь вариантов великое множество. Начиная от самописных деплой-скриптов и готовых deploy software типа Capistrano, заканчивая разверткой и подменой бэкендов и сменой docker-контейнеров.

Кот

я бы взял тупо ext4 б а так можно и zfs - зерабайт хранить можно.