Зачем писать на языке, который является просто полигоном для обкатки фич для новых стандартов C++?

Быстро вы соскочили. Начинали же со спецификации.

сразу назову без спецификации :)

питон

https://docs.python.org/3/reference/index.html

https://docs.python.org/3/reference/introduction.html#alternate-implementations

А зачем использовать boost?

stackless недостаточно alternate? ну технически он форк cpython конечно

незачем, вот и не пиши (а я буду — удобно говна набросать)

Это не стандарт.

Вот это стандарт: https://www.ecma-international.org/publications/standards/Ecma-334.htm

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

Хана языку.

С чего это? Я бы понял, если бы новость звучала «компилятор языка D передан в Apache Foundation».

Не увиливай. Я начал одновременно с этих двух вещей, а вторая невозможна без первой.

у него есть сторонние реализации на основе python language reference (считай это спецификацией)

Никто не спрашивал стандарте, это было бы слишком прекрасно, но у rust мы этого не увидим, в ближайшие лет 10.

Всё, что не ISO — не стандарт.

мать вашу, нужны вам GC и рефлексия — пичешите на жаву

Неистово плюсую ++

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

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

Наконец-то!

Причем здесь язык?

статика. libphobos слинковано статикой. слинкуйте динамически, будет примерно в 5 раз меньше

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А разве у D run-time рефлексия, а не compile-time рефлексия?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

alias this

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

Язык D подключён к аппарату искусственной вентиляции лёгких GNU (gcc 9)

Я поправил. Желаю пациенту скорейшей кончины.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Создатель 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
`));

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

mixin(some_ctfe_function(str_input))

А, да, мы немного о разных вещах говорим. Вы про отладку в компайл-тайме, а я про отладку в ран-тайме.

Не скажу на счет безопаснее...

Я вспомнил, что он имел в виду под безопасностью - AST макросы позволяют изменить синтаксис языка. А миксины этого не позволяют.