Dlang VS Rust

Они учат меня формулировать доступные людям логики.

Или ученик тупой, или система не та, но результаты учебы так себе.

Это хорошо. Потому что срач на форуме, имхо, никогда не ведет к чему-то конструктивному. Одно дело, когда пытаешься разобраться в техническом тексте и тратишь время пытаясь разобраться с мыслью автора. И другое, когда ты пытаешься разобраться в техническом тексте, разбавленном срачем - тут уже проще бросить этот текст вообще.

Хайп нужен, чтобы о тебе узнали. Иначе так и останешься в подвале с двумя единомышленниками. После набора критической массы пользователей хайп уже больше вредит, соглашусь. К счастью, хайпожоры очень быстро переключаются на новое, и вот после очищения от них проект становится зрелым. D уже древний, но так и не созрел, потому что стадию хайпа не прошел.

Я просто различаю популяризацию и хайп. Дальнейшему росту популярности D в свое время помешал переход на D2. D1 был популярен и его популярность росла, так как на тот момент он действительно сильно отличался от остальных языков. Но резкий переход на D2 оттолкнул многих пользователей. Теперь урок извлекли. Что получится - увидим. Активно использую язык уже лет 8, если не больше. И все это время язык развивается, экосистема тоже, темпы не снижаются как минимум, так что я уже давно не переживаю за его будущее.

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

Это чем D1 сильно отличался от остальных языков? Что-то не могу вспомнить в нем ничего такого оригинального.

Вопрос справедливый, хотя и с подковыркой) Ну я не буду погружаться в ретроспективный анализ D1. Мое утверждение основано на том, что было довольно много комментариев на форумах, что с выходом С++11 переход на D снизил свою актуальность, т.е. до С++11 разница было очень большой - больше чем между С++11 и С++98.

D1 очень сильно отличался от C++03 в лучшую сторону (хотя многие из отличий обуславливались именно наличием GC и проверок в run-time). Но вот в сравнении с другими языками программирования в D1 было не так уж много чего-то нового и оригинального. Разве что работу с шаблонами они сделали более человеческой, чем в C++.

Принципиально другие вещи в D появились уже когда к его развитию Александреску подключился. В частности иммутабельность, которой императивные языки до сих пор не могут похвастаться. Но это уже D2.

Ок, про все языки я погорячился, имелись в виду С и С++ в первую очередь. Ну и Александреску собственно и привел косвенно к падению популярности D из-за внесенных им изменений. Хотя текущий D мне более симпатичен чем старый, Андрей как ни крути грамотный специалист.

Пытался сделать небольшое прикладное приложение для формирования отчетов на расте.

Учитывая что остальные языки - говно, то говно-раст не особо выделился из них. Но вот его нестабильность, требование одних крейтов стабильной ветки, других - ночной, и прочие пляски с бубном включая эквилибристику баланса safe и unsafe, совершенно не впечатлили меня углубляться в очередное говно. Переписал поделие в итоге на Qt.

Я бы с удовольствием применял бы вместо/помимо говно-с/c++ какой нибудь другой язык, если бы хоть в одном из них был бы вменяемый GUI и подключение нативного кода с маппингом объектов. Таких нет. А ведь это был верный маркетинг. Пишешь язык с ориентированием на GUI и набором gui-батареек и имплементируешь маппинг объектов для других языков. Профит.

Дело в том, что хайп привлекает также инициативных, но бестолковых людей.

Ну и что? Это уже вопрос к тому как язык развивается: новые фичи должны быть обоснованы, аккуратно обкатаны, а уже затем втащены в язык. Иначе ерунда и с «мотивированными людьми» случиться может, если они будут в разные стороны мотивированы.

Кстати, Александреску одной из проблем D называл как раз отсутствие хайпа (poor adoption).

Потому как никакое владение не имеет никакого отношения к системе типов, вообще. Никак через неё не выражается. Вообще.

регионы и линейные типы

полноценный CTFE с простым разумным синтаксисом

ещё, если про инфаструктуру – появился тот же стандартный dub пакетный менеджер, а не куча разных велосипедов. так что интегрироваться с стало проще.

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

Хайп в первую очередь способствует появлению рабочих мест. Если вам они не нужны, то можно и без хайпа конечно в секретной лаборатории что-то пилить по ночам. Впрочем, расту пока хайп тоже не слишком помог. Но там язык невменяемый, такому ничто не поможет.

У нас, видимо, разное понимание хайпа. Адекватный руководитель никогда не будет руководствоваться хайпом, имхо. Речь же идет об IT индустрии, а не об индустрии моды - там это как раз работает на ура.

Адекватный руководитель никогда не будет руководствоваться хайпом

Консервативный руководитель никогда не будет руководствоваться хайпом. Прогрессивный руководитель будет руководствоваться хайпом.

Можно «консервативный адекватный». Хотя «адекватный» здесь лишнее слово, не имеющее смысловой нагрузки.

Слово «адекватный» без упоминания модели не имеет смысла.

Кстати, Александреску одной из проблем D называл как раз отсутствие хайпа (poor adoption).

ИМХО, хайп – это волна завышенных ожиданий из категории «вот уж сейчас заживем».

Так было с хайпом вокруг Java, что вот сейчас-то уж можно будет написать один раз, а оно везде само заработает.

Так было с хайпом вокруг функционального программирования: вот сейчас-то уж багов в коде станет сильно меньше, а уж распараллеливание будет происходить и бесплатно, и безбажно, и само по себе.

Так было с хайпом вокруг Ruby-On-Rails. Мол, вот сейчас уж клепать Web-приложения можно будет одной левой.

Так сейчас с хайпом вокруг Rust, типа можно писать как на C++, но не на C++, и сразу все будет и мегабезопасно, и мегабыстро, и меганадежно.

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

Адекватный руководитель никогда не будет руководствоваться хайпом, имхо.

Там фанбои сплошь и рядом если речь о тимлидах. Но и менеджеры скорее выберут ту технологию, которая на слуху.

По поводу определения хайпа полностью согласен, у меня такое же мнение. А вот poor adoption я бы определил как малое распространение, а не невостребованность. Т.к. имеется в виду, что он малоизвестен массам, и поэтому они его не используеют, а не то, что его не используют, потому что продукт слабый. Ну и уже несколько лет D является более чем стабильным. Изменения есть, в том числе бывает и ломают обратную совместимость, но делают это очень аккуратно (так как обожглись уже) и обновление проектов проблем никаких не вызывает.

Достаточно посмотреть на веб: там табунами все перебегают от одной модной темы к другой. Никто не понимает зачем, просто в этом сезоне все носят розовое, и всё стадо в розовом, а чо делать.

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

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

А это взаимосвязано. Мало используют -> мало знают -> мало используют -> и т.д. по кругу.

Ну и уже несколько лет D является более чем стабильным.

Этому можно только порадоваться.

волна завышенных ожиданий из категории «вот уж сейчас заживем».

вот сейчас ребёнок сидеть научится и полегче станет; вот сейчас он ходить научится и полегче станет; сейчас начнёт в детский сад ходить и полегче будет; ну вот а школу отправим и …

примерно так же :)

А это взаимосвязано. Мало используют -> мало знают -> мало используют -> и т.д. по кругу.

А еще в круг добавляется - «А у вас же там сборщик мусора?» или еще хлеще - «Проблему с двумя стандартными либами решили?»

Так и живем)) И живем, кстати, хорошо.

Так про сборщик мусора-то актуально. Поэтому для меня лично D является конкурентом (потенциальной заменой) не C++ или Rust-а, а таких языков, как C#, Java, Kotlin, Scala, Ceylon, Gosu, Go, Eiffel, OCaml и иже с ними.

Ну и вот тут оказывается, что у языков на платформах .NET и JVM гораздо лучше с «батарейками». А у Go гораздо ниже порог вхождения, более понятная ниша (под которую он заточен), Google за спиной и уже огромная армия довольных хомячков («хомячек» здесь для красного словца вставлен, без отрицательных конотаций).

Если, скажем, у вас D используется вместо C++, то это, скорее всего, означает, что C++ для вас и не нужен был. Просто исторически так сложилось.

Так про сборщик мусора-то актуально.

Вот это очень больше заблуждение. Именно С++ или Rust являются конкурентом D, а не C# или Java. В шарпе или яве сборщик мусора проходит красной нитью через весь язык. Они без сборщика языка вообще не будут работать, грубо говоря. А в D сборщик мусора это лишь одна из возможностей управлять памятью, не больше.

А в D сборщик мусора это лишь одна из возможностей управлять памятью, не больше.

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

Т.е., если я отказываюсь от GC, то лесом идут возможности, которые мне, скорее всего сильно потребуются.

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

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

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

Более быстрая компиляция? Более простые шаблоны? Compile-time рефлексия?

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

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

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

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

Я вообще не понимаю жалоб на сборщик мусора. Если вы беспорядочно выделяете память, то у вас тормозить будет и при ручном выделении памяти. А если вы в главном цикле (если взять игру) память не выделяете, то с чего вдруг сборщику начинать эту самую сборку? В 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();
}

@nogc delegate has been called

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

import std;

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

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]

Кроме того, не знаю как сейчас, а раньше в 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, а часть - с сборщиком мусора. Язык это поддерживает.

Java и наоборот.

Это JNI? В режиме betterc или полноценный как полноценный D со сборщиком?

Я где-то слышал, якобы D нельзя встраивать и звать из JNI потому что он не может в JNI вызове инициализировать свой рантайм и хочет чтобы main() была D-шной.

Скажите, в D можно затребовать у сборщика собрать конкретные объекты немедленно? Ну например я создавал большой массив в куче, я из функции планирую выходить, а больше этот объект никому не нужен, и хочу память эту освободить прямо сейчас. В джаве так нельзя, там даже общую сборку форсировать не получается (GC только учтет совет программиста, но не более).

Я вообще не понимаю жалоб на сборщик мусора.

Речь не про жалобы. Речь про то, что GC – это водораздел. Либо ты пишешь код так, либо вот так.

GC сильно упрощает жизнь, поэтому как только компьютеры стали достаточно мощными, то языки с GC стали использоваться повсеместно. И это правильно.

Но GC не везде применим. И там, где он не применим, лично для меня странным выглядит попытка задействовать язык с GC, но без GC. Типа, вот я знаю Java, а больше ничего не знаю, поэтому когда мне нужно будет писать код с высокой отзывчивостью, я лучше начну пердолится с Java без GC, чем возьму более подходящие для этих целей С++, Ada или Rust.

При этом выясняется, что тот же D без GC выглядит привлекательным разве что в глазах тех, кто на D уже сидит давно и без GC его вряд ли использует. Иначе не объяснить то, что экспериментальные фичи, которые еще не включены по умолчанию (типа исключений без привязки к GC) или отсутствие некоторых важных фич (типа замыканий), считаются доказательством возможности использовать D без GC.

Когда сталкиваемся с программированием без GC, то возникает вопрос: а как нам язык помогает в этом деле? И выясняется, что Rust помогает. А вот D – нет. Более того, еще и разные метки, типа @nogc вручную расставлять нужно. Это типа как [[nodiscard]] в C++ – полезно, но блин, слишком уж муторно и зависит от забывчивости разработчика.

Так что это скорее не GC вызывает жалобы, а попытка D усидеть на двух стульях. Нет бы Брайту и Ко взять и сказать: D – это безопасный нативный язык с GC, типа Go, но лучше. Иниипёт. А кому не нравится, тот отправляется в пешее эротическое.

Но нет, нужно же и на ёлку влезть, и… Поэтому давайте сделаем D без GC, потом еще и betterC, а сейчас еще и лайфтаймы из Rust-а скомуниздим.

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

Отсюда и poor adoption.

Что бы не врать - первоисточник

Судя по комментариям дишный код в примере собирается без опции betterC. Также нет опции -dip1008, а значит дишное исключение, которые перехватывается в java коде, выбрасывается именно с дишным сборщиком мусора. Но сам я не проверял это дело.

Иначе не объяснить то, что экспериментальные фичи, которые еще не включены по умолчанию (типа исключений без привязки к GC) или отсутствие некоторых важных фич (типа замыканий), считаются доказательством возможности использовать D без GC.

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

Когда сталкиваемся с программированием без GC, то возникает вопрос: а как нам язык помогает в этом деле? И выясняется, что Rust помогает. А вот D – нет.

Ну как это вы все фичи языка привязали к сборщику мусора. В D есть куча вещей, которых нет в тех же C или C++ и которые к сборщику мусора вообще никогда не были привязаны. У вас тут явно предвзятая позиция. В D уже давным давно метапрограммирование с человеческим лицом, CTFE, интроспекция, модули, миксины, ренджи и прочее. И уверяю вас, они ооочень помогают, каждый день работаю и с плюсами (С++11 правда) и с D - так что разница видна очень сильно.

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

Так что аргументация у вас слабая, честно скажу.

Давайте еще раз. Для C++ сейчас осталось место либо там, где залежи легаси (причем неважно, нужно ли сопровождать древний проект или же писать новый проект, который на 90% будет состоять из древних плюсовых библиотек), либо там, где было бы лучше обойтись без GC вообще (hard-real time, встраиваемые системы, системщина и вот этот вот все).

Вне этих ниш C++у, по большому счету делать нечего. И если вы видите D как лучшую замену C++у там, где C++у не место уже, то вы ищете для D не тех конкурентов.

А вот там, где C++ все еще применим, там нужен не кастрированный язык типа без GC (коим пока все еще является D), а нормальный, проверенный временем инструмент.

И все озвученные вами преимущества D (вроде тех же CTFE, mixin-ов, ranges и пр.) будут преимуществами постольку-поскольку. Ибо аналогичные возможности C++ далеко не везде используются и востребованны. А где что-то подобное нужно и можно применять, там уже и на C++ велосипедов наваяли в разы больше, чем когда-либо сделают на D.

Собственно, в нишах типа hard-real time, встраиваемых систем и системщины тот же Rust гораздо предпочтительнее. Т.к. он не пытается усидеть на двух стульях, там все заточено под безопасное программирование без GC.

Плюс хайп и большое количество горящих желанием Rust применить.

Так что еще раз повторю то, что говорил раньше: для маленьких коллективов, которые уже подсели на D и которым экосистемы D достаточно, D может выглядеть достойной альтернативой C++ и Rust. Но таких мало.

Может быть именно потому и мало, кстати говоря :)

Да ладно вам. D на данный момент используется от микроконтроллеров и СХД (которые и реального времени, и без сборщика мусора) и до научных расчетов (где сборщик мусора и реальное время иррелевантно, но быстродействие важно). Мнение ваше, конечно, ясно, но факты говорят сами за себя.

И я уж 100% сомневаюсь, что в научные разработки начнут внедрять Rust, разве что уж в качестве низкоуровневых либ. Просто потому, что человек, способный осознано оптимизировать целевую функцию, а перед этим ее еще и вывести - вряд ли ему будет интересно слушать рассказы про лайфтаймы и количество мутабельных ссылок, как показывает практика. Питон и взлетел поэтому.

Все мной озвученные преимущества D значительно повышают качество кода и продуктивность разработчика и позволяют ему больше времени уделить решению проблемы, а не заниматься удовлетворением требований компилятора. Есть области где безопасность очень актуальна, а есть где не очень - а зачем платить цену за то, что не используешь?

D на данный момент используется от микроконтроллеров и СХД (которые и реального времени, и без сборщика мусора)

Так и на Java такого добра навалом, если не больше на пару-тройку порядков. Что вовсе не говорит о том, что на Java такие вещи легко делаются, и что Java в этом лучше C++ или Rust.

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

Я могу предположить, что все озвученные вами преимущества вы опробовали на D с GC.

Скажите, в D можно затребовать у сборщика собрать конкретные объекты немедленно? Ну например я создавал большой массив в куче, я из функции планирую выходить, а больше этот объект никому не нужен, и хочу память эту освободить прямо сейчас. В джаве так нельзя, там даже общую сборку форсировать не получается (GC только учтет совет программиста, но не более).

Есть GC.free позволяет освободить память, ранее выделенную сборщиком мусора, если память выделялась под типы с деструктором предварительно необходимо вызвать destroy. Есть GC.collect вручную запускает процесс сборки мусора, но реальные действия implementation defined - как и в Java

Вы также можете свой сборщик мусора использовать при необходимости.

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

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

Так и на Java такого добра навалом, если не больше на пару-тройку порядков. Что вовсе не говорит о том, что на Java такие вещи легко делаются, и что Java в этом лучше C++ или Rust.

Ну как минимум это говорит, что Java не хуже C++ или Rust

Я могу предположить, что все озвученные вами преимущества вы опробовали на D с GC.

Так эти преимущества _не зависят_ от сборщика мусора, есть он или нет - это не имеет значения.

D - первая попытка сделать Go.

Ну вы очевидно не знаете либо D, либо Go, либо оба эти языка. Они отличаются, мягко говоря, кардинально.

Спасибо. Да, они там по JNI сильно замахнулись.

Да, если получится, то это будет сильно. Я давно хочу приложение под Андроид на D написать.

Печально, что у проекта DlangUI нет ресурсов. Для десктопа эта технология была бы хитом.

Ну как минимум это говорит, что Java не хуже C++ или Rust

Нет, это говорит лишь о том, что на Java такое можно делать. А вот насколько это лучше/хуже судить сложнее. Особенно в условиях, когда от C++ зачастую отказывались исключительно по политическим мотивам, на волне хайпа, или же когда технические решения принимали люди, начинавшие свой пусть в программировании с Python-а и Java.

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

Речь о том, что вы о D судите с позиции человека, который использует D с GC. Поэтому, например, вам без разницы, что скрывается внутри ranges, можно ли сохранить ссылку на то, что лежит внутри range, насколько безопасно сохранять у себя ссылки на immutable объекты, можно ли передавать замыкание в какой-нибудь обобщенный алгоритм или сохранять замыкание где-то, нужно ли расставлять @nogc, что генерирует какой-нибудь mixin из популярной библиотеки и т.д.

А вот когда вы лоб в лоб столкнетесь с тем, что обо всем этом нужно думать. И не просто думать, но еще и отгребать, если что-то забыли или в чем-то ошиблись, то ситуация может сильно изменится.

Ну вы очевидно не знаете либо D, либо Go, либо оба эти языка. Они отличаются, мягко говоря, кардинально.

Не обращай внимания, жто известный лоровский специалист по всему, а на деле заправщик принтеров и нажиматель any key.

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

не, не так. первая попытка сделать Go – это Limbo из Inferno. читая книгу Inferno Programming with Limbo видим примеры того, как можно написать приложение в стиле CSP процессов и каналов Хоара.

в частности, примеры того, как можно по коду на Limbo сгенерировать код на сишечке модульный, автоматически ключом компилятора limbo -T. и далее этот сишный модуль встроить в ядро Inferno.

среди презентаций и публикаций от автора этой книжки есть примеры подобного приложения: модульный сниффер, симулятор embedded микроконтроллеров распределённый кроссплатформный в стиле Grid. там тоже похожая архитектура: Hosted OS Inferno в виде emu ядра на сишке (который собирается 6c/6l компилятором kencc), потом модули на Limbo и Dis VM, потом модули-плагины встраиваемые в emu ядро библиотекой. причём, автомагически можно их скодогенерировать из прототипа на Limbo написанном.

кстати, ещё про публикации из Plan9/Inferno. про конкурентный многопоточный инкрементальный GC без синхронизации и lock-free, и про Rio конкурентую оконную систему.

второе описывает альтернативный дизайн для lock-free gui. если сисколлы и каналы обычно блокируются, а хочется lock-free – разбивают window system на несколько процессов (mouse/kbd/styx) которые мультиплексируют обработку в корутины и зелёные нити, которые в свою очередь, мультиплексируют много логических ресурсов в один физический (что через множественные пространства имён и сисколл bind в plan9 естественно реализуется). то есть: оконная система как мультиплексор ресурсов, через файлы и файловые сервера представляющих системные объекты которые мультиплексируются несколькими процессами (в которых блокирующиеся сисколлы на чтение этих объектов) в нити-обработчики.

в итоге цель получить полный lock free, в добавок к сетевой прозрачности и конкурентности.

всё это реализовано было в девяносто мохнатые года ещё на сишечке в Plan 9 (сначала было на отдельном языке Alef, прообразе Limbo. потом обошлись для каналов и корутин сишной библиотекой).

сам протокол P9FS / Styx при желании можно и на микроконтроллерах реализовать: на Lego Mindstorm – Styx файлсервер это сетевой TCP/IP сервер, отвечающий на 14 сообщений специального вида. в книжке ipwl выше приводится утилита interloper для трассировки запросов – по сути, сниффер.

GoLang по сути это Limbo-Inferno runtime (emu) - Dis VM + ad hoc интерфейсы + корутины + паника+ много библиотек + тулзы в удобной упаковке (go build/test/get/…)

Android по сути это Inferno -plan9 подобное ядро + Linux -glibc +boinc -Dis +Dalvik -Limbo +Java/Kotlin/etc

опять хайпанули же. поскольку не продаётся Plan9/Inferno, завернули в красивую упаковку от Linux+Java и продали вторсырьё по второму разу, а потом ещё GoLang по третьему.

D – это на мой взгляд, вторая попытка сделать «С++ с человеческим лицом» (если первой считать Java или MS Java := J++,J#, .NET и прочие).

и все проблемы второй системы.

что как сказал Линус на примере «SVN = CVS с человеческим лицом» – путь в никуда. потому что сам оригинал уж сильно нечеловеческий - чтобы далее его архетип копировать.

Но GC не везде применим. И там, где он не применим, лично для меня странным выглядит попытка задействовать язык с GC, но без GC. Типа, вот я знаю Java, а больше ничего не знаю, поэтому когда мне нужно будет писать код с высокой отзывчивостью, я лучше начну пердолится с Java без GC, чем возьму более подходящие для этих целей С++, Ada или Rust.

При этом выясняется, что тот же D без GC выглядит привлекательным разве что в глазах тех, кто на D уже сидит давно и без GC его вряд ли использует. Иначе не объяснить то, что экспериментальные фичи, которые еще не включены по умолчанию (типа исключений без привязки к GC) или отсутствие некоторых важных фич (типа замыканий), считаются доказательством возможности использовать D без GC.

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

хотя эти вещи как 3 шестерёнки, зацеплены друг за друга – можно и иногда и нужно написать другой рантайм к тому же языку. если хочется хвалёного зерокоста, и все эти фичи языка не нужны – нужен настраиваемый ограниченный рантайм.

например, можно писать на си сетевой сервер. в духе POSIX написать с форком и сигналами, потом портировать это на виндовое WaitForMultipleObjects и CreateThread и т.п. потом обмазаться #ifdef (который в том же Plan9 уже давно considered harmful – и статья такая есть. сам код что Inferno что Plan9 os показывает, что вполне возможно писать кроссплатформное/кроссистемное без кучи #ifdef, скринсейвера configure и лапшы из автолулзов на M4, даже на сишечке). или упарываться по std::thread или опять же кроссплатформным библиотекам.

в общем, получить нечто хрупкое на сишечке.

или взять например аду. и избранные места переписать на аду с tasks и рандеву. отвязавшись от POSIX-анутости с форком и сигналами и завязавшись на встроенную конструкцию языка, адский рантайм, приложение с несколькими рантаймами.

причём GNAT тоже использует бекенд gcc. то есть, в таком многоязычном приложении кодогенератор и оптимизатор будет один и тот же, gcc-шный.

потом не удовлетворившись стандартным GNARL/GNULL рантаймом из GNAT ады, использовать свой обрезанный кастомизируемый, и прагмы на аде его ограничивающие. возможно, предварительно проверив и доказав на SPARK что что-то фичастое в реальной программе не используется, и можно так ограничивать.

вот и тут, в D тоже нужно нечто подобное. возможность собрать свой ограниченный рантайм и версию без всех фич языка, которые в реальной программе не используются. потому что если не нужно – зачем платить больше?

при этом поскольку CTFE, контракты, рефлексия по тайпинфо времени компиляции и аннотации типа @nogc, pure, immutable можно формально доказать что все эти богатые фичи на самом деле в реальной программе не используются – и значит, можно выкинуть и заменить на другой, оптимизированный рантайм.

экспериментальные фичи, которые еще не включены по умолчанию (типа исключений без привязки к GC) или отсутствие некоторых важных фич (типа замыканий), считаются доказательством возможности использовать D без GC.

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

теоретически, замыкания можно и без GC реализовать. например, вот здесь про ZIL и MDL приводится пример лиспа из 70-х (MDL, Muddle) и DSL на его базе, ограниченного (ZIL, Zork Implementation Language).

второй сделан специально таким образом, чтобы этот ограниченный диалект лиспа не использовал GC. чтобы не cons-ил в рантайме, возможно только в компайл тайме в макросах.

язык существенно ограничен по сравнению с полноценным лиспом, зато допускает компиляцию в другой, статический язык (например, то же си-подобное). далее Inform7 ещё более ограничен как язык, но зато в нём явно прописано что вся память выделяется статически, и её выделение известно в compile time. что любопытно, на Inform6 реализован диалект лиспа (в игре «Lists of Lists»: вы начинающий студент академии магии, заходите в башню, садитесь за компутер. вылазит джин и подкидывает 20 задачек на лиспе (диалекте схемы). игру не пройдёте, пока примеры не отладите и не заработают на этом диалекте лиспа в игру встроенном. ). диалект лиспа реализован на Inform6, в котором забили на эту фичу про статическую аллокацию, встроили код на сишечке в безопасную Zork VM и делали malloc/free в куче вручную.

можно и пулы памяти использовать, в духе той же ады, например.

тот же TeX написан на диалекте паскаля, в котором всё выделение памяти в массивах, в духе фортрана и мемори пулов закат солнца вручную.

так что да, фичи можно не использовать и рантайм другой настраиваемый использовать — если вы знаете, что делаете и сколько стоит использование этой фичи.

другое дело, что язык не помогает это формально верифицировать, и автомагически такие возможности обнаружить. в Аде, например есть ASIS + SPARK, которые это могут.

в расте и т.п. пошли по пути явного ограничения C memory model + language machine, Rust memory model — которая явно ориентирована на улучшение lock free, зерокост, многопоточность и конкурентность и т.п.

в реальности нужно и то и другое.

если проанализировать тот пример про ZIL и MDL:

There was a lot of effort put into not provoking the garbage collector (No consing, please, this is Lisp!). Zork never called that–slow, prone to unexpected consing, and so on. So it didn’t get in the way when moving to ZIL (or to FORTRAN); everything that was running in Zork was compiled, which limited the bad (inefficient, difficult to port) things that

есть фичи языка, такие как локальные и глобальные области видимости, синтаксический сахар к ним через точки и запятые; никогда не запускать EVAL и ограничивать FEXPS, чтобы всё компилировалось в CTFE статически код, с зерокост рантаймом; ограничивать MAPF и прочие рекурсии.

Side note: I believe Cornerstone’s VM is much better suited to hosting functional MDL programs than the Z-machine.

занятно, что VM в которую это всё компилировалось – развивалась со временем: .z3,.z5,.z6,.z8, cornerstone VM (для СУБД с ЕЯ интерфейсом, описание VM доступно), glulx vm.

развивалось в направлении устранения ограничений VM (более гибкого языка с более толстым рантаймом с бОльшими накладными расходами на стоимость «фич языка»).

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

опять же, язык ничего не делает для ограничения этих фич. но хотя бы позволяет написать свой парсер, задействовать аннотации, контракты, CTFE фичи на тайпинфо рефлексию (поверх аннотаций) чтобы эти ограничения проконтролировать.

по хорошему, нужен компилятор библиотекой с плагинами чтобы такие верификаторы написать. и что-то типа того же семантического интерфейса как ASIS в Аде.