История изменений

Исправление yetanother, 15.01.20 15:42 (текущая версия) :

Я вообще не понимаю жалоб на сборщик мусора. Если вы беспорядочно выделяете память, то у вас тормозить будет и при ручном выделении памяти. А если вы в главном цикле (если взять игру) память не выделяете, то с чего вдруг сборщику начинать эту самую сборку? В D сборщик начнет сборку только если памяти ему не хватает. А если вы память заранее выделили и в главном цикле уже не выделяете на куче ничего, то сборщик мусора у вас и не запустится. Тем более вы можете принудительно отключать сборщик мусора в критических местах.

Если мне не изменяет склероз, то раньше на GC были завязаны такие фичи языка, как делегаты (т.е. лямбды) и исключения.

Замыкания завязаны на сборщик мусора, делегаты нет:

import std;

void main() @nogc
{   
    // delegate declaration
    void delegate() @nogc dg;
    // delegate definition
    dg = () {
        printf("@nogc delegate has been called\n");
    };
    // the delegate call
    dg();
}

Запустить код можно тут https://godbolt.org/z/oy4K-9 output:

@nogc delegate has been called

Исключения уже не завязаны, но это только недавно было добавлено и пока по умолчанию не включено. Нужен дополнительная опция для компилятора dip1008:

import std;

void main() @nogc
{    
    throw new Exception("I'm @nogc now");
}

output:

object.Exception@./example.d(5): I'm @nogc now
----------------
??:? [0x55693b9ce5a5]
??:? [0x55693b9da43a]
??:? [0x55693b9c2d6d]
example.d:5 [0x55693b98e219]
??:? [0x55693b9c29ef]
??:? [0x55693b9c28de]
??:? [0x55693b9c273d]
__entrypoint.d:8 [0x55693b98e3b4]
??:? __libc_start_main [0x7fbe60695b96]
??:? [0x55693b98e0c9]

Запустить код можно тут https://godbolt.org/z/tp3tsH

Кроме того, не знаю как сейчас, а раньше в stdlib D вроде как не было понятия аллокаторов и контейнеры были расчитаны на то, что будет использоваться GC.

Есть такое. На этот случай народ давно разработал пакет emsi_containers. Контейнеры в нем поддерживают аллокаторы. Несмотря на версию пакета он используется очень широко. На нем решили обкатать перед включением контейнеров в стандартную либу.

Кроме того, при наличии GC я мог создать некий immutable объект и не парится о его времени жизни: можно было свободно передавать ссылки на этот immutable объект везде, где ожидались const или immutable ссылки. Что делало разработку каких-то вещей на D гораздо проще, чем на С++.

Так, а в чем проблема? Создавайте со сборщиком и используйте. Не хотите использовать сборщик - мучайтесь вручную, также как и в плюсах. Тут уж либо крестик спрячьте, либо трусы наденьте.

Если теперь мне говорят, что все это идет лесом и D может приняться там же, где и C++ с Rust-ом, то возникает резонный вопрос: а в чем преимущества D в таком случае?

Почему это идет лесом-то, я не пойму?

Ну может быть. Только вот у D есть один актуальный компилятор непонятного качества и непонятной доступности на различных платформах. А компиляторы на базе GCC и LLVM сильно отстают в поддержке.

У D есть три компилятора:

референсный dmd используется для разработки из-за быстроты компиляции и все новые фичи в начале появляются в нем. У него количество платформ только две - x86 и amd64. Качество кода не очень.

gdc на базе gcc имеет лучшую поддержку платформ/архитектур и качество кода, но из-за необходимости слияния с основной веткой gcc он отстает от dmd и значительно. Этот момент хорошо известен и он временный. Когда мейнтейнер gcc завершит процесс gdc догонит dmd.

ldc на базе llvm также имеет лучшую поддержку платформ/архитектур и качество кода и практически не отстает от dmd. По факту это наилучший компилятор для D и поддерживает чуть ли не все последние писки из этой области типа lto, сборку под GPGPU, webassebly и пр. Я там не особо слежу. Также на базе ldc есть проект calypso который позволяет в одном проекте писать и на плюсах и на D - т.е. в дишный код можно импортировать плюсовые заголовочники, использовать тот же Qt.

Те ссылки выше, что я привел на код с делегатом и исключением, они как раз собраны с помощью ldc, ldc практически не отстает от dmd на сегодня. Уверен, что и gdc подтянется.

Количество сторонних разработок на D мизерно по сравнению с C++. Качество большинства из них непонятно.

Это естественно. И большинство разработок не очень высокого качества - так везде. Более того, наиболее качественные разработки они закрыты. Поэтому в языке развиваются средства взаимодействия с другими языками. Есть поддержка С (100%), С++ (не 100%, но шаблоны поддерживаются, например), python, R, julia вроде бы. Последнее время активно пилится поддержка Java - вызов из дишного кода кода на Java и наоборот.

Удовольствие делать на D обертки к C-шным либам то еще.

Это странное утверждение. С самого начала D поддерживал C 100%. Писать обертки к сишному коду в D это очень элементарно. Но даже этого не надо есть, есть два инструмента dstep и dpp которые автоматизируют написание биндингов к C/Obj-C и плюс частичная поддержка плюсов. dpp вообще позволяет импортировать сишные заголовочники в дишный код и в отличие от calypso он попроще, но и поддерживает не только ldc.

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

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

Нет уж. Если D без GC, то в современных условиях проще и дешевле (а то и перспективнее) выбирать C++ и Rust. Особенно Rust. Тут на хайпе по крайней мере можно что-то ловить.

Да уж, всем не угодить. Одни ругают сборщик мусора, другие без него не хотят работать. Никто не будет убирать GC из D, просто уменьшается количество фич, которые от него зависят. Так что если он вам не нужен - не используйте его. Хотите сборщик мусора - пожалуйста. У вас может быть часть кода написана в @nogc, а часть - с сборщиком мусора. Язык это поддерживает.

Исходная версия yetanother, 15.01.20 15:40: