в сфере интерфейсов для 3D наоборот

dx? opengl?

OpenGL 2.* был очень высокоуровневым. OpenGL 3-4 требует куда больше низкоуровневых действий. Vulkan, говорят, представляет по сути унифицированный интерфейс к GPU.

Производительность железа. Последняя такова, что в прикладном программировании способна переварить высокоуровневый говнокод, с приемлемыми тормозами. Зато программировать может каждая кухарка, не заботясь об освобождении памяти и прочих презренных вещах, о которых и понятия не имеет. А в 3D подобный подход не прокатывает, всё сразу начинает дико лагать, и это, блин, очевидно! Так что в будущем, когда прогресс полупроводников встанет, С++ триумфально вернётся.

В чем, на ваш взгляд, разница между этими сферами, что движутся они в диаметрально противоположные стороны?

Как раз движутся в одну сторону: кому нужна производительность - пишет на низкоуровневом вулкане, кому нужна скорость и простота - берёт OpenGL или обёртку над тем же Вулканом.

а C/C++ постепенно отходят в сторону, оставаясь там, где им пока нет внятной альтернативы.

т.е. везде

а также сложнее выстрелить себе в ногу.

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

не заботясь об освобождении памяти и прочих презренных вещах

Какой язык умеет закрывать/освобождать ресурсы автоматически, когда они больше не нужны? :) Например закрывать файл при выходе из скоупа.

Какой язык умеет закрывать/освобождать ресурсы автоматически, когда они больше не нужны? :) Например закрывать файл при выходе из скоупа.

C

Бидон?

С каких пор в C появились деструкторы?

С каких пор в C появились деструкторы?

Тьфу, я прочитал исходный пост как «какой язык _НЕ_ умеет».

Каждой задаче свой инструмент.

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

В одном направлении они движутся: чтобы было быстрее.

Плюсую. Но в случае приложений - чтоб быстрее писать, а в случае дров - чтоб быстрее работать

C++, Objective-C, Swift.

Так что в будущем, когда прогресс полупроводников встанет...

В массы пойдут квантовые компьютеры.

В gcc-лайках работают cleanup-ы, в стандарте их естественно нет.

http://stackoverflow.com/questions/1828550/portable-equivalent-to-gccs-attrib...

Всё очевидно. Прикладной программист не имеет дело ни с OpenGL, ни с DirectX, ни с Vulkan, ни с им подобными API. С ними имеют дело разработчики движков, иных часто используемых библиотек (SDL, Qt) и эти ребята совершенствуют свои библиотеки в сторону скорости работы, им чем ниже уровень API тем лучше.

А прикладные программисты уже имеют дело с высокоуровневым API, и движки с ЯП им его обеспечивают.

А С/С++ в сторону не отходят. На С как писали 30 лет назад драйвера, ядра ОС, системные библиотеки и утилиты так и продолжают писать, никто его пока не потеснил.

На С++ как писали 30 лет назад всё, что выдаёт на экран более 2-х кнопок, так и продолжают. Под кроссплатформу ему нет вменяемых альтернатив.

Если пишем под один компилятор - да. Вон у MSVC есть даже проверка валидности указателя, толку только.

А кто такие «прикладные программисты»? Те кто пишут прикладное ПО? А всякие движки, числодробилки, игори, фотошопы это уже стало системным ПО? С каких пор?

числодробилки, игори, фотошопы

это прикладное ПО, которое непосредственно удовлетворяет цели пользователей

движки

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

в данном случае, провёл такое разделение

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

Отличная аналитика

кому нужна скорость и простота - берёт OpenGL
простота
OpenGL

Вы - возможно да. Я - нет.

Варнинги, за редкими исключениями, надо исправлять а не подавлять

А сколько твоих рабочих проектов/модулей и под сколькими компиляторами собираются без выхлопа? Имеется ввиду рабочий код, не домашние хелворды на -pedantic. И цифры не «потенциальные», пожалуйста, а фактические.