D, Go и Rust, взлетит ли что-нибудь?

не будет полностью обратно совместимы со старыми и при этом работать на порядок быстрее старых

Не факт. Для перехода проекта на новый язык достаточно более-менее простого интерфейса к старому языку (хотя бы к си) и более простого программирования при приемлемой производительности. Примеры java|python|.net|да тех же С++ это наглядно демонстрируют. Например кресты прекрасно вытеснили С из области игр. Несмотря на то, что крестовый подход к программированию медленнее сишного. Производительность выше, чем у си никому не нужна, да и врядли возможна. Нужны большие гарантии со стороны языка, при сравнимой производительности.

Примеры java|python|.net

очень медленно и мучительно отвоёвывают себе внимание и место под солнцем, и при этом старые и пока ещё работающие модули и программы никто не стремится полностью портировать под новый язык, особенно когда имеется возможность обратиться из нового языка к коду написанному на старом (в виде внешней библиотеки), более того там где это необходимо ради повышения скорости многие модули намерено переписываются на старых языках (си и даже ассемблер), игнорируя такие незначительные критерии как простота и безопасность программирования. Там где от производительности программы напрямую зависит прибыль, любые другие критерии становятся настолько незначительными что даже и не рассматриваются.

очень медленно и мучительно отвоёвывают себе внимание и место под солнцем

Очень быстро заняли свои ниши, и дальше ничего отвоёвывать не будут. Ибо не должны.

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

А зачем это кому-то может понадобится? Только ради фана. А ради фана мало чего делается. В особенности бесполезного.

ради повышения скорости многие модули намерено переписываются на старых языках (си и даже ассемблер)

Покуда ничего высокоуровнего быстрее сишки нет, там где нужна скорость будет править сишка (с крестами в обнимку). Только скорость нужна в небольшом объёме кода.

Там где от производительности программы напрямую зависит прибыль

А вот здесь хотелось бы пару примеров из несистемщины. Понятно, что linux-kernel должен быть маложрущим. А вот большие приложения должны эффективно масштабироваться. И сишка и прочее байтодрочерство здесь сильно вредит.

А вот здесь хотелось бы пару примеров из несистемщины.

Такие примеры чаще всего из области перехода с какого нибудь PHP на C++ (или куда там фейбук перешёл). Эффективное масштабирование конечно помогает и спасает, но не отменяет постоянной и неустанной оптимизации производительности. Из несистемщины ещё можно вспомнить про базы данных которые сплошь на крестах и сях и борятся за каждый такт или такую специфичную область как биткойны где ради прибыли вообще переместились на уровень железа.

с какого нибудь PHP на C++ (или куда там фейбук перешёл)

Может быть я ошибаюсь, но емнип фэйсбук написал HHVM под себя. А HHVM это пыха с плюшками.

Базы данных - да, они все сплошь на си, за исключением пары nosql на жабе. Но в этом они сродни библиотекам. Для них нужна скорость, и поэтому их пишут на си с крестами. И это оправдано. Но БД - это всё таки системный уровень, а не прикладное приложение. Так что давай ещё примеры.

ну знаете IT мир ядром и окошечками не ограничивается, и там где идёт борьба за милисекунды на исполнение запроса (поисковики ага) вы даже жабы уже не встретите не говоря уже об менее производительных языках.

Я точно не знаю, но могу предположить, к примеру в высокочастотном трейдинге, где уже не хватает скорости оптоволокна и конкурентным преимуществом считается сигнал доставленный на 100 милисекунд быстрее, как думаете долго будут мириться «приемлемой» производительностью?

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

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

ну знаете IT мир ядром и окошечками не ограничивается

Несомненно это так.

идёт борьба за милисекунды

В таких компонентах даже кресты не очень часто можно встретить.

Но мы начинали разговор про

массового перехода на них значительной части индустрии не произойдёт

А то, что ты описал выше - весьма специализированные случаи.

100 милисекунд быстрее, как думаете долго будут мириться «приемлемой» производительностью?

В таких системах объём кода, влияющий на эти 100 миллисекунд крайне мал, в сравнении с остальным кодом. Поэтому, например, nginx написан на си, а остальное на пыхе/жабе/питоне и т.д.

И переписывать даже фэйсбук, при их то масштабах, на си/кресты никто не спешит. Дешевле оптимизировать пыху.

А при меньших масштабах куда дешевле поставить десяток доп серверов, чем нанимать два десятка сишников.

А в прикладных вещах от си уже давно ушли на языки на порядок медленнее. И все довольны, даже пользователи.

Но мы начинали разговор

это всё были примеры того

где от производительности программы напрямую зависит прибыль

а что касается

массового перехода на них значительной части индустрии не произойдёт

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

А при меньших масштабах куда дешевле поставить десяток доп серверов

десяток доп серверов конечно же поставят, но когда масштабы достигнут таких уровней, что для увеличения производительности хотя бы в два раза нужно поставить сотни серверов, то будут нанимать не два десятка сишников, а сотню, и всё ради повышения производительности хотябы на 1%

и когда у тебя сервера имеют больше 10 ядер загруженных на 100% 24 часа 7 дней в неделю, и оперативной памяти больше чем места на дисках и забита она тоже на 100%, но не дисковыми кешами, и программа не сидит в блокировке потоков или ожидании сетевых пакетов, то есть когда оптимизировать больше нечего, тогда ты узнаешь что такое хардварные счётчики и будешь оптимизировать программу изменением порядка ассемблерных инструкций только потому, что больше уже ничего не остаётся, но надо ещё хотябы 1%

А в прикладных вещах от си уже давно ушли

но осталась куча библиотек которые на низком уровне выполняют всю ту работу (например кодирование\декодирование) которую невозможно переложить

на языки на порядок медленнее

иначе это будет настолько медленнее что даже пользователи будут недовольны.

Ну в общем со всем описанным тобой я ни в коем случае не спорю.

Видимо под массовым переходом на них значительной части индустрии мы понимаем разные вещи.

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

Из несистемщины ещё можно вспомнить про базы данных которые

хм, может я перегибаю, но из того что я наблюдаю - каждая вторая на Java

к примеру в высокочастотном трейдинге

вот уж кто не нужен - так это спекули всяческие

Производительность выше, чем у си никому не нужна, да и врядли возможна.

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

Говорят, что кур доЯт. Столетиями спрессованное до состояние окаменелости говно очень плохо пригодно для числоблудия и непригодно совсем для решения каких-либо других задач. И да, на перемножениях матриц, например, влоб написаный код из BLASA, сливает на десятичный порядок по производительности написанному более изощрённо коду на Цхх (см. напр., библиотеку Eigen). Так что апологеты некромантии делают вывод об охренительной пригодности этого ископаемого дерьмеца по соотношению (пригодность к числоблудию (очень маленькая величина)) / (пригодность,напр. к парсингу текста (ровно 0)). Получается конечная величина, делённая на ноль, откуда и все выводы про отполированность.

бенчмарки не делал, ниче не знаю. Вообще, еще говорят о том, что аналогов фортрановых либ на сях нету, но я им не особо верю :/

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

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

Поэтому, если написать с нуля тоже самое на любом современном ЯП, то получится лучше (быстрее, компактней, надёжней, и др.) абсолютно по всем показателям.

Ты сначала найди, кто тебе за это заплатит...

Хотя, конечно, можешь продолжать переписывать всё и вся, так сказать, for fun :)

ну а что плохого в переписывании?

А что плохого в неуловимом Джо?

пардонте, но мне не понятна ваша аналогия. еще варианты есть?

массово переписывать код ни кто не будет: тех, у кого он уже работает, устраивают затраты на его поддержание, но не устраивают затраты на его переписывание. А for fun переписывается только всякая мелочь, которой интересно заниматься... Так что плохого в переписывании ничего нет, просто самого переписывания нет и не предвидится...