Массивы не живут в стандартной библиотеке, они встроены непосредственно в язык (а Phobos вообще беден на контейнеры в ожидании github.com/andralex/phobos/blob/allocator/std/allocator.d). Для встроенных массивов GC _необходим_ только для операции ~= (конкатенация). В целом же массив это просто указатель + длинна, а как выделена память — не критично. Обойти GC не так уж трудно, просто теряются гарантии по безопасности работы с памятью.
> Она ж ляжет все и полностью (ну почти...).
Большая часть std.algorithm, std.range и тому подобных модулей уже работают без аллокаций. Остальные модули понемногу вычищают — это долгий процесс.
Полностью отказаться от GC довольно трудно на нынешнем этапе, но для 99.99% приложений это и не нужно, достаточно держать количество мусора на минимуме.
> Эхх… если б не его не убиваемый GC (стандартные библиотеки без него не работают) — круто было бы.
Не совсем так — отдельные модули работают, отдельные нет. В грядущем релизе появятся две очень важные возможности для тех, кто старается избежать GC: флаг компилятора -vgc (печатает все места в модуле, которые выделяют память через GC) и новый атрибут @nogc , гарантирующий, что функция транзитивно не использует GC (ошибка компиляции в противном случае).
> Кстати, а D может в C скомпилироваться, чтоб его к живому проекту приаттачить?
Все проекты по трансляции D в C загнулись, потому что слишком мало кому нужно. Для использования в живом проекте это и не нужно — можно линковать напрямую через extern(C). Вот, например, отчёт об интеграции D с существующими библиотеками на C++ в Facebook: www.youtube.com/watch?v=1JZNvKhA3mA
Если я верно понимаю суть вопроса (уже изрядно подзабыл С++), то можно не указывать. В D было принято решение делать семантический анализ только после инстанциирования и нет грамматической неоднозначности между < > как операторами и как синтаксисом шаблонов.
Встраивание вместо наследования: traits в Rust (частично, проблемы с встраиванием переменных), template mixin + alias this в D (полностью)
Структурная типизация: traits в Rust (полностью), template constraints в D (частично, подмножество duck typing)
Мне кажется, что сообщество всех трёх языков вообще настолько сильно «в теме» дизайна языков программирования, что о новаторстве вообще трудно говорить применительно к отдельным фичам, только о сумме принятых решений.
Все эти три пункта в том или ином виде присутствуют во всех трёх нативных языках «новой волны» (Go / D / Rust), едва ли тут можно говорить о новаторстве :)
У этого термина есть очень много трактовок. Самая строгая — язык может считаться подходящим для системного программирования если позволяет прямой доступ к железу и на нём можно написать hard real-time OS. C / Rust / D этим критериям соответствуют, Go — нет.
Процитированное определение из вики довольно бесполезно, так как под него подходят чуть ли не все промышленные языки, оно описывает скорее намерения, чем формальные свойства.
Да, DIP54 ещё не закончен (я работаю над этим по мере свободного времени), пока что в «живых» проектах приходится выкручитываться на свой вкус. Я изначально говорил только об учёбных материалах, вводящих в заблуждение.
Нет, он очень даже жив. deadalnix выступал с презентацией на недавнем DConf: dconf.org/2014/talks/sechet.html + планируется в качестве одной из заявок на GSoC.
Видео с конференции правда придётся ждать долго, т.к. выступал он последним, а публикуют их по порядку :) Но архитектура намного более перспективная, чем жуткая каша в исходниках DMD.
Это дефект реализации CTFE, фундаментально тут никакой проблемы нет. Всего лишь исправление issues.dlang.org/show_bug.cgi?id=6498 уменьшит потребление памяти на порядок и больше.
Экспериментальный альтернативный front-end для D (https://github.com/deadalnix/SDC) использует LLVM JIT для CTFE и вообще не имеет таких проблем :)
Разбухание кода 1-5% разработчиков, которые активно использует метапрограммирование — терпимая цена за упрощение документации для всех остальных. Это я говорю как тот самый разработчик, чей код может разбухнуть :) В любом случае, имя Tuple уже используется стандартной библиотекой для std.typecons.Tuple, поэтому этот вариант вообще недопустим в обучающих материалах.
Кстати рекомендуемый короткий alias — List и Pack соответственно.
Макросы обсуждались ещё на первом DConf в (страшно представить!) 2007 году, с тех пор в языке существует ключево слово «macro», которое на практике не используется. Со временем было принято решение что генерация кода через CTFE/mixin — решение более универсальное и простое для изучения новичками, хотя и существенно уступающее в гигиене для более сложных проектов. На данный момент введение AST макросов не рассматривается, DIP50 — просто мысли одно из активных участников сообщества.
В целом макросы вещь важная и нужна, но не столь однозначно превосходящая CTFE/mixin, как может показаться. Преобразование существующего кода — да, тут вопросов не возникает. Но поддержка произвольных строковых DSL куда проще реализуется простым лексическим разбором этих самых DSL.
Лично мне в текущей системе не хватает аргументов-выражений (по аналогии с тем, как alias это аргумент-символ), это решило бы множество задач, где пригодились бы макросы.
Пожалуйста, не надо использовать термин Tuple (кортеж) для обозначения списка шаблонных аргументов в D. Это очень специфическая для языка сущность, с огромным количеством особенностей и заморочек, почти ничего общего с кортежами из других языков не имеющая. На дальнейшие объяснения «почему так, а не эдак» приходится тратить очень много времени.
Автоматическая генерация биндингов (plain C) возможна с помощью магической утилиты github.com/jacob-carlborg/dstep
Минусы: не будет идиоматической конвертации макросов
Плюсы: быстро, не нужно тратить время на поддержку
Мы используем dstep в «боевом» коде при сборке: .proto -> protobuf-compiler -> dstep, экономит много времени при изменении файлов .proto
Смелое начинание, книга у Али очень подробная и объёмная. Рекомендую держать весь переведённый материал перевода в каком-нибудь одном месте, чтобы потом его можно было легко оформить и добавить как один из официальных переводов.
Массивы не живут в стандартной библиотеке, они встроены непосредственно в язык (а Phobos вообще беден на контейнеры в ожидании github.com/andralex/phobos/blob/allocator/std/allocator.d). Для встроенных массивов GC _необходим_ только для операции ~= (конкатенация). В целом же массив это просто указатель + длинна, а как выделена память — не критично. Обойти GC не так уж трудно, просто теряются гарантии по безопасности работы с памятью.
> Она ж ляжет все и полностью (ну почти...).
Большая часть std.algorithm, std.range и тому подобных модулей уже работают без аллокаций. Остальные модули понемногу вычищают — это долгий процесс.
Полностью отказаться от GC довольно трудно на нынешнем этапе, но для 99.99% приложений это и не нужно, достаточно держать количество мусора на минимуме.
Не совсем так — отдельные модули работают, отдельные нет. В грядущем релизе появятся две очень важные возможности для тех, кто старается избежать GC: флаг компилятора
-vgc(печатает все места в модуле, которые выделяют память через GC) и новый атрибут@nogc, гарантирующий, что функция транзитивно не использует GC (ошибка компиляции в противном случае).> Кстати, а D может в C скомпилироваться, чтоб его к живому проекту приаттачить?
Все проекты по трансляции D в C загнулись, потому что слишком мало кому нужно. Для использования в живом проекте это и не нужно — можно линковать напрямую через
extern(C). Вот, например, отчёт об интеграции D с существующими библиотеками на C++ в Facebook: www.youtube.com/watch?v=1JZNvKhA3mAСтруктурная типизация: traits в Rust (полностью), template constraints в D (частично, подмножество duck typing)
Мне кажется, что сообщество всех трёх языков вообще настолько сильно «в теме» дизайна языков программирования, что о новаторстве вообще трудно говорить применительно к отдельным фичам, только о сумме принятых решений.
Процитированное определение из вики довольно бесполезно, так как под него подходят чуть ли не все промышленные языки, оно описывает скорее намерения, чем формальные свойства.
эквивалентно
… просто более короткая форма. То же самое и для enum.
Видео с конференции правда придётся ждать долго, т.к. выступал он последним, а публикуют их по порядку :) Но архитектура намного более перспективная, чем жуткая каша в исходниках DMD.
Экспериментальный альтернативный front-end для D (https://github.com/deadalnix/SDC) использует LLVM JIT для CTFE и вообще не имеет таких проблем :)
Кстати рекомендуемый короткий alias — List и Pack соответственно.
В целом макросы вещь важная и нужна, но не столь однозначно превосходящая CTFE/mixin, как может показаться. Преобразование существующего кода — да, тут вопросов не возникает. Но поддержка произвольных строковых DSL куда проще реализуется простым лексическим разбором этих самых DSL.
Лично мне в текущей системе не хватает аргументов-выражений (по аналогии с тем, как alias это аргумент-символ), это решило бы множество задач, где пригодились бы макросы.
Пожалуйста, не надо использовать термин Tuple (кортеж) для обозначения списка шаблонных аргументов в D. Это очень специфическая для языка сущность, с огромным количеством особенностей и заморочек, почти ничего общего с кортежами из других языков не имеющая. На дальнейшие объяснения «почему так, а не эдак» приходится тратить очень много времени.
Ссылка по теме: wiki.dlang.org/DIP54
Готовлю длинный цикл статей о vibe.d, в том числе с объяснением деталей реализации (я автор некоторых модулей). Но жизнь всё отвлекает и отвлекает :)
Минусы: не будет идиоматической конвертации макросов
Плюсы: быстро, не нужно тратить время на поддержку
Мы используем dstep в «боевом» коде при сборке: .proto -> protobuf-compiler -> dstep, экономит много времени при изменении файлов .proto