Я думаю что будет уменьшаться, но сила инерции здесь будет очень велика.
Ну а насчет веб-а, на С++ то-же пишут, всякие Facebook-и и яндексы, которым приходится обрабатывать очень много данных, используют С++. Гугловский big table то-же не на PHP написан.  
В общем С++ будут по прежнему использовать для всякого server side-a  
Ну и в gamedev-e, естественно... XNA, это конечно круто, но люди, которые там работают, даже стандартные контейнеры иногда боятся использовать... FPS наше все  
Но!
Через несколько лет все может измениться. Все дело в законе Мура, как известно, тактовые частоты современых процессоров, некоторое время назад, перестали расти. Вместо этого, начало расти количество ядер, этих процессоров. Года через 2-3, hi end десктоп, будет похож на современный сервер, то-есть иметь штук 16 CPU.  
Реализовывать параллельные/конкурентные алгоритмы на С++, это pain in the ass. Никогда не знаешь, будет ли оно на самом деле работать быстрее, или же все будет работать даже медленнее обычного, последовательного кода. С++, это shared memory и explicit locking, со всеми вытекающими.
Помимо этого, еще существует такая штука, как vector processing, а с векторизацией кода, у С++ компиляторов как правило туго.

в жабаскрипте радуют лямбды с замыканиями, полная интроспекция, и простой синтаксис инициализации структур (объектов)

но лямбды с замыканиями будут в С++0х (0xA-0xF), а интроспекция и прочие радости жизни... ну чтож поделать, зато в жабаскрипте перегрузки операторов нет

а зачем?
впрочем как и в Java.

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

Конечно языки с динамической компиляцией и хорошей динамической оптимизацией дали бы еще большую производительность.
Но я хз есть ли они, и удобно ли на них писать.

ты так говоришь, как будто VM, это что-то плохое
наоборот, VM обеспечивает модульность и interoperability(не знаю как перевести), простой пример, ты написал программу на с++, в которой использовал стороннюю библиотеку, потом вышла новая версия этой библиотеки, которая умеет портить память  
В результате, твоя программа упадет, но в каком нибудь неожиданном месте, тебе не кажется что это не совсем... технологично, что-ли. Плохая модульность.
Другой пример, у тебя есть библиотека, написанная на чем нибудь экзотическом, с calling convention ты разобрался, но вот беда, библиотека оперирует с float-ами другого формата и функции этой библиотеки возвращают далеко не примитивные типы данных... Х#вое interoperability.

Oxy, перегрузка операторов затем что DSL, и затем что обобщенность
я предпочитаю писать iterator++ вместо iterator.increment()
и писать код одинаково работающий как со стандартными числовыми типами, так и с любыми классами поддерживающими арифметические операторы.

в последнее время меня вообще умиляют рассказы о всевозможных DSL на C++. 
DSL, как правило!!, это когда ты сидишь и пишешь много часов не саму программу, а этот гребаный DSL, ф-я которого состоит в том, что-бы автоматически выявлять логические ошибки во время компиляции
это неоправданное усложнение кода в большинстве случаев, а поддержка кода состоящего(чуть более чем сами знаете как) из шаблонной магии, это ###, потому-что через месяц возникает вопрос, что за ### написал эту ###
если С++ код использует template metaporgramming для реализации expression templates для реализации EDSL для какой-нибудь маловажной ###, то скорее всего программисту просто было пакайфу его писать, вероятно он чувствовал себя ### каким умным в этот момент и вряд-ли задумывался о том, что тратит время зря  
Но конечно, если вас зовут Joel de Guzman, то флаг вам в руки, в остальных случаях...  

Lazin, цена которая платится за преимущества ВМ слишком высока.
В ВМ есть только то, что есть в этой ВМ, а это не всегда соответствует возможностям конкретной системы, под которую и пишется программа.

Допустим в ВМ нет доступа к реальной памяти, поэтому код библиотек не может ее портить. Но если этот доступ был бы реально полезен для задачи -  его не получить.
Или например в ВМ используется один формат float'ов , а на самом деле этих форматов float'ов много, и не факт что тот float который в ВМ лучше подойдет к моей задаче, но нормального способа юзать другой float в ВМ нет.

Добавлено через 5 минут и 35 секунд
Lazin, ДСЛ - это не обязательно вещи уровня лямбды или спирита.
перегрузка * для перемножения матриц - это уже ДСЛ.
использование + для конкатенации буферов - это тоже ДСЛ.

но если в коде будут сложные выражения, то шаблоны выражений вместо явной композиции функции могут реально ускорить код, при этом сделав его более читаемым. Да, это только для тех случает когда сложность задачи оправдывает время на написание ДСЛ.

и если знать язык и методы написания такого кода - то много времени это не займет

Добавлено через 7 минут и 7 секунд
и да, это действительно пакайфу писать =)

не преувеличивай, так можно договориться и до того, что метод push_back, добавляющий что-либо в конец контейнера, это то-же DSL  

Задача программиста состоит в том, что-бы сделать так, что-бы задача перестала быть сложной, а не в том, что-бы решить очень сложную задачу - очень сложными средствами. Код, который использует какой-либо DSL, например boost.spirit, выглядит проще, но это не значит, что он делает что-то столь-же простое. Иногда это приводит к тому, что код делает не совсем то, что от него ожидает программист.

Обычно, существует возможность использовать нативный код, практически в любой ВМ. С другой стороны, тот-же .NET FCL имеет столько возможностей, что вряд-ли тебе это часто будет нужно 

Добавлено через 10 минут и 1 секунду

оговорюсь, я использую boost.spirit, но не потому-что это круто  , а потому-что это действительно пример удачной реализации DSL, можно привести примеры неудачных, например библиотека SOCI. Если говорить о spirit-e, то это очень сложный проект, который живет уже достаточно долго и в котором участвовали далеко не дилетанты - http://spirit.sourceforge.net/spirit_folks.html

Т. е. кеширование у нас отменили?! А в случае с С++ - почему в стандартный рантайм не встроена, скажем, ГУИ-либа? Кто-то от этого страдает?


Ну.. ТЫ говоришь про бэкенды. Да-да СУБД никто не писается писать на прикладных языках - это область системного программирования. Здесь С++ никуда не уйдёт. Сспоры, что С != С++ оставим, я это понимаю, но в данном случае это неважно, ибо для СУБД оправдано использование С++ в разумной мере  


  


Проблема не в этом. Проблема в том, что в С++ средств полноценного метапрограммирования на самом деле нет. Точней так - есть средства метапрограммирования, но предназначенные только для абстрагирования от типа. А ДСЛ-и строить на С++ - это извращенье