Мини-версия рантайма для программирования микроконтроллеров на D

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

ну вообще D изначально позиционировался как замена C++

Ну хотелось бы какой-нибудь конкретики, обе библиотеки слишком объемные.

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

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

В Обероне я умудрился напрямую использовать C++ Haiku API. С Qt наверное тоже можно.

D писался как преемник С++, а не как «заглушка» к ушлёпским сипипям.

Александреску в гриме? Простите, мэтр, не узнал.

Почему C# взлетел?

Рождённый ползать летать не может.

Но C# это игрушка Микрософта

C# - это не игрушка Мелкософта, а высер. Причём получился он после того как Sun им заткнули физиологическое отверстие из которого лезла Жаба, ломающая совместимость с Сановской Жабой (что характерно для мелкомягких всегда).

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

У компиляторов Delphi и C# один и тот-же автор.
Совпадение?
Не думаю :)

У компиляторов Delphi и C# один и тот-же автор

Не у компиляторов, а у языков. Компиляторы и VM делали совершенно разные люди.

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

Да, конечно. Только не надо забывать, что Qt требует метакомпилятор и его выхлоп крайне сложно переложить на что-то, отличное от C++. В интерпретируемых языках с этим, к слову, лучше, поэтому Qt-биндинги к Питону, например, не запредельно сложны.

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

Работа идёт. Похоже, сообщество согласилось, что изначальное решение отринуть совместимость с C++ было сильно ошибочным.

ну вообще D изначально позиционировался как замена C++

весь вопрос в том, что имелось в виду. в моей башке это разворачивается в «замена в нишах, где скорость разработки важнее чистой производительности и/или размера получающегося бинарника». то есть, в 90% случаев.

Про 100% замену: не верю, что такой опытный инженер, как Брайт, не понимал, что это невозможно: для такой замены надо тащить весь багаж и модель C++, что совершенно бессмысленно.

Ну хотелось бы какой-нибудь конкретики, обе библиотеки слишком объемные.

ну, например, чтобы не слишком объёмное, посмотри std::bitset и BitArray из std.bitmanip. Последний не вполне подходит, так как это динамический массив бит, а не статичный, но по реализации можно судить о «незначительном улучшайзинге».

Можно ещё глянуть на стороннюю реализацию более статичного массива бит https://github.com/ZILtoid1991/bitleveld.git

для грубой оценки: заголовок /usr/include/c++/10/bitset : 45979 байт, 1598 строк, blank 212 comment 350 code 1036

весь файл (то есть, не только BitArray, а ещё куча всего, ВКЛЮЧАЯ ЮНИТТЕСТЫ) /opt/ldc2-1.24.0/import/std/bitmanip.d: blank 692 comment 597 code 3341

упомянутая реализация от László Szerémi: blank 10 comment 46 code 256

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

на C++20 — да, на C++17 — возможно, на более младших — нет.

Обратное тоже верно.. не всё, что можно выразить на C++, можно однозначно выразить на D

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

С чего бы? ldc2 генерирует крайне хороший код, gdc даёт код, не отличающийся принципиально от кода для C++. На dmd никто релизный софт не собирает, насколько я понимаю.

программ на D почти нет, в отличие от шарпа, на котором валом софта, и серверного, и десктопного.

это верно :)

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

Зачем?

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

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

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

Ты не ответил на вопрос. Что подразумевается под тормозутной сборкой?

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

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

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

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

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

В отсутствии архитектуры. При создании этого ЯП, кажется, повторилось большинство >ошибок создателей ЯП предыдущих 30 лет.

Ой, да ладно. Питон придумывался для обучения и покрывал популярные на тот момент концепции. А потом всё завертелось… Почему-то академически полные инструменты никогда не бывают удобными и популярными. Немного здоровой эклектики, скорее в плюс, чем в минус. Ну да, потенциала для расширения новомодными штучками немного, во всяком случае, без глобальной ломки. Ну и что? Удобство инструмента это не нарушает.

по факту бесполезные лямбды и сложность написания функционального кода

Хорошо бы рассказать это специалистам в области МО, чёй это они кипятком писают?

ldc2 генерирует крайне хороший код, gdc даёт код, не отличающийся принципиально от кода для C++. На dmd никто релизный софт не собирает, насколько я понимаю

И CLR генерирует очень хороший код. Что не отменяет его тормознутости по сравнению с C/C++. Очень много бенчей с C# и JVM на becnhmarkinggame бессмысленно, казалось бы, проигрывают или выигрывают у альтернатив. А происходит это из-за того, вызвался ли во время работы программы GC и сколько раз. Это и является принципиальным отличием кода генерируемого LDC от кода Сlang-LLVM.

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

Зачем?

Мигрировали с 32 бит на 64, его раздуло некисло так.

Ты не ответил на вопрос. Что подразумевается под тормозутной сборкой?

Нагрузка на процессор и его кэш в результате работы сборщика мусора.

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

Да, Так сделали в C#, так сделали в Go, так сделали в JS, да в питоне, в общем-то, но на питон я бы не стал равняться.

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

И это тоже. Только ты здесь не упомянул, что это же является причиной, почему никто не может сделать альтернативной реализации — у языка нет спецификации, о его стандартизации не может идти и речи. По этой же причине в коде базовых объектов питона до сих пор в основном находится тот же самый код из 1991 года. Значимым исключением из этого правила являются, например, строки. которые приобрели юникод и потому изменились.

Питон придумывался для обучения и покрывал популярные на тот момент концепции. А потом всё завертелось

Мне указывали на это заблуждение и я в нем разобрался. Питон не разрабатывался для обучения — питон разрабатывался для никсового скриптинга, там он и осел навечно, не осилив толком ни GUI, ни нормальную работу в виндовой консоли. То что на нем делают сервера?.. Ну, кто-то сервера и на баше писал.

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

Ошибка номер два: питон никому не нужен, всем нужны готовые решения, которые есть в изобилии под питон. По этой же причине питон никогда не разовьется, и даже для введения минимальных (!) изменений в язык при переходе от второй версии к третьей понадобилось лет 10, чтобы на это портировали готовые решения. Как инструмент сам питон неудобен. и потому сообщество массово ищет альтернативы, но что-то более-менее совместимое с CPython не получается сделать — слишком уж он кривой, слишком ограничивает альтернативные реализации.

по факту бесполезные лямбды и сложность написания функционального кода

Хорошо бы рассказать это специалистам в области МО, чёй это они кипятком писают?

Я не понял тезиса.

Мне указывали на это заблуждение и я в нем разобрался. Питон не разрабатывался для обучения — питон разрабатывался для никсового скриптинга, там он и осел навечно, не осилив толком ни GUI, ни нормальную работу в виндовой консоли. То что на нем делают сервера?.. Ну, кто-то сервера и на баше писал.

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

Повторяемое тут утверждение, что Python не развивается - вообще глупое, а в этой теме вдвойне глупое, так как былм разработаны и реально применяются варианты Python- а специально для микроконтроллеров. От стандартного Python-а они отличаются например отсутствием GIL, затрудняющего многопоточную обработку. Также меньше требования к ресурсам.

Python разрабатывался для прототипирования приложений на C++ (в этом не преуспел) и для замены Perl в веб-приложениях, имея более простой синтаксис

Читай интервью с Гвидо, где он конкретно объяснял, кто зачем разрабатывалось и за чем следовало. Про C++ Гвидо в то время не знал, а многие идеи были позаимствованы, как ни странно, из Си. Я тоже этому удивился сначала, но потому, глубже познакомившись с языком, я понял, что фундаментальный механизм структур данных взят из Си и сделан он такой именно для удобства реализации на Си.

так как былм разработаны и реально применяются варианты Python- а специально для микроконтроллеров. От стандартного Python-а они отличаются например отсутствием GIL, затрудняющего многопоточную обработку

Нет потоков — нет необходимости в GIL.

сомневаюсь, что в Qt прокатит, как минимум из-за их мета-объектного компилятора

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

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

как минимум из-за их мета-объектного компилятора

Сделать что-нибудь своё вместо этого компилятора.

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

Хе. У кого ещё есть стандартизированная спецификация, кроме C,C++ и Ады? Ну, Фортрана ещё (кто сказал Алгол? :) ). И это не мешает плодить реализации.

Мне указывали на это заблуждение и я в нем разобрался. Питон не разрабатывался для >обучения — питон разрабатывался для никсового скриптинга, там он и осел навечно, не >осилив толком ни GUI, ни нормальную работу в виндовой консоли.

Как интеересно… Я первый раз услышал о Питоне из статьи в Журнале Dr. Dobb’s, кажется. за 91 год (плюс 4 – минус 1 год). В этом номере описывались два новых языка — Питон, и почти забытый ныне Icon. Ни слова о служебных скриптах там не было, насколько помнится. А вот об обучении наоборот, было. И да, в этот период «в трендах» была MS DOS и ожидаемая с нетерпением OS/2, но никак не юниксовый скриптинг.

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

Да, конечно. «Батарейки в комплекте». НО готовые решения сделаны на Питоне и Питон сам по себе (объекты + структуры данных) более, чем удобен для «быстренько посмотреть».

По этой же причине питон никогда не разовьется, и даже для введения минимальных >(!) изменений в язык при переходе от второй версии к третьей понадобилось лет 10, >чтобы на это портировали готовые решения.

Очень сильное утверждение. И да, конец портированию всего наработанного даже непросматривается, невозможно это. В этом и проблема. Я вообще не уверен, что введение в язык несовместимых изменений, это очень хорошая идея. Ну вот введение скобок у принт — ну нафига, кому мешало, в чём была сакральная необходимость?

   по факту бесполезные лямбды и сложность написания функционального кода

>>Хорошо бы рассказать это специалистам в области МО, чёй это они кипятком >>писают?

Я не понял тезиса.

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

Всё не так. Python разрабатывался для прототипирования приложений на C++ (в этом не > преуспел) и для замены Perl в веб-приложениях, имея более простой синтаксис. По > >сравнению с Perl оказался более универсальным.

Повторюсь, Как интеересно… Я первый раз услышал о Питоне из статьи в Журнале Dr. Dobb’s, кажется. за 91 год (плюс 4 – минус 1 год). В этом номере описывались два новых языка — Питон, и почти забытый ныне Icon. Perl более – менее зазвездился не ранее 1991,с выходом верблюжей книги. Не бьётся.

варианты Python- а специально для микроконтроллеров.

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

механизм структур данных взят из Си и сделан он такой именно для удобства >реализации на Си.

а на чём ещё его можно было реализовывать на/для персоналках/ок в начале 90-ых?

Хе. У кого ещё есть стандартизированная спецификация, кроме C,C++ и Ады? Ну, Фортрана ещё (кто сказал Алгол? :) ). И это не мешает плодить реализации

https://www.iso.org/ics/35.060/x/

Algol 60, Fortran, Cobol, PL/1, APL, Pascal, Ada, Basic, Modula-2, M/MUMPS, C, C++, C#, Forth.

Поразительно то, что есть стандарт на Ruby:

https://www.iso.org/standard/59579.html

Куцый, конечно, но есть.

Я первый раз услышал о Питоне из статьи в Журнале Dr. Dobb’s, кажется. за 91 год (плюс 4 – минус 1 год)

Минус один не мог быть, потому что питон релизнут в 1991 году. Самая ранняя статья по питону, которую у меня получилось найти — за 1997 год, а это уже довольно поздно.

НО готовые решения сделаны на Питоне

Ошибка номер три: готовые решения сделаны на C/C++, на питоне их предпочитают не писать, а только использовать.

Математики, статистики, специалисты в МО, находят питоновские лямбды вполне удобными и сахар годным

Они вообще ничего не понимают в технологиях программирования, им скорми что угодно — они схавают. Просто, сейчас кормят питоном — вот они и жрут питон. Потому тезис

Мнение целевой аудитории немного более ценно, чем теоретическое недовольство

некорректен, потому что у ЦА нет мнения.

а на чём ещё его можно было реализовывать на/для персоналках/ок в начале 90-ых?

Да хотя бы CMUCL/CLisp. Это было бы еще и весьма просто, потому что CL с питоном очень близки. Чтение сорцов первого питона показывает, что там много чего было позаимствовано из реализации ABC, что на фоне интервью с Гвидо рисует картину «я его слепила из того, что было». То есть, Гвидо взял все известные ему технологии, как то Си, ABC, Icon, и слепил из частей этих языков нового франкенштейна.

компилятор ldc (ldc2) можно заставить выдавать результат в llvm

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

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

кто называет? что общего у cil с интерпретатором и, тем более, с виртуальной машиной?

Он про другое: зачем нужен безопасный Раст с переусложнённым синтаксисом, когда есть ещё более безопасный Хаскель с переусложнённым синтаксисом?

что общего у cil с интерпретатором и, тем более, с виртуальной машиной?

https://ru.wikipedia.org/wiki/Common_Intermediate_Language

CIL — «высокоуровневый ассемблер» виртуальной машины .NET.

«Не читайте перед обедом советских газет»

https://en.wikipedia.org/wiki/Common_Intermediate_Language

Runtimes typically just-in-time compile CIL instructions into native code.

CLI-compatible execution environments also come with the option to do an Ahead-of-time compilation (AOT)

In the .NET Framework there is a special tool called the Native Image Generator (NGEN) that performs the AOT. A different approach for AOT is CoreRT that allows the compilation of .Net Core code to a single executable with no dependency on a runtime.

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

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

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

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

Не совсем понимаю, что должна была сказать эта ссылка. У джавы тоже есть JIT, код на дотнете тоже может модифицироваться в процессе работы (в том смысле, что нельзя сказать, что JIT отрабатывает всего один раз). Так в чём же разница?

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

К любым не знаю, но в D можно использовать манглинг и C, и С++, помимо дишного в виде `extern(C)` и `extern(C++)`. Дишные библиотеки активно используются из-под питона и R - это точно, про остальные просто не знаю.

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

Промежуточное представление есть у всех не тривиальных языков. Оно используется на этапе компиляции для того, чтобы представить исходный код в виде, удобном для дальнейшей обработки. Таких представлений может быть несколько и они используются только во время компиляции. После компиляции (ну и линковки) машинный код уже не подлежит каким-то изменениям и предназначен для непосредственного исполнения на ЦПУ. Байт код это же уже по факту универсальный машинный код, который на ЦПУ выполнятся не может, ему нужна виртуальная машина. Да, есть техники, которые позволяют байт-код преобразовывать в машинный, иногда это дает отличные результаты. Но это не отменяет того, что для использования байт-кода нужно довольно жирная прослойка дополнительного ПО. Иногда просто жирный рантайм. У си рантайм небольшой, у плюсов тоже, у раста такая же история. И у Ди рантайм не жирный.

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

dmd это референсный компилятор, предназначенный для разработки фронтэнда языка, который используется также и ldc, и gdc. dmd очень простой и легкий в установке/сборке. Сборка dmd с нуля занимает несколько секунд(!), не нужно тащить всю инфраструктуру llvm или gcc. Это очень упрощает работу разработчикам. Да у него оптимизатор уступает ldc/gdc - так никто от него этого не ждет. Обычная практика - разработка с помощью dmd и релизная сборка с помощью ldc/gdc. dmd еще и компилирует быстрее чем ldc/gdc. Так что очень удачное разделение ролей между тремя компиляторами. gdc еще пока отстает по версии фронтэнда, но работы ведутся в этом направлении

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

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

Ну как же ложное, если по вашей же ссылке написано черным по белом:

CIL is a CPU- and platform-independent instruction set that can be executed in any environment supporting the Common Language Infrastructure, such as the .NET runtime on Windows, or the cross-platform Mono runtime.

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

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

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

Ну из D нельзя запользовать тот же Qt напрямую

Есть такая возможность. Хотя по мне это больше на костыль похоже, но на практике работает.

Байт код это же уже по факту универсальный машинный код, который на ЦПУ выполнятся не может, ему нужна виртуальная машина. Т.е. для запуска CIL кода нужен JIT компилятор

вы же сами пишете про компилятор, хотя бы и JIT

Т.е. для запуска CIL кода нужен JIT компилятор, который компилирует код непосредственно перед запуском.

ниже по той же ссылке написано про AOT

Вы не можете скопировать на чистую машину CIL код и запустить его там без жирного рантайма.

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

Вот тут то и ключевая разница между D и С#

это так, только вопрос в том, что разница между языком с мощным GC против языка со слабым GC и ручной сборкой мусора; виртуальная машина тут не причём

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

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

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

Так-то была даже gcc версия джавы, и да она была AOT и без виртуальной машины совсем.

вы же сами пишете про компилятор, хотя бы и JIT
ниже по той же ссылке написано про AOT

Ладно, оставим это в стороне, не хочу уходить в детали

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

Библиотеки и рантайм - это разные вещи. Библиотек и у С++ очень много, если не больше всех. Библиотека времени выполнения (runtime library) - это библиотека, которая используется приложениями для своей работы. Она не расширяет возможности приложения (как другие библиотеки), она обеспечивает реализацию определенных возможностей языка. Т.е. без рантайма эти возможности не могут использоваться.

это так, только вопрос в том, что разница между языком с мощным GC против языка со слабым GC и ручной сборкой мусора; виртуальная машина тут не причём

Тут соглашусь

Это библиотека, которая используется приложениями для своей работы. Она не расширяет возможности приложения (как другие библиотеки), она обеспечивает реализацию определенных возможностей языка.

Совершенно верно. Но куцый рантайм просто означает куцую стандартную библиотеку, это значит, что то, что у ПО других языков лежит в рантайме, у С++ и у D лежит в велосипедах. И каждый из этих велосипедов при одновременном использовании жрёт память, в то время как у других языков переиспользуется рантайм.

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

это так, только вопрос в том, что разница между языком с мощным GC против языка со слабым GC и ручной сборкой мусора; виртуальная машина тут не причём Тут соглашусь

Я это всё вёл к тому, что совершенно не очевидно, что C# будет проигрывать по скорости D. Собственно, по дебиановским тестам, C# выигрывал с существеннм отрывом, но там использовали dmd версию, а не llvm. Так что это так себе показатель, конечно.

Совершенно верно. Но куцый рантайм просто означает куцую стандартную библиотеку, это значит, что то, что у ПО других языков лежит в рантайме, у С++ и у D лежит в велосипедах. И каждый из этих велосипедов при одновременном использовании жрёт память, в то время как у других языков переиспользуется рантайм.

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

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

Я это всё вёл к тому, что совершенно не очевидно, что C# будет проигрывать по скорости D.

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

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

Всё-таки наличие хороших учебных материалов много даёт. Мне кажется, что если нет коммерческих авторов желающих этим заниматься, то разработчики языка и/или сообщество должны брать дело в свои руки. Кстати, бесплатность таких материалов ещё увеличивает их привлекательность. Скажем, купить книгу по хаскелю я готов, а по какому-нибудь Nim - нет.

Очевидно, что в некоторых случаях из C# можно выжать производительность не хуже чем из нативно компилируемых

Опять 25:

1. CLI - это просто промежуточный язык, такой же, как llvm.

2. JIT компиляция используется по умолчанию, но не обязательна

=> С# такой же нативно компилируемый язык, как и D.

К слову, в С# тоже есть возможность управлять памятью вручную, без сборщика мусора. https://stackoverflow.com/questions/18172979/deleting-c-sharp-unsafe-pointers Правда, я не стану рекомендовать писать такой код.

Опять 25:

1.CLI - это просто промежуточный язык, такой же, как llvm.

2.JIT компиляция используется по умолчанию, но не обязательна

=> С# такой же нативно компилируемый язык, как и D.

Внимание, вопрос - а зачем тогда нужен CLI и жирный рантайм, если можно сразу компилировать в машинный код? Если на C# можно сразу собирать нативные бинарники, зачем вся эта возня с CLI? Ну и собирали бы сразу как в С++ или D? И не надо было бы рантайм таскать. В чем тогда профит то от жирного рантайма у C#?

а зачем тогда нужен CLI

затем же, для чего промежуточный язык llvm, CLI - полный аналог

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

политика майков - кроссплатформенность бинарного кода по-умолчанию

затем же, для чего промежуточный язык llvm, CLI - полный аналог

Ну это смотря с какой стороны смотреть. По способу использования они очень даже разные. CIL выполняется на виртуальной машине .net. А IR это всего лишь временное представление для облегчения оптимизации. Оно не выполняется нигде и ни в каком виде. IR используется только для обмена данными между частями компилятора, оптимизации и генерации машинного кода.

Отличие в том, что IR не виден пользователю вообще, пользователь получает уже готовый к запуску бинарник. А CIL это как раз то, что поставляется в сборках, и при запуске должна запуститься ВМ или JIT/AOT компилятор, которые будут выполнять этот код/преобразуют его в машинный. Разница налицо. Если код банальная числодробилка, где важна производительность, то нативный код уделает .net как тузик грелку просто за счет отсутствия накладных расходов. В случае нативного языка IR уже скомпилирован, а C# еще должен запустить JIT/AOT, преобразовать CIL в машинный код и только потом запустить этот машинный код на выполнение. Причем в нативных языка компиляция выполняется один раз, а в случае C# - каждый раз при запуске.

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

А CIL это как раз то, что поставляется в сборках, и при запуске должна запуститься ВМ или JIT/AOT компилятор

скажите, вы в курсе, что такое AOT компилятор?

Всё-таки наличие хороших учебных материалов много даёт.

На сайте D есть ссылка на бесплатную книгу, которая должна должна быть достаточно актуальной:

D version: 2.094.2
Book revision:2021-02-2

http://ddili.org/ders/d.en/Programming_in_D.pdf

примеры из книги: http://ddili.org/ders/d.en/Programming_in_D_code_samples.zip

Я сам не читал, так как мне пока не нужен D. Но может кому-то будет интересно…

скажите, вы в курсе, что такое AOT компилятор?

Т.е. по поводу виртуальной машины и JIT компилятора вы согласны, правильно я понял?

Ещё раз: вы в курсе, что такое AOT компилятор?

Ещё раз: вы в курсе, что такое AOT компилятор?

Еще раз: по поводу виртуальной машины и JIT компилятора вы согласны со мной?

Если вы хотите раскрыть какую-то важную на ваш взгляд деталь - так вы не стесняйтесь, раскрывайте.

Я первый спросил.

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

А поводу Jit - он необязателен. С поправкой на это, я согласен. Хотя, это вы тоже уже прочитали.