Оптимальный выбор ЯП для большого соц инфо проекта

Исходите из наличия специалистов под рукой. Любой ЯП хорош, когда спец знает что делает, вам посоветуют php - вы будете искать программиста и не сможете найти (я о хороших программистах сейчас говорю), вам посоветуют ruby, ROR - вы также будете искать спеца, и его также трудно найти, так как те немногие что есть - нарасхват.

Просто слышал, что именно php для огромных проектов не подойдет, так он жрет много там чего-то и не иного потоковый, а нужен многопотоковый и упомянули Python, как подходящий. Вот собственно с этого момента мне интересно.

А на чем фейсбук написан и вконтакте, в основном?

Вы задаете вопросы, на которые хабр вам ответит первой строчкой. FB использует HipHopPHP для оптимизации своего php кода (что она там делает в Си я без понятия на самом деле), VK также написан на PHP но тут не так давно они писали, что сделали нечто похожее на HipHopPhp только я совсем забыл как называется, но написан - да, на php.

Эти штуки значит для ускорения и php похоже очень удобный получается?

Почитайте, я не специалист, я лишь наслышан об этом.

Масштабируемые проекты должны безболезненно горизонтально масштабироваться (т.е. производительность системы должна расти в идеале линейно в зависимости от количества серверов). На каком языке написан функционал - в большой степени не важно, а важно лишь, чтобы в систему была изначально заложена возможность горизонтального масштабирования. Т.к. оптимизацией ЯП вы всего-лишь сэкономите на количестве серверов, на ЗП программистам на экзотических технологиях вы вложите больше денег, чем на увеличение числа серверов.

Если проект взлетит так, что стоимость серверов начнет перевешивать затраты на программирование, код перепишете хоть на С++ - у вас уже будут для этого возможности :)

Это верно, но все же хотелось бы изначально начать с более экономного и удобного варианта, что бы потом не переделывать то, что можно было бы делать с самого начала. В этом и вопрос весь.

Так не бывает, чтоб не переделывать "с самого начала". Поскольку Вы не знаете, с какими проблемами Вы можете столкнуться, то и написать сразу так, как нужно будет в будущем под неизвестные потребности - невозможно. Когда-то Вы все равно возьмете свой "пластилиновый комок", обросший костылями и выкинете вон. Либо умрете под грузом рефакторинга.

Отнеситесь к проекту пока как к прототипу. Сделайте первую версию проекта силами хорошего архитектора и дешевых разработчиков. Когда набьете шишки получите опыт - перепишете.

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

Ассемблер экономный.. и достаточно гибкий. :D