Да, но чем JS примечателен по сравнению с другими языками? Как компилируемый язык он никакой даже в принципе, а как интерпретируемый (динамический)... Зачем мы используем такие языки? Чтобы быстро разработать приложение. Я смотрю, как программисты отлаживают и доводят AJAX-сайты на JavaScript и я четко понимаю и даже вижу примеры из жизни, что сделать намного более стабильное десктопное приложение с той же функциональностью даже проще, а в работе оно получится rock-solid. Даже если его дополнить back-end-ом в виде удаленного сервера, то работа по крайней мере сопоставима по объемам. Просто это не вписывается в современную маркетинговую модель.
То есть, JavaScript плохо справляется со своей основной задачей. Написать на нем user-ский front-end не намного проще, чем на каком-нибудь C++ + QT. Даже если и проще - то не принципиально. Если учитывать время отладки и доводки, а не только время на набрасывание на коленке прототипной демо-версии. И качество приложения получается ниже. И в чем же тогда прикол?

К формату пакетов претензий не имею, хотя и сложно понять, зачем он human-readable, если его люди не читают (ну разве что для отладки глюков в настройках перегруженных историческим наследием серверов). А вот в совокупности вся технология HTTP-доступа имеет столько недостатков, что по ним можно писать книги. :) Основное, на вскидку:
- Отсутствует нормальная поддержка сессий,
- Отсутствует поддержка для загрузки структурированных объектов,
- Кэширование требует танцев с бубном, особенно в сочетании с AJAX,
- Используется протокол TCP, что ведет к неизводимым замираниям и задержкам при загрузке страниц - если пропал один-единственный пакетик от сервера,
- Серверы типа Apache во всей своей архитектуре ориентированы на концепцию файловой системы, хотя все современные сайты - это динамический сгенерированный контент.

Я использую, например, rexx (в текстовом редакторе), с какого-то мохнатого года, это тоже динамический язык. Для работы с HTML (в принципе) он бы тоже подошел. :) Но писать на таких языках что-то серьезное? Это IMHO извращение. Вынужденное, в некоторых случаях.
Неужели Вы не видите, что ВСЯ технологическая цепочка, начиная от HTTP-сервера (типа Apache) и заканчивая JavaScript и HTML - это безнадежное, прогнившее до основания нагромождение "культурных слоев" давно минувших эпох и цивилизаций? Просто нам дано это все в ощущениях, эти технологии уже "раскручены", в них вложены миллиарды баксов и миллионы человеко-лет и поэтому мы не можем от них отказаться. Хотя де-факто это просто хаотическое нагромождение исторического наследия и хаков.
Но гораздо конструктивнее потратить следующие человеко-годы на разработку принципиально новой, современной среды, вообще не использующей никаких элементов этой безнадежно устаревшей цепочки, а не на ускорение JavaScript и добавление еще каких-то 101-х по счету технологий-затычек к существующему маразматическому наслоению.

Возьмем ПРОСТЕЙШИЙ пример - массово используемую вставку XMLHttpRequest.js. 362 строки кода и десятки грязных хаков, чтобы добиться безглючной работы одного-единственного метода средней тривиальности под разными браузерами, включая Opera, Mozilla и IE - ни один из них не делает все как надо. Это п-ц. И так там практически все, может быть просто в чем-то другом несколько меньше глюков и больше стандартизации, но проверки типа браузера и хаки для обхода утечек памяти - в любом framework, в любой большой библиотеке...

Я действительно не встречал ни одного нормального веб-приложения, где бы активно использовался JavaScript. Они все тяжеловесные и в них течет память, или они "виснут" непонятно почему время от времени, особенно при длительном использовании. Включая gmail. Если даже чудом там не течет память - то это исключение, которое подтверждает правило. Значит, что разработчики сайта и frameworks вложили человеко-годы в тяжелый трах с миллионами глюков реализаций JavaScript в разных браузерах и ужасными хаками пофиксили проблему. Причем хаки эти нигде не описаны и эзотерическое знание о них которых передается от учителя к ученику, как в секте, или же добывается reverse engineering-ом чужих сайтов. А на любом ресурсе, где есть программисты на JavaScript (включая Хабрахабр), найдется с десяток статей с частицами таких сведений - что говорит об актуальности проблемы.

Что, неужели там теперь переменные block scoped? :)

Еще одно популярное заблуждение - это то, что в США большие проблемы со свободой прессы, аналогичные российским. Это полный бред, что можно продемонстрировать таким примером: в США прямо перед выборами в основных кинотеатрах страны запросто показывают "Фаренгейт 9/11", но может ли кто-то представить, чтобы в России за пару дней до выборов в центральных кинотеатрах показали что-нибудь на тему "ФСБ взрывает Россию".

Возьмем для примера стартап YouTube. Какого потребительского кредита хватило бы на 1 неделю работы их инфраструктуры? Кто бы им дал обычный кредит под их бизнес-план, если их ресурс бесплатный?

Зачем ищут партнера для разработки дизайна не в курсе. А вот откуда Вы возьмете деньги на зарплату для 4 хороших программистов в течение двух лет, например? Плюс на аренду офиса для них. Причем попробуйте сделать это все по-белому, в стране, где платятся все налоги. Вариант заложить дом, где живут твоя жена и дети не предлагать, к тому же такого дома может и не быть или он может быть сам куплен в кредит.

А если бы не получилось? Что тогда? К сожалению, в любом начинании не все зависит от идеи, но многое зависит просто от удачи. Бывает так, что идея отличная, но удача проекту не сопутствует и все, провал. Например, попытки создания социальных сетей делались давно и неоднократно, но успеха добились конкретно myspace и facebook. Почему именно они? В изрядной степени просто потому, что именно им улыбнулась Фортуна.

Нужны, вообще не представляю без них жизнь. :) Но не зря же ввели ключевое слово restrict, чтобы ограничить область их действия и всякие ключи типа -fstrict-aliasing у GCC. Было бы хорошо, если бы можно было вообще явно описывать диапазоны изменения значений у целых переменных и области действия у указателей (кстати, в древних языках типа PL/I указатели не были настолько неконтролируемыми, как в "C", правда, наверное, там больше заботились о борьбе с ошибками затирания памяти, чем о параллелизме).

Я знаком с технологией OpenMP. К сожалению, удобна она только для чистого счета - расставить прагмы вокруг циклов for. Очень сложно добиться распараллеливания операций над структурами данных - например, сделать так, чтобы распараллеливались операции поиска в дереве, причем чтобы они совмещались со счетом в других циклах. OpenMP везде ставит синхробарьеры. Если убрать их директивами - вся ответственность за последствия на тебе. Начинаешь на микро-уровне обдумывать, что в программе на что влияет и можно ли здесь считать параллельно - никакой помощи от компилятора уже нет. Сделать же что-то вроде параллельной модификации независимых ветвей в дереве средствами OpenMP просто невозможно. То есть, как я и говорил - для чистого счета есть решения (например OpenMP или аналогичные свои средства других компиляторов), а для обработки данных - ничего нет, пиши все сам и принимай все решения своей головой. В этом плане функциональные языки потенциально лучше "C" - они могли бы (в теории) сами выявить изрядную долю параллелизма, так как в них нет переменных и компилятору самому понятно, что можно распараллелить.

Во многом согласен, но как раз на практике с распараллеливающими компиляторами для функциональных языков сложностей еще большие, чем с автоматически распараллеливающими компиляторами для C[++]. Сейчас функциональные языки распараллеливаются по большей части за счет своей run-time системы исполнения, что тоже хорошо, но не позволяет выжать из железа все, на что оно способно.
Хотелось бы иметь компилятор, который дал бы возможность писать идеально распараллеленные "цифродробилки", работающие на пределе возможностей процессора. Причем не только чисто счетные программы, но и с обработкой данных.
Что же касается работы с общими данными, то в последнее время я начинаю склоняться к тому, что лучше ее не иметь вообще, sharing nothing рулит. Чем меньше общих данных, тем лучше. Конечно, иногда от них не уйти по сути задачи (например, если мы разрабатываем базу данных). Но хоть в служебных структурах стараюсь от них избавиться. Пока есть общие данные, будут и все эти неразрешимые толком конфликты типа ложного разделения строчек кэша, будут mutex-ы и т.п.

С компиляторами есть реальные проблемы. Возьмем C или C++ и посмотрим на реальный код программ на них. Там постоянно используются указатели, которые делают крайне сложной или попросту невозможной оптимизацию циклов, так как формально невозможно установить, есть ли зависимости между итерациями цикла или их нет. Сложно выявить индуктивные переменные. Не понятны диапазоны изменения значений переменных. Можно, конечно, всякими прагмами и прочими нестандартными hint-ами указывать компилятору, что он должен делать в каждом конкретном случае - но это сильно усложняет программирование, а программа становится нечитабельной.

Допустим, что ввода-вывода нет вообще. Например, у нас какая-нибудь счетная программа: математика, графика и т.п. Или еще сложнее - база данных, у которой все нужные данные уже лежат в памяти и расходы на ввод/вывод отсутствуют, обращений к ОС нет. Как распараллелить такую программу на 20 ядер, если она написана на "C"?
Я не говорю, что это вообще невозможно - но на практике эта выливается в неимоверный мега-трах, занимающий уйму времени. И это могут сделать только программисты наивысшей квалификации.
Причем мы не достигаем линейного роста производительности даже если задача идеально распараллеливается в теории. И можно поехать крышей, вручную принимая решения на микро-уровне: нужно ли распараллелить memset(p, 0, n) и при каком "n", или что делать с циклом:
while (p) {
   ...
   p = p->next;
}
Язык "C" плохо подходит для современных суперскалярных конвейерных процессоров (особенно с SIMD-расширениями), не говоря уже о многоядерных процессорах.
Чего стоит одна только проблема aliasing-а при использовании указателей - когда никому не известно, какую именно память затрет конструкция вида * p = 0 - не одну ли из глобальных переменных используемых в нашей процедуре? Не тот ли элемент массива, который компилятор только что закэшировал в регистре?
В общем, настало время что-то делать с "C".

Кроме компилятора есть еще и программист. То, что не может сделать компилятор - может за него сделать программист. Кто бы спорил, что функциональные языки потенциально избавляют программиста от изрядной части работы по распараллеливанию кода на нижнем уровне - это и стимулировало research в области функционального программирования.
Но, во-первых, это преимущество по большей части носит чисто теоретический характер, когда в умных книжках рассуждают об автоматических преобразованиях программ, редукциях и лямбда-исчислении. На практике же компиляторы функциональных языков - доступные нам в ощущениях, а не те, о которых ходят легенды - не умеют сами распараллеливать вычисления так хорошо, как следует из теории. Они вообще не очень-то сильны как компиляторы в машинный код, а тем более как распараллеливающие компиляторы. Вместо этого разработчики сред стараются вынести все, связанное с распараллеливанием в run-time - оно и понятно, так намного проще, ведь не нужно привлекать большую науку с переднего края при написании компилятора.
Отсюда и появление всяких конструкций явного параллелизма в, казалось бы, "чистых" функциональных языках, которые могли бы и сами этот параллелизм выявить.
А во-вторых, на практике за все приходится платить. Функциональные языки избавляют нас от траха мозгов с низкоуровневым распараллеливанием кода - но своим pattern matching, динамической типизацией, сборкой мусора, типичной для них компиляцией в байт-коды и т.п., привносят столько накладных расходов, что это де-факто съедает выигрыш от автоматического распараллеливания.
Не говоря уже о том, что мыслить в такой форме возможно, но неудобно - по сравнению с императивными языками. Считайте меня тупым, если Вам так удобнее - но я убедился, что голова меньше болит при написании обычного кода на "C".

Вообще кому как больше нравиться. С моей личной точки зрения больший интерес представляют языки с lazy evaluation, так как они привносят что-то реально новое, по сравнению с обычными императивными языками. А так получается больше игра с формой записи.
Если для Erlang будут сделаны компиляторы, которые на алгоритмах обработки структур данных (матриц, векторов, списков, деревьев, хешей и т.п., а не просто строк с урлами) дадут большее быстродействие, чем дают компиляторы "C" - я предпочту писать программы на Erlang. :) Имею ввиду большее быстродействие на одном процессоре, так как оно показывает качество кода, выдаваемого компилятором. Ведь распараллелить задачу на много ядер через использование передачи сообщений не сложно, и используется эта техника на практике уже больше 10 лет на моей памяти.
Автоматически векторизирующие и распараллеливающие компиляторы для императивных языков (включая "C") так же развиваются уже не один десяток лет и сейчас такие возможности предоставляют обычные mainstream компиляторы.
Что касается PHP, то тут вообще не о чем споить, IMHO. PHP - это скриптовый язык, видно, что изначально он предназначался для внесения несложной динамики в сайты маленьких проектов, магазинов и т.п. Но за неимением чего-то принципиально лучшего (другие классические интерпретируемые скриптовые языки не в счет) PHP стали использовать на всех этапах от создания простого прототипа, до продукта и почти повсеместно, включая мега-проекты, отчего он и распространился. Но не за счет своих преимуществ как языка программирования.