Есть что-то лучше C++?

Это да. Но некоторые уже там, а некоторые будут там раньше других.

low latency traiding системы

C++ в этой сфере это уже давно не лоу лейтенси. С такими требованиями по скорости можно и на java писать.

биллинг

А здесь зачем плюсы?

Go - потому что это тру. в отличии от.

нивелировать эту доп. сложность используя специальную IDE

Как это? Есть вот простая закономерность: если кодер не понимает рекурсию (и указатели в запущенных случаях), никакие костыли ему не помогут в работе с более-менее сложными структурами. Будет говнокодить, без вариантов. Так и с умными указателями, передачей владения, RAII и т.п. Надо ясно понимать что там происходит внизу, иначе беда. Ну с растом то хорошо, говнокод даже не скомпилируется (правда на этом путь в индустрию и закончится, хехе).

C++ в этой сфере это уже давно не лоу лейтенси. С такими требованиями по скорости можно и на java писать.

Жир с экрана потек!

Это да. Но некоторые уже там, а некоторые будут там раньше других.

Если брать smalltalk, который особо живым никогда и не был, то можно и в ed код фигачить, но с его (smalltalk'а) всеобъемлющей интроспекцией и горячей заменой кода логично использовать среду типа squeak, которая всё это умеет.

С лиспами то же самое: SLIME настолько хорош, что не использовать его по религиозным причинам просто лишено смысла.

SLIME

Там вой начинается: «Мы не осьминоги!», - а мне нравится. И кложуровский CIDER тоже. Жалко, что для Racket подобной штуки нет, даже немного уныло как-то кодить из-за этого.

Ракетка вообще своего названия не оправдывает. Тому же SBCL в скорости проигрывает на порядок.

Go - потому что это тру. в отличии от.

аргумент 80 левела.

«Ракетка» это Racket, а не Rocket.

Очевидно, зависит от задачи. Например, C++ не очень хорошо подходит для разработки веб-приложений (я про серверную часть), ибо слишком легко допустить какую-нибудь утечку памяти или переполнение буфера. Там лучше себя показывает Python, Java и JavaScript.

Или, например, C++ имеет меньшую скорость разработки, чем опять же какой-нибудь Python.

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

Справедливости ради, к Qt (а что ещё ты собрался на C++ использовать для нормального кроссплатформенного гуя?) есть биндинги для кучи других языков (тот же Python, например).

Не очень понятно, чем плох GC.

Как минимум:

1) Приводит к переиспользованию ресурсов. Допустим, я выделил массив на пару гигов в ОЗУ, поработал с ним и больше он мне не нужен. В C++ я могу сразу же сделать delete, в Java массив будет неопределённое время висеть в памяти. А может мне ОЗУ теперь нужно на новый массив?

2) В зависимости от реализации может приводить к остановке исполнения приложения на время сборки мусора.

Для каких-то задач это не критично, для каких-то критично. Соответственно, язык без GC (или с возможностью его отключения) обязательно нужен.

При желании GC можно прикрутить к любому языку с ручным управлением памятью. Просто допиливаешь в том же C++ smart_ptr, чтобы вместо delete при обнулении счётчика объект ставился в очередь на удаление. Плюс дорабатываешь логику для обработки циклических ссылок. В конце-концов в Java то GC как-то реализован.

есть, да, протухшие версии и с нулевым коммьюнити на stackoverflow

в итоге, от этой «кучи других языков» остаётся 1 богомерзкий питон

И чем плох питон + Qt, если надо по-быстрому сваять гуй с логикой не требующей высокой производительности? Скорость разработки приложения будет очень высокой, шансы получить какую-нибудь утечку памяти или сегфолт из-за кривых рук - минимальные. Так что вполне себе альтернатива C++ для кроссплатформенного гуя на ряде задач. Конечно же, если задача запилить что-то высокопроизводительное или залезть поглубже в потроха системы, то питон уже подходит хуже. Но речь шла не об этом.

Просто допиливаешь в том же C++ smart_ptr, чтобы вместо delete при обнулении счётчика объект ставился в очередь на удаление.

В этом случае деструктор будет срабатывать не когда удалили последний smart_ptr на объект, а когда очередь дойдет, что меняет логику работы. Это я к тому, что GC приделать к C++ можно, но осторожно, и только где надо.

Суть GC в том, что деструкторы не нужны (посмотри на Java и Python, в первом деструкторов нет вообще, во втором как бы есть, но они не особо используются и нужны скорее для отладки или каких-то специфичных вещей). А ещё в том, что освобождение памяти из-под сложной структуры может быть очень длительной операцией (ведь уничтожение одного объекта может привести к цепной реакции в результате которой окажутся без ссылок тысячи объектов и их надо будет тоже уничтожить). Соответственно, за этим и нужна очередь приговорённых к уничтожению объектов - чтобы уничтожать их в отдельном потоке, либо в свободное время, а не тормозить текущую задачу.

Конечно можно, вопрос только не будет ли такое поделие тормозить? Нужно учесть, что джава код пишешь не думая о том, как эффективнее утилизировать объекты и какую фрагментацию они создадут. Поэтому рассматриваю пока способ конвертить джаву в asm.js код.

посмотри на Java и Python, в первом деструкторов нет вообще

посмотрел. в первом есть корявые деструкторы.

А может мне ОЗУ теперь нужно на новый массив?

Если памяти не хватит - очевидно, запустится GC.

В конце-концов в Java то GC как-то реализован.

Посмотри как, чтобы не говорить глупостей про «Просто допиливаешь в том же C++...». К тому же смысл GC не в отложенном удалении, оно просто следствие принятого подхода.

посмотри на Java и Python, в первом деструкторов нет вообще, во втором как бы есть

Там и там суть одинаковые финализаторы.

что меняет логику работы

Если выбрал shared_ptr - ты уже не связываешь логику работы с временем вызова деструктора.