Ага, мне тоже «мусорщик» нравится больше.

При слове «мусорщик» в тексте за аватаркой автора сразу представляется программист, владеющий темой. При словах «сборщик мусора» — маркетолух-минетжер, больше всего боящийся, что серьёзные дяди отругают его за несерьёзную терминологию.

// Это всего лишь ассоциации, в жизни может быть по-любому, разумеется.

да по-моему ни у кого нет нормальной, вся проблема в том, что С++ слишком сложен, чтобы иметь с ним совместимость, поэтому единственный путь обеспечить с ним совместимость - это встраивать полноценный плюсовый компилятор в то, что хочет поддерживать эту совместимость

Rust его победил, хоть и не хотел, закапывайте. Вообще неплохой язык, но 90% либ не пашет без GC, в топку.

Ты прямо все 90% либ перепробовал

Господи, что бы знать что 90% либ не могут в GC, надо перепробовать 100% либ. И ты не способный решить задачку из 3 класса мне рассказываешь про любительство?

Ты много топишь за Nim. Где посмотреть годные проекты на Nim? Где почитать об трюках и волчьих ямах?

Кто нибудь может объяснить чем реалтайм Cortex-M отличается от реалтайма Cortex-R?

Никому не нужна совместимость с С++. Даже совместимость с С, как таковым, никому не нужна. Просто так получилось, что сишное ABI это универсальный интероп, поэтому с ним и делают совместимость. Возьми Rust - по сути это язык следующего поколения. Да там плевать все хотели на совместимость с С++. И это никак не мешает его бешеной популярности. Возьми Java, Python, какие там ещё самые популярные языки. Ни у кого нет никакой совместимости с С++.

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

С чего это вдруг?!

Нигде не топлю. Документация нулевая. Ответы нужно гуглить на форуме или дискорде. Отладки как таковой вообще нет. Каждый тип исключения нужно обрабатывать иначе оно аукнится в работе программы.

D - интересный язык, по продуктивности разработки похожий на Python, при производительности, сравнимой с C++
Мне кажется, что полу-рабочий инструмент без внятных планов развития не особо привлекателен, даже несмотря на то, что в некоторых моментах он очень хорош.

C# же ж. Последний раз я тыкал палкой D, когда в нем был неточный сборщик мусора. Тогда я не был впечатлен. Когда я читаю фичи последней версии D, мне сразу вспоминается шарп. И тоже по производительности сравним с C++. Я давно не следил за языком, но пока что он меня не впечатляет. Да, отдельные прикольные фишечки есть, но в целом ничего прорывного, а опора на GC лишь заменяет один класс проблем (работа с памятью) другим (тормознутая сборка) — и я сомневаюсь, что это вторая проблема всерьез решалась в языке.

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

максимум возможностей в человеко – читаемом виде

Адовцы так же думали и даже сделали по максимуму, а в итоге писать на Аде, все равно что пытаться проглотить рыбьи кости. Куча кода, минимум библиотек и те к ветхозаветному периоду относятся, несовместимость типов требующее постоянного 'Image, из брокеров только CORBA от которой блевать хочется.

Вообще-то, Python развивается. Специально для микроконтроллеров предназначены его разновидности MicroPython и Zerynth Python, которые иногда даже применяются. Применение Rust для микроконтроллеров пока ещё эксперимент, но может быть в конечном счёте будет практичным.

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

Когда я читаю фичи последней версии D, мне сразу вспоминается шарп. И тоже по производительности сравним с C++.

C# не совсем то, потому что выполняется в VM, а D компилируется в машинный код. Это две разные ниши с разными задачами. В критичных к производительности числодробильнях в шарпе придется вызывать код на C++, а D перемолотит все быстро сам.

Никому не нужна совместимость с С++.

ЕМНИП там до сих пор ABI не стандартизирован. Так что какая может быть совместимость?

У сишечки с этим намного лучше. Почему её в качестве ffi и используют.

Сейчас мейнстрим - это С++ и D нужна совместимость именно с ним.

Совместимость с этим франкенштейном? Да ты гонишь! Он сам-то с собой нихрена не совместим. Разные компиляторы (одного поколения!!) до сих пор спотыкаются друг об друга. Не говоря уже про утерю преемственности кода между версиями «стандарта».

Если и говорить про всякие «совместимости» между компилируемыми языками, то настоящая совместимость может быть только на уровне ABI. Примерно, как это реализовано у языков на основе JVM.

Была в своё время контора бывших сотрудников Borland, которые попытались реализовать такую идею на основе MSDOS и Intel. Не взлетело. M$ заменили DOS на Шindiws и бобик сдох.

Кому интересно, гуглите по ключевым словам «Topspeed compilator» «J&J company»

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

Насколько я понимаю, у D и так есть потенциал для «популярности» - совместимость с C-библиотеками. Правда, односторонняя, как и у C++. А вот если-бы да кабы можно было на D писать либы типа glib и они линковались к любым программам на любых компилируемых языках! «Эх! Петька! Мы бы всех белых победили!»

C# не совсем то, потому что выполняется в VM, а D компилируется в машинный код. Это две разные ниши с разными задачами. В критичных к производительности числодробильнях в шарпе придется вызывать код на C++, а D перемолотит все быстро сам

C# тоже компилируется AOT, NGEN был в дотнете чуть ли не с первых версий. «В критичный к производительности числодробильнях» я буду вызывать CUDA.NET, которая порвет любой код на C++/D/C/asm/etc.

С++, кстати, и в обратную сторону совместим и на нем можно писать сишные библиотеки вполне. Подозреваю, что D тоже должен так уметь.

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

P.S. Cuda\OpenCL ведь про то же самое, они вообще из исходников компилируются под текущую видеокарту и на это тратится много времени, просто затраты окупаются после определенного момента. И да, Cuda\OpenCL - не панацея, они хороши только в своем узком сегменте - в вычислениях, которые хорошо ложатся на архитектуру GPU.

уменьшение вероятности наличия уязвимостей ценой увеличения нагрузки на программиста приводит к появлению уязвимостей и/или некорректностей уже не в работе с памятью, а в самой логике

«Отлить слова в граните!» (ц) Это самая правильная формулировка, почему ржавоподелие порочно от рождения - именно вот этим: «мы сделали всё безопасно, но вы так ЗАЕ******ТЕСЬ ПИСАТЬ безопасно, что скорее бросите язык».

Наплевать на «хороняк Ди» - чем меньше этих клоунов, тем меньше конкуренции.

А вот если-бы да кабы можно было на D писать либы типа glib и они линковались к любым программам...

D писался как преемник С++, а не как «заглушка» к ушлёпским сипипям. Если уж идти в новый век, так с новым языком, который должен ЗАМЕНИТЬ ВСЁ. Нет смысла продолжать ковыряться с Си, если ты всё равно его закопаешь.
Почему C# взлетел? Вот поэтому - он сразу предложил «новый дивный мир», где даже указателей нет и всё красиво завёрнуто в объектики - как же глубоко и довольно выдохнули те, кто писал простыни Win32 API!! :)

Но C# это игрушка Микрософта (куча легаси и явно гуманитарных решений), а для нативного мира нужен адекватный язык, который писали без оглядки на три строки легаси.

Язык D имеет маленький недостаток - он никому не нужен.

:)))) Сказал как пёрнул!
Ди - это преемник С++. ВСЕ, кому нужен современный ООП, но заколебался костылям С++, дорога в Ди. Ди-вный мир нормального языка и библиотек.

И проблема в том, что D не дает революционных преимуществ перед плюсами

Уже по этой фразе распознаются ТРЕПАЧИ, которые от Ди только и знают, что «преемник С++». Ты от фич Ди даже 1% не знаешь, иначе не морозил бы такую тупость «не дает преимуществ» - ещё как даёт! Надо просто РЕАЛЬНО УЧИТЬ ЯЗЫК, чего ты по лени своей никогда не делал.

Ну раз ты у нас такой просветленный, приведи пример кода, где D показывает свое превосходство над C++

Учи язык. Мне за метание бисера не платят. Просто поверь проф. программисту (стаж 20 лет).

Наплевать на «хороняк Ди» - чем меньше этих клоунов, тем меньше конкуренции.

Какой конкуренции?

понял, пустой вскукарек

D и раст компилируются в LLVM и его аналоги, а не машинный код. С++, обычно, тоже. С#, в свою очередь, компилируется в CIL. Почему вы CIL называете виртуальной машиной, а LLVM - нет, для меня загадка.

Почему вы CIL называете виртуальной машиной, а LLVM - нет, для меня загадка.

У LLVM есть промежуточное представление, но в итоге исходники всё-таки преобразуются в машинный код. А CIL не запускается самостоятельно, а при помощи рантайма. В этом и разница.

CIL тоже всегда преобразуется в машинный код. Обычно JIT-компилятором, но возможность использовать ahead-of-time компиляцию также присутствует из коробки.

Рантайм есть и у D и у С и у любого другого живого языка.

Рантайм есть и у D и у С и у любого другого живого языка.

Это разные рантаймы. Или ты правда не видишь разницы между «нативными» языками и языками с виртуальной машиной?

D и раст компилируются в LLVM и его аналоги, а не машинный код. С++, обычно, тоже. С#, в свою очередь, компилируется в CIL. Почему вы CIL называете виртуальной машиной, а LLVM - нет, для меня загадка.

Во-первых ldc не единственный компилятор языка D. Есть еще gdc и dmd. Во-вторых, LLVM IR - это промежуточное представление кода, которое существует только во время компиляции. CIL преобразуется в машинный код в рантайме, это немного не одно и то же. У D в рантайме крутится только его примитивный сборщик мусора, который, если не ошибаюсь, дергается только при вызове new или руками. Т.е. по сути его можно рассматривать как вызов библиотечного кода. Я совсем не эксперт по устройству .NET, но там как минимум есть JIT и гораздо более продвинутый сборщик мусора, т.е. в рантайме присутствует «машина», выполняющая «виртуальные» инструкции.

У C#, в отличие от Java, нет виртуальной машины.https://stackoverflow.com/questions/1564348/is-the-clr-a-virtual-machine

Есть еще gdc

у gdc, по факту, тоже есть промежуточный язык

dmd

мало того, что дигитал марс не может в платформы, кроме х86, так ещё и на ней сильно отстаёт в производительности от gdc и ldc

LLVM IR - это промежуточное представление кода, которое существует только во время компиляции.

да

CIL преобразуется в машинный код в рантайме,

совершенно ложное утверждение, CIL точно также компилируется до запуска программы. https://en.wikipedia.org/wiki/Common_Intermediate_Language

1. Source code is converted to CIL bytecode and a CLI assembly is created.
2. Upon execution of a CIL assembly, its code is passed through the runtime’s JIT compiler to generate native code. Ahead-of-time compilation may also be used, which eliminates this step, but at the cost of executable-file portability.
3. The computer’s processor executes the native code.

т.е., там даже JIT необязательный

У D в рантайме крутится только его примитивный сборщик мусора,

в любом рантайме ещё есть набор стандартных функций, но в целом, можно и так сказать

в C# же крутится мощный сборщик мусора

почему ржавоподелие порочно от рождения - именно вот этим: «мы сделали всё безопасно, но вы так ЗАЕ******ТЕСЬ ПИСАТЬ безопасно, что скорее бросите язык»

У тебя неверное представление о Расте. На нём не нужно прилагать усилия, чтобы писать безопасно, нужно прилагать усилия, чтобы писать небезопасно.

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

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

К тому же, сейчас там нет ничего нового. Что-то стоящее там было в нулевых, но не сейчас.

А вот это очень сложный вопрос. Чем один язык отличается от другого? Только синтаксисом? Маловато будет. Скорее, всей совокупностью — согласованной! — синтаксисом, читаемостью, набором возможностей, вытекающей из них стандартной библиотекой и соответственно, приёмами работы. Я настаиваю :) , что D предоставляет такой набор, что писать на нём легко и быстро. Очень быстро, сравнимо со скоростью написания кода на динамически типизированном Питоне. C++ не может предложить ничего подобного, несмотря на весь появившейся сахар. Хотя вероятно, некоторый код сделать на последних вариациях ++ гораздо проще, чем на D, на общий случай это не влияет.

Насколько это важно, продемонстрировала недавняя история с уязвимостями в >>написанном на RUST аналоге sudo: увеличение нагрузки на человека – программиста >>за счёт формы и дополнительных сущностей

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

Возможно. Однако, наблюдается удивительная картина: все проекты, делающиеся на Rust’е, оказываются долгостроем. Я склонен считать этот факт камнем в подтверждение тезиса.

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

Надо. Когда говорим об «уровне сложности», надо иметь в виду и скрытые особенности и возможность разобраться в коде стандартной библиотеки. Много народу способно врубиться в шаблонный код stl? А сколько реально будут это делать? Я бы даже сказал, сколько надо заплатить человеку, чтобы он по доброй воле полез в этот код?

А теперь сравниваем с аналогичными инструментами D.

Самая главная проблема D в том, что он совместим только с C, а в современном мире нужна совместимость уже с C++.

Это не совсем так. Есть более – менее зачаточная совместимость на уровне ABI. Для работы на уровне библиотечного кода это достаточно. Смешивать два языка в одном тексте нельзя, конечно, хотя попытки телодвижений в этом направлении, похоже, есть (или были).

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

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

А вот если имеется в виду, что можно отгрызть кусочек (и даже более, кусман) за счёт очень быстрой разработки при вполне достаточном качестве машинного кода, то почему бы и нет?

Вообще-то, Python развивается. Специально для микроконтроллеров предназначены его разновидности MicroPython и Zerynth Python, которые иногда даже применяются.

Чот кажется очень странным, по крайней мере, для «классических» МК с крайне ограниченными ресурсами.

Применение Rust для микроконтроллеров пока ещё эксперимент, но может быть в >конечном счёте будет практичным.

Вероятно, только для МК и драйверов и будет практичным :)

Язык D имеет маленький недостаток - он никому не нужен.

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

Но если энтузиасты пытаются найти ему области применения, то это нормально.

Нет, следует читать: «то это замечательно» :)

Насколько я понимаю, у D и так есть потенциал для «популярности» - совместимость с C-библиотеками.

На D можно писать код, имеющий C – ABI и свободно линковать его с понимающим этот ABI кодом. И наоборот. Есть зачатки аналогичной совместимости с С++.

А вот если-бы да кабы можно было на D писать либы типа glib и они линковались к любым программам на любых компилируемых языках!

Вот если бы в своё время штуки типа SOM и direct - to SOM компиляторы «пошли бы в народ», то о межъязыковой совместимости вообще бы не говорили, была – бы автоматически. Но увы… :)

Ну раз ты у нас такой просветленный, приведи пример кода, где D показывает свое превосходство над C++

ну, посмотри, например, реализации любой части std:: и аналогичных средств Фобос’а.

D и раст компилируются в LLVM и его аналоги, а не машинный код. С++, обычно, тоже. С#, в свою очередь, компилируется в CIL.

брррр. компилятор ldc (ldc2) можно заставить выдавать результат в llvm, но почему-то, все предпочитают простой исполняемый код.

можно, к слову, и в webassembly, это как-то меняет суть дела?

а cil виртуальной машиной, наверное, не называют, но своего рода интерпретатором, контролирующим ход исполнения, безусловно :)

почему ржавоподелие порочно от рождения - именно вот этим: «мы сделали всё >>безопасно, но вы так ЗАЕ******ТЕСЬ ПИСАТЬ безопасно, что скорее бросите язык»

У тебя неверное представление о Расте. На нём не нужно прилагать усилия, чтобы писать безопасно, нужно прилагать усилия, чтобы писать небезопасно.

наверное, всё-таки, не совсем так. «надо прилагать усилия, чтобы писать.». Точка :)

Очень многое, что (уже давно) есть в D, появилось и в C++14 / C++20, да…

Возможно, ранее оно было актуально, но момент упущен.

Момент для чего? Ещё раз, на C++ не получается писать столь же быстро, как и на D. Причём отрыв значителен. Подразумевается корректный код. Да, стало сильно лучше, но большой разрыв до сих пор есть и веорятно, избавиться от него не выйдет.

D - интересный язык, по продуктивности разработки похожий на Python, при >производительности, сравнимой с C++. Проблема же D в том, что он годами стагнирует >в недоделанном состоянии и у него полностью отстуствует план развития. Фактически >это просто хобби-проект Уолтера Брайта

Согласен. К сожалению, это судьба всех! инструментов, за которыми не стоит или крупная коммерческая контора, или удачливая контора, которой удалось занять пустующую нишу. Даже C++ в своём развитии абсолютно подтверждает этот тезис.

С другой стороны, есть пример Питона, который тоже очень медленно «шёл в народ», но в конце концов, распробовали :) Это даёт некоторую надежду.

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

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

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

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

Да, у нас дело сильно портит отсутствие хорошего русскоязычного учебника,

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

кроме хайпа, для успеха, нужен лёгкий в освоении инструмент. 10 лет назад этого не было. Книжка Александреску (2012 переводная) не годится в качестве учебника: раскрывает концепции и задумки автора, но большинство практиков поставят обратно на полку: интересно, но не практично.

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

шарп. И тоже по производительности сравним с C++

о, как же юзеры ругают шарповские программы! формально, по производительности сравнимы, но какие, зачастую, проявляются жестокие «тормоза»! Впрочем, после того, как видел исполняемый файл на 300Мб, уже ничему не удивляюсь. Ну и (фактически) виндоус-центричность не вызывает энтузиазма.

Нет, конечно, есть и более, чем позитивные примеры. Но осадочек остался :) А значит, у инструментов, дающих чистый, «не управлямый» код, есть некоторые перспективы.

а опора на GC лишь заменяет один класс проблем (работа с памятью) другим (тормознутая сборка)

минутку. Что имеется в виду? Сборка, или «остановка мира»?

зачем развиваться питону? Его уже давно забросили.

??? Когда?

потому что питон порочен в корне

В чём это выражается?

о, как же юзеры ругают шарповские программы! формально, по производительности сравнимы, но какие, зачастую, проявляются жестокие «тормоза»

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

Впрочем, после того, как видел исполняемый файл на 300Мб, уже ничему не удивляюсь

У меня есть на делфи 300 Мб бинарник.

а опора на GC лишь заменяет один класс проблем (работа с памятью) другим (тормознутая сборка)

минутку. Что имеется в виду? Сборка, или «остановка мира»?

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

зачем развиваться питону? Его уже давно забросили.

??? Когда?

Вам просто не доложили об этом. Cpython уже довольно давно находится на минимальной поддержке, которой не хватает ни для какого развития и баги в нем висят годами. Особенно тебе об этом не скажет Гвидо, который с покерфейсом при любой погоде будет хвалить свой проект. Из которого он сам, правда, уже давно ушел.

потому что питон порочен в корне

В чём это выражается?

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