Потому что есть огромная разница между оптимизацией производительности и полным отключением безопасности
Благодаря уменьшению количества сборщиков мусора их структура становится более отзывчивой и может работать (предположительно) быстрее. Теперь оптимизация для сборщика мусора не означает, что они никогда не собирают мусор. Это просто означает, что они делают это реже, и когда они делают это, они работают очень быстро. Эти виды оптимизации включают в себя:
- Минимизация количества объектов, которые перемещаются в пространство для выживших (то есть, которые пережили хотя бы одну сборку мусора) с помощью небольших одноразовых объектов. Объект, который переместился в пространство выживших, сложнее собрать, и сборка мусора здесь иногда приводит к зависанию всей JVM.
- Не выделяйте слишком много объектов для начала. Это может иметь неприятные последствия, если вы не будете осторожны, поскольку объекты молодого поколения очень дешевы в размещении и сборе.
- Убедитесь, что новый объект указывает на старый (а не наоборот), чтобы молодой объект можно было легко собрать, поскольку нет ссылок на них, которые могли бы его сохранить
Когда вы настраиваете производительность, вы обычно настраиваете очень специфическую «горячую точку», игнорируя код, который не часто запускается. Если вы сделаете это в Java, вы можете позволить сборщику мусора по-прежнему заботиться об этом темном углу (так как он не будет иметь большого значения), в то же время очень тщательно оптимизируя область, которая работает в узком цикле. Таким образом, вы можете выбрать, где вы оптимизируете, а где нет, и таким образом вы можете сосредоточить свои усилия там, где это важно.
Теперь, если вы полностью отключите сборку мусора, вы не сможете выбрать. Вы должны вручную избавиться от каждого объекта, когда-либо. Этот метод вызывается не чаще одного раза в день? В Java вы можете позволить этому быть, так как его влияние на производительность незначительно (может быть, допустимо, чтобы полный GC происходил каждый месяц). В C ++ у вас все еще утечка ресурсов, поэтому вы должны позаботиться даже об этом неясном методе Таким образом, вы должны заплатить цену за управление ресурсами в каждой отдельной части вашего приложения, в то время как в Java вы можете сосредоточиться.
Но это еще хуже.
Что если у вас есть ошибка, скажем, в темном углу вашего приложения, доступ к которой возможен только в понедельник в полнолуние? У Java есть сильная гарантия безопасности. Существует практически нет "неопределенного поведения". Если вы используете что-то неправильно, выдается исключение, ваша программа останавливается, и повреждение данных не происходит. Таким образом, вы уверены, что ничего плохого не произойдет, если вы не заметите.
Но в чем-то вроде D у вас может быть плохой доступ к указателю или переполнение буфера, и вы можете повредить вашу память, но ваша программа не будет знать (вы отключили безопасность, помните?) И продолжит работать с ее неправильным данные, и делать какие-то довольно неприятные вещи и портить ваши данные, и вы не знаете, и по мере того, как происходит все больше коррупции, ваши данные становятся все более и более неправильными, а затем внезапно ломаются, и это было в жизненно важном приложении, и некоторые ошибки произошли в вычислении ракеты, и поэтому он не работает, а ракеты взрываются, а кто - то умирает, и ваша компания находится в первой странице каждой газеты и ваша точка босс его палец к вам сказать «Вы находитесь инженер, который предложил использовать D для оптимизации производительности, почему вы не задумывались о безопасности?«И это твоя вина. Ты убил этих людей своей глупой попыткой выступить.
Хорошо, хорошо, в большинстве случаев это гораздо менее драматично, чем это. Но даже критически важные для бизнеса приложения или просто приложение GPS или, скажем, веб-сайт государственного здравоохранения могут привести к довольно негативным последствиям, если у вас есть ошибки. Использование языка, который либо полностью предотвращает их, либо быстро прекращает работу, когда они происходят, обычно очень хорошая идея.
Отключение безопасности стоит. Быть родным не всегда имеет смысл. Иногда гораздо проще и безопаснее просто немного оптимизировать безопасный язык, чтобы пойти ва-банк с языком, на котором вы можете застрелиться в ногу. Правильность и безопасность во многих случаях превосходят несколько наносекунд, которые вы могли бы списать, полностью исключив ГХ. Disruptor может быть использован в тех ситуациях, так что я думаю , что LMAX-биржа сделала правильный вызов.
Но как насчет D в частности? У вас есть GC, если вы хотите для темных углов, а подмножество SafeD (о котором я не знал до редактирования) удаляет неопределенное поведение (если вы не забываете его использовать!).
Ну, в таком случае это простой вопрос зрелости. Экосистема Java полна хорошо написанного инструмента и зрелых библиотек (лучше для разработки). Гораздо больше разработчиков знают Java, чем D (лучше для обслуживания). Переход на новый и не очень популярный язык для чего-то столь важного, как финансовое приложение, не был бы хорошей идеей. С менее известным языком, если у вас есть проблема, мало кто может вам помочь, и библиотеки, которые вы обнаружите, имеют тенденцию иметь больше ошибок, так как они были выставлены меньшему количеству людей.
Поэтому мое последнее замечание остается в силе: если вы хотите избежать проблем с тяжелыми последствиями, придерживайтесь безопасного выбора. На данный момент в жизни D его клиенты - маленькие стартапы, готовые пойти на сумасшедший риск. Если проблема может стоить миллионы, вам лучше оставаться в курсе инновационной кривой .