Виктор Юрченко

Скорее всего front-end написана на питоне. Но думаю что помимо питона можно найти и другие)
Сказал бы что на питоне работает api только, но боюсь закидают камнями, точно не знаю, так что утверждать не буду. Сами по себе приложения "клиенты/back-end" написаны на родном языке платформы.
Приложение для андроида всегда на jave или js. Другой язык попросту не поддерживается. У ios это с++, у win phone это вроде бы тоже с++, точно не знаю.

По мимо всего, надо правильно настроить сервера. Успех в балансе.

А vk.com написан на PHP, как так? Ведь приложение есть под все OS.

При установке python, в корневую директорию windows копируется py.exe. Запуская его с разными параметрами запускаются разные интерпретаторы:
Запуск python 2 идет по умолчанию:
py ваш_скрипт.py
или явно:
py -2 ваш_скрипт.py
Запуск python 3:
py -3 ваш_скрипт.py
Документация

Установка модулей:

py -2   -m pip install SomePackage  # default Python 2
py -2.7 -m pip install SomePackage  # specifically Python 2.7
py -3   -m pip install SomePackage  # default Python 3
py -3.4 -m pip install SomePackage  # specifically Python 3.4

Прочитал весь вопрос, но на ответы меня не хватило, так что могу что-то повторить)

Момент 1. Языки. Если ты реально знаешь C++ (указатели, управление памятью, стек, куча, ООП и т.д.), то ты автоматически уже почти знаешь PHP, Python и Ruby. У тебя есть преимущество при изучении этих языков, так как ты уже имеешь представление о том, что реально происходит в твоей программе и, что тоже важно, под капотом интерпретатора. Сами эти языки (с точки зрения подходов и принципов) не так уж сильно отличаются друг от друга. Каждый из них имеет ряд своих особенностей, но их не так много и освоить их не составит труда. При этом изучив любой из языков ты совершенно без проблем перескачишь на любой другой.

Момент 2. Фреймворки. Вряд ли в реальных проектах получится взять язык N, и ручками с нуля что-то на нем делать. Скорее всего будут использованы какие-то фреймворки. Но тут, опять же, достаточно взять любой доступный на языке N фреймворк, чтобы понять подавляющее большинство остальных. Yii, Django, Rails, Laravel - все они схожи гораздо сильнее, чем может показаться. Итог - изучив один из них можно легко перескачить на другой. Каждый перескок будет даваться все легче (актуально и для предыдущего пункта).

Момент 3. Сервер. Если ты хочешь заниматься именно вебом, то сервер, очевидно, его неотъемлемая часть. Тут у языков немного больше отличий, чем в первых двух моментах. Но суть одна - если брать самую распространенную конфигурацию, то должен быть т.н. front-end сервер (не путать с front-end частью приложения), который отдает обычные файлы, не беспокоя само приложение, и back-end сервер (или сервер приложения). Back-end сервер как раз и занимается выполнением кода приложения и тут в зависимости от языка свои особенности по его установке, настройке и связке с front-end сервером. Но все в пределах разумного и вполне реально изучить. Менее распространенные конфигурации можно будет изучить по ходу, да и суть будет похожа.

Момент 4. Node.js. Да, для него отдельный пункт. В JavaScript все построено на асинхронном программировании, поэтому он сильно отличается от "классических" языков. В подробности вдаваться не буду, но рекомендую как минимум с ним ознакомиться, чтобы иметь общее представление об асинхронном программировании, в частности на сервере. Можно взять не Node.js, а какие-то похожие варианты на других языках, но JavaScript основан на этой идее, поэтому я считаю., что оптимально взять именно его.

Момент 5. Лирика. Любая технология решает опеределенный круг задач, поэтому говорить, что она "плоха" просто некорректно. Можно сказать, что она не решает данную конкретную задачу или же есть какая-то другая технология, которая решает ее лучше. Теперь конкретно про PHP, Python и Ruby. Как ты успел заметить в этом вопросе, существует очень много споров о том, что же лучше. Сам факт неугасания этих споров в течении многих лет говорит о том, что нельзя однозначно их разрешить.
Так же есть тренд говорить, что PHP язык для лохов. Но говоря так человек лишний раз доказывает свою некомпетентность и невежество. Исторически так сложилось, что PHP самый распространенный язык, поэтому на нем написано огромное количество вещей разных назначений и качества. Людей, которые могут на нем писать (я намеренно не стал использовать слово "программист"), очень много и логично, что качество кода многих из них оставляет желать лучшего. Многие говорят про порог вхождения, но я бы не сказал, что у того же Python этот порог выше. Плюс PHP за последние годы приобрел много хорошего и как язык, и как его инфраструктура. Короче, можно смело брать PHP :)

Поток мыслей получился немного сумбурный, но, надеюсь, на поставленные вопросы я ответил.

Обычно разделяю предметные области проекта на отдельные приложения. Если какая-то область слишком обширна, то в папке приложения создаю отдельные приложения для подобластей. Для каждого приложения - своя папка templates: это позволяет при большом количестве приложений не путаться в разросшейся иерархии директорий. Кроме того, отправляю всю обособленную статику в директории static каждого приложения: иногда для работы интерфейса пишу JavaScript приложения на Marionette - всегда знаю, где искать нужную кучу скриптов.
Для примера: пишем проект для дилерской сети по распространению и продаже автомобилей. Получается так:

./project_name/
./project_name/settings.py
./project_name/urls.py
./project_name/static/
./project_name/static/css/...
./project_name/static/js/...
./project_name/static/imgs/...
./dealer/
./dealer/admin.py
./dealer/models.py
./dealer/views.py
./dealer/urls.py
./dealer/templates/
./dealer/templates/dealer/
./dealer/templates/dealer/list.html
./vehicles/
./vehicles/admin.py
./vehicles/models.py
./vehicles/logistics/
./vehicles/logistics/models.py
./vehicles/logistics/admin.py
./vehicles/logistics/views.py
./vehicles/logistics/urls.py
./vehicles/logistics/templates/
./vehicles/logistics/templates/logistics/tracking.html
./vehicles/logistics/static/
./vehicles/logistics/static/js/app/tracking/
./vehicles/logistics/static/js/app/tracking/main.js
./vehicles/logistics/static/js/app/tracking/app.js
./vehicles/logistics/static/js/app/tracking/...
./vehicles/sales/
./vehicles/sales/models.py
./vehicles/sales/admin.py
./vehicles/sales/views.py
./vehicles/sales/urls.py
./vehicles/sales/templates/
./vehicles/sales/templates/sales/invoices.html
./vehicles/sales/static/
./vehicles/sales/static/js/app/invoices/
./vehicles/sales/static/js/app/invoices/main.js
./vehicles/sales/static/js/app/invoices/app.js
./vehicles/sales/static/js/app/invoices/...
./static/
./media/
./templates/
./templates/base.html
./templates/...

Далее по аналогии. Если нужна какая-то мелочь - отправляем ее в соответствующее "корневое" приложение; если мелочь становится более серьезным куском функционала в рамках той же предметной области - создаем ей отдельное приложение внутри уже существующего. Все, что выходит за рамки предметной области - новое "корневое" приложение.

Пусть на меня пожалуются, но))

Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге.

госпади, можно ж поискать...

https://github.com/github/hub

API социальных сетей - это вполне типичные примеры реализации REST API.

REST (RESTful) - это общие принципы организации взаимодействия приложения/сайта с сервером посредством протокола HTTP. Особенность REST в том, что сервер не запоминает состояние пользователя между запросами - в каждом запросе передаётся информация, идентифицирующая пользователя (например, token, полученный через OAuth-авторизацию) и все параметры, необходимые для выполнения операции.

Всё взаимодействие с сервером сводится к 4 операциям (4 - это необходимый и достаточный минимум, в конкретной реализации типов операций может быть больше):
1. получение данных с сервера (обычно в формате JSON, или XML)
2. добавление новых данных на сервер
3. модификация существующих данных на сервере
4. удаление данных на сервере

Операция получения данных не может приводить к изменению состояния сервера.

Для каждого типа операции используется свой метод HTTP-запроса:
1. получение - GET
2. добавление - POST
3. модификация - PUT
4. удаление - DELETE

Т.е. :

GET-запрос /rest/users - получение информации о всех пользователях
GET-запрос /rest/users/125 - получение информации о пользователе с id=125
POST-запрос /rest/users - добавление нового пользователя
PUT-запрос /rest/users/125 - изменение информации о пользователе с id=125
DELETE-запрос /rest/users/125 - удаление пользователя с id=125

Суть в том, что вы можете четко контролировать в какой момент получилось плохо. Вы можете проследить цепь событий которая к этому привела. И главное — вы можете спокойно откатиться на тот момент когда все было хорошо.
В случае с гитом и доступом к ssh вы делаете так, на локальной машине
git push
на сервере
git pull
И собственно все!
Если вы работаете с композером, то можно например настроить composer up на выполнение git pull перед обновлением зависимостей. Таким образом вы весь проект приводите к актуальному состоянию одной командой.
И да, у вас по хорошему должна быть отдельная БД, в которой лежат тестовые данные, ведь вам важны схемы таблиц, а не их содержание по ходу разработки?
Также по поводу гита — представьте что вы на столько любите женщин, что хотите встречаться с несколькими одновременно. В реальности трудно удержать более n-кол-ва паралельно, они столкнутся и вам будет плохо. А в git вы просто создаете ветки и то процедуры слияния они друг о друге не подразумевают. По хорошему каждая фича вашего приложения должна создаваться как отдельная ветка(branch), таким образом вы сможете просматривать историю разработки конкретно этой фичи отдельно.
Сумбурно, но это ощущение после полугодичного использования гита.
PS также представьте что вы сейчас вероятно один работаете, а каково работать таким образом в команде. Если это делать без VCS — высока возможность перезаписать файл который только что изменили и тд и тп

Неизбежные накладные расходы.

Например, программа, которую вы написали, делает полезную работу в течение 10 мс, но на запуск и завершение виртуальный машины Ява уйдет дополнительно 5 секунд, и эти 5 секунд будут оверхедом.

Девид Флэнаган — Javascript (5 издание)

Сам пишу на .NET и на мой взгляд, конкретно для создания «сайта» лучше использовать другие технологии. Безусловно, можно сделать сайт любой сложности на ASP.NET MVC, если у вас прямые руки, и он будет ничем не хуже сайтов на других технологиях. Но зачем привязывать себя к Windows? На Django или RoR вы напишите такой же сайт, и сможете размещать его где угодно. Другое дело если вы используете .NET для сложных больших проектов (распределенные корпоративные приложения, например) и в этом вот проекте, в качестве его части, нужно написать веб-приложение. Очевидно, что здесь вы будете использовать ASP.NET MVC, потому что использовать другие технологии нет никакого смысла. Соответственно, если вы не привязаны к .NET, и планируете в будущем заниматься исключительно веб-разработкой — лучше присмотритесь к другой технологии. У NET все же несколько иное назначение.