LINUX.ORG.RU

Язык D включен в коллекцию компиляторов GNU (gcc 9)

 


3

7

GCC 9.1 будет первым стабильным релизом с поддержкой GDC.

Его выход ожидается приблизительно в конце первого квартала 2019 г.

Код для поддержки GDC включает библиотеку libphobos (D run-time library) и фреймворк для тестов D2.

Поддержка D потребовала внесения изменений в приблизительно 1 миллион строк кода.

>>> Подробности



Проверено: jollheef ()
Ответ на: комментарий от eao197

как пример удобного, практичного, нативного языка с GC — D очень хорош. Всяко лучше популярного нонче Go.

И в чём же конкретно он лучше чем Go? Вот недостаток я к примеру могу назвать: неотзывчивый сборщик мусора. В Go субмиллисекундные паузы, поэтому он например неплохо подходит для геймдева, по крайней мере любительского. В реализациях Ди же паузы слишком долгие — пришлось бы терпеть неприятные пролагивания (как в Майнкрафте при -XX:+UseParallelGC, а может даже хуже).

anonymous ()
Ответ на: комментарий от yetanother

Я не могу понять, почему в плюсы не могут завести рефлексию?

в результате получится требование тащить в плюсовый бинарник такой-же рантайм, как у D?

C++ высокооптимальный (сравнительно) код. D — приятный и очень быстрый в разработке, но не настолько высооптимальный, как у плюсов. Имхо, так :)

glebiao ()
Ответ на: комментарий от Gentooshnik

Вышел C++11, и фичи D стали уже не настолько киллер.

имхо, разные ниши.

C++ — результат максимально приближен к высокооптимальному низкоуровневому коду.

D — фокус на быстроте и лёгкости разработки при сохранении *достаточной* оптимальности кода. Считайте, что это такой компилируемый Питон.

И да, Раст тут вообще перепендикулярен, совершенно другие цели и ниша.

Осилил в конце концов Common Lisp

причём тут это?

glebiao ()
Ответ на: комментарий от vertexua

Как в D с экосистемой пакетов? Например как вам собираемость и надежность того что есть в dub?

при таком числе пакетов, которые сейчас на слуху, это вряд ли имеет большое значение.

как репозиторий вырастет (а с включением в gcc надежда появляется :) — посмотрим

glebiao ()
Ответ на: комментарий от devzero

Насколько я понял, методы по умолчанию виртуальные, невиртуальных не предусмотрено?

в D разделение между структурами (все методы невиртуальные) и классами (наследование в полный рост и => методы)

Как интероперабельность с си и крестами? Насколько больно вызывать сишный код из дишного и наоборот?

С Си — полная. вызов в обе стороны не имеет трудностей (хотя есть тонкие места).

С плюсами сравнительно плохо. Прямой совместимости (в стандартных компиляторах, на сегодня) нет. Возможны биндинги. Появился ещё один подход, основанный на препроцессоре.

Раздельная компиляция модулей возможна?

всегда раздельна.

glebiao ()
Ответ на: комментарий от dimgel

Во что они его компиляют — ортогонально; внутри бинарника останется и GC, и рефлексия, и тормоза по сравнению с плюсами.

Я думаю, вы не понимаете о чем вам говорят. Сейчас явно наблюдается тенденция интереса к безопасным языкам с GC, но транслирующимся в нативный код. Поскольку дополнительные прослойки в виде JVM или MSIL — это уже пройденный этап.

Насколько при этом Go, Kotlin/Native или D будет проигрывать в чистой производительности C++ или Rust-е мало кого интересует. Т.к. в скорости разработки все равно будет существенный выигрыш.

eao197 ★★★★★ ()
Ответ на: комментарий от SR_team

Хочешь, я тебе буду жаловаться, про то как не удобно расширять функционал существующих классов без множественного наследования?

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

кроме того, в D есть такое волшебное заклинание «alias this», на нём очень многое навешивается :)

glebiao ()
Ответ на: комментарий от glebiao

Я был уверен, что D-шный рантайм тащит с собой только аналог C++ного RTTI. И в этом плане расходы в run-time будут сравнимы.

И что D-шная рефлексия достигается за счет метапрограммирования в compile-time. И что в run-time в D нет возможности, скажем, получить список методов класса и дернуть какой-нибудь метод, скормив ему вектор с аргументами (как в Java, например).

Но я уже лет 10 на D не программировал, пусть действующие разработчики внесут ясность.

eao197 ★★★★★ ()
Ответ на: комментарий от RazrFalcon

Как минимум сейчас я не вижу причин использовать его вместо Rust.

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

yetanother ()
Ответ на: комментарий от glebiao

в результате получится требование тащить в плюсовый бинарник такой-же рантайм, как у D?

Откуда такое требование? Рефлексия времени компиляции.

C++ высокооптимальный (сравнительно) код. D — приятный и очень быстрый в разработке, но не настолько высооптимальный, как у плюсов. Имхо, так :)

Ди ровно настолько же высокооптимальный.

yetanother ()
Ответ на: комментарий от glebiao

С плюсами сравнительно плохо. Прямой совместимости (в стандартных компиляторах, на сегодня) нет. Возможны биндинги. Появился ещё один подход, основанный на препроцессоре.

Прямая совместимость как раз есть, но она хуже в сравнении с Си.

yetanother ()
Ответ на: комментарий от glebiao

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

Нет, не тащит в рантайм абсолютно ничего. Рефлексии времени выполнения в D очень мало. Я ее никогда не использовал, кстати.

yetanother ()
Ответ на: комментарий от eao197

Я был уверен, что D-шный рантайм тащит с собой только аналог C++ного RTTI. И в этом плане расходы в run-time будут сравнимы.

И что D-шная рефлексия достигается за счет метапрограммирования в compile-time. И что в run-time в D нет возможности, скажем, получить список методов класса и дернуть какой-нибудь метод, скормив ему вектор с аргументами (как в Java, например).

Но я уже лет 10 на D не программировал, пусть действующие разработчики внесут ясность.

Все правильно.

yetanother ()
Ответ на: комментарий от SR_team

Костыль. На сколько я понимаю изначально придуманный для структур, когда ВНЕЗАПНО оказалось, что людям нужно наследование в структурах.

Ну насчет костыля я не уверен. Это просто другой механизм наследования для типов-значений. Он просто непривычен. Тут только практика покажет.

yetanother ()
Ответ на: комментарий от yetanother

В Dlang tour оно подается как замена наследованию для расширения функционала классов, структур и обычных типов. Учитывая, что в D есть UFCS, это выглядит именно как костыль для замены наследования.

SR_team ★★ ()
Ответ на: комментарий от SR_team

Не, UFCS никак не заменяет alias this полностью. Если мне нужно добавить функциональность в виде нового метода, да, хватит UFCS. А если мне нужно данные добавить в тип, то уже UFCS не справится. Так что никак тут не костыль alias this. Они частично лишь пересекаются - UFCS и alia this.

yetanother ()
Ответ на: комментарий от dimgel

В D интерфейсах можно реализовывать не виртуальные и статические функции https://dlang.org/spec/interface.html Плюс есть такая вещь «Template Mixins» https://dlang.org/spec/template-mixin.html которая позволяет вставлять практически произвольные куски кода в нужные места. В общем большую часть того для чего нужно множественное наследование эти вещи покрывают. А миксины по моему даже и мощнее в плане повторного использования чем множественное наследование.

anonymous ()
Ответ на: комментарий от dimgel

Создатель D не любит AST макросы. Но при этом сдуру наверно умудрился добавить в D вещь почти не уступающую по мощи AST макросам, строковые миксины https://dlang.org/articles/mixin.html Конечно это не сравнить по удобству с AST макросами с квазицитированием, но на практике пусть и через одно место позволяет делать на D вполне нормальные встроенные DSL

import pegged.grammar;

mixin(grammar(`
Arithmetic:
    Term     < Factor (Add / Sub)*
    Add      < "+" Factor
    Sub      < "-" Factor
    Factor   < Primary (Mul / Div)*
    Mul      < "*" Primary
    Div      < "/" Primary
    Primary  < Parens / Neg / Pos / Number / Variable
    Parens   < "(" Term ")"
    Neg      < "-" Primary
    Pos      < "+" Primary
    Number   < ~([0-9]+)

    Variable <- identifier
`));

anonymous ()
Ответ на: комментарий от anonymous

Создатель D не любит AST макросы. Но при этом сдуру наверно умудрился добавить в D вещь почти не уступающую по мощи AST макросам, строковые миксины

Ну почему сдуру. Это его явная позиция, что на миксинах можно сделать многое, если не все что и на AST макросах, при этом миксины безопаснее. Логика у него есть, потому что далеко не все люди умеют обращаться со свободой. Кто-то получив полную свободу действий напишет свою Мону Лизу. Но таких будет мало. Заметно больше народа пойдёт пихать вилку в розетку и смотреть что получится. А еще многие тупо нажрутся в хлам и будут лежать бесформенной кучей. Внутренняя диспциплина это не всем дано.

Только уточню что не все миксины строковые. Есть просто миксины, строковые миксины и шаблонные миксины. И pegged да, мощная вещь.

yetanother ()
Ответ на: комментарий от yetanother

Если мне склероз не изменяет, то сразу как только появились строковые миксины он плакался в форуме что их не нужно использовать для встроенных DSL.

anonymous ()
Ответ на: комментарий от yetanother

при этом миксины безопаснее

Не скажу на счет безопаснее, но когда строковые mixin-ы появились да еще в купе с CTFE, то выяснилось, что парсинг DSL-ей и генерацию новых текстов для последующего включения через mixin, оказалось довольно таки просто отлаживать. Чуть ли не покрывая обычными юнит-тестами. ИМХО, на AST-макросах отлаживать сложные кодогенерирующие DSL-и было бы сложнее.

eao197 ★★★★★ ()
Ответ на: комментарий от yetanother

Хм, а "...ошибки должны отлавливаться юнит-тестами"?

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

AlexM ★★★★★ ()
Ответ на: комментарий от anonymous

Если мне склероз не изменяет, то сразу как только появились строковые миксины он плакался в форуме что их не нужно использовать для встроенных DSL.

Тут ничего не скажу. Уолтер периодически тоже ошибается. Последнее что помню это манглинг для работы с плюсами. Люди просили сделать возможность напрямую в виде строки задавать неймспейс для плюсового символа, а он настаивал на том, что неймспейсы нужно моделировать с помощью модулей. Он был категорически против пока в один момент внезапно не принял PR который добавлял манглинг в виде строки. Именно внезапно. Все мы люди.

yetanother ()
Ответ на: комментарий от eao197

Не скажу на счет безопаснее, но когда строковые mixin-ы появились да еще в купе с CTFE, то выяснилось, что парсинг DSL-ей и генерацию новых текстов для последующего включения через mixin, оказалось довольно таки просто отлаживать.

Ну я бы не сказал что миксины просто отлаживать. Банально в отладчике сейчас нельзя зайти внутрь миксина. Довольно неудобно. Сейчас создан PR который добавляет возможность делать это путем генерации миксина в строковом виде в отдельный файл. Так что там есть куда расти.

Чуть ли не покрывая обычными юнит-тестами. ИМХО, на AST-макросах отлаживать сложные кодогенерирующие DSL-и было бы сложнее.

C AST макросами не работал, мнения по этому поводу не имею.

yetanother ()
Ответ на: комментарий от AlexM

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

Согласен конечно. Но позиция автора языка что отлавливание таких ошибок должно быть в отдельном инструменте реализовано, а не в компиляторе. Чтобы не тормозило как в Расте. Быстрая компиляция это действительно удобно.

yetanother ()
Ответ на: комментарий от yetanother

Ну я бы не сказал что миксины просто отлаживать. Банально в отладчике сейчас нельзя зайти внутрь миксина.

А мы точно об одном и том же говорим?

mixin(some_ctfe_function(str_input))
Здесь some_ctfe_function — это обычная функция, которая берет строку на вход и выдает строку на выходе. Вы можете отлаживать эту функцию и покрывать ее unit-тестами сколько угодно вне конструкции mixin.

eao197 ★★★★★ ()