Разработчики языка программирования D представили (https://dlang.org/blog/2019/03/03/dmd-2-085-0-and-dconf-2019.../) релиз основного эталонного компилятора DMD 2.085.0 (https://github.com/dlang/dmd/), который поддерживает системы GNU/Linux, Windows, macOS и FreeBSD. Код компилятора распространяется (https://github.com/dlang/dmd/) под свободной лицензией BSL (Boost Software License).
Язык D использует статическую типизацию, обладает синтаксисом, схожим с C/C++, и обеспечивает производительность компилируемых языков, при этом заимствуя некоторые полезные возможности динамических языков в области эффективности разработки и обеспечения безопасности. Например, предоставляется поддержка ассоциативных массивов, косвенное определение типов, автоматическое управление памятью, средства параллельного программирования, опциональный сборщик мусора, система шаблонов, компоненты для метапрограммирования, возможность использовать библиотеки на языке C, а также некоторые библиотеки на C++ и Objective-C.В новой версии DMD (https://dlang.org/changelog/2.085.0.html):
* Добавлена поддержка взаимодействия с кодом на Objective-C, позволяющия организовать обращение к классам, переменным и супервызовам, определённым в библиотеках на языке Objective-C. Классы
Objective-C теперь могут быть определены напрямую как классы D, без промежуточных прослоек, достаточно просто указать класс как extern(Objective-C) и использовать атрибут @selector для обращения к методам;- Внесены улучшения в сборщик мусора. В состав DRuntime добавлен новый сборщик мусора (https://dlang.org/spec/garbage.html#precise_gc), реализующий режим тщательного сканирования содержимого кучи
для выявления актуальных указателей или ссылок, указывающих на объекты в куче. Активация производится при помощи опции "--DRT-gcopt=gc:precise").
Кроме того, реализованы опции для управления поведением сборщика мусора при завершении приложения. Доступно два варианта: collect для инициирования сборки мусора при завершении приложения (поведение по умолчанию), none для завершения без чистки и finalize для завершения всех активных объектов без их анализа. Для выбора режима предложена опция "-DRT-gcopt=cleanup:режим". Дополнительно добавлены программные интерфейсы для доступа к статистике сборщика мусора и реализована возможность подключения к runtime собственных сборщиков мусора;- Улучшена совместимость со стандартной библиотекой C++. Добавлен новый DRuntime-модуль core.stdcpp.new_, предоставляющий доступ к C++ операторам new и delete, что позволяет программам на D использовать память, выделенную под кучу для C++. Кроме того, представлен модуль core.stdcpp.allocator позволяющий использовать C++ класс std::allocator для привязки к типам контейнера STL;
- Прекращена поддержка 32-разрядных версий macOS;
Кроме того, в прошлом месяце состоялся выпуск LDC 1.14.0 (https://github.com/ldc-developers/ldc/releases), компилятора для языка D развиваемого на базе наработок проекта LLVM. В новой версии реализованы новые опции компилятора и runtime DMD 2.084.1, добавлена поддержка AddressSanitizer, переработан код компоновки при компиляции в формат WebAssembly.URL: https://dlang.org/blog/2019/03/03/dmd-2-085-0-and-dconf-2019.../
Новость: https://www.opennet.dev/opennews/art.shtml?num=50245
Так и не понял, почему он не взлетел. Всяко интересней ржавчины.
> Так и не понял, почему он не взлетел. Всяко интересней ржавчины.Ему ж Си помешал. Очевидно </!>
Тут ещё опять же такое... Что называть "взлетел". Если все поголовно неистово бросились на D всё переписывать это как бы тоже не самое прекрасное, чего ждёшь.
> Тут ещё опять же такое... Что называть "взлетел". Если все поголовно неистово
> бросились на D всё переписывать это как бы тоже не самое
> прекрасное, чего ждёшь.а почему? D даёт же возможность писать как на уровне Си и ниже там где надо, так и на уровне "лучше подумаем над алгоритмами и/или скоростью написания"
Так-то, если в C надо ниже C, никто не мешает делать в коде ассемблерные вставки.
> Так-то, если в C надо ниже C, никто не мешает делать в коде ассемблерные вставки.так я и говорю что это и в D можно, но в D так же можно и много чего, в том числе "алгоритмично и быстро писать на высоком уровне", чего на C нельзя
>алгоритмично и быстро писать на высоком уровне#include<algorithm>
#include<the stuff you like>В C++ беда не со стандартной библиотекой, а с тем, что большинство компиляторов её не реализовали. То есть, если хочешь использовать стандартную библиотеку, то ты ограничен g++/clang++ + glibc++ под linux, потому что студия как обычно сильно отстаёт, в MinGW-w64 хедеры присутствуют, но при попытке просто их приинклюдить обнаружишь, что в самих хедерах ошибки.
нет покровительствующей корпорации. Впрочем, как и у раста, поэтому он не такой уж и популярный (популярным он кажется исключительно в разделе комментариев опеннета)
Я так понял, на расте пишут в мозилле. Ну и ещё где-то что-то по чуть-чуть. А где и что крупное пишут на D?
Ну глянь на GH - есть движение вокруг, но не на сказать, что проекты крупные или какие-то незаменимые. Опять же один проект даже "незаменимый" не решит ничего. Помнится был единственный мне известный проект на Modula, который реально использовался активно (в среде OS/2шников). Ну да, хорошо. Но никак Modula это не помогло. Полуоси, правда, тоже, но то совсем другая история...
>известный проект на Modula, который реально использовался активно (в среде OS/2шников)э... это какой?
>>известный проект на Modula, который реально использовался активно (в среде OS/2шников)
> э... это какой?Weasel https://ecsoft2.org/weasel
Вот и исходнички (*.DEF, *.MOD)
ftp://ftp.pmoylan.org/Weasel/WeaselSrc_2.54.zip
Weasel v. 2.54 (28/2/2019, Peter Moylan)
(сползает под стол) он ещё и развивается!? Петеру долгого здравия. Упорный гражданин.
>>>известный проект на Modula, который реально использовался активно (в среде OS/2шников)
>> э... это какой?
> Weasel https://ecsoft2.org/weaselа!!! хорошая штука, последний раз использовал в 2001
> Вот и исходнички (*.DEF, *.MOD)
не знал, что он открыт и на модуле. да что там, не знал, что есть модула для полуоси, кроме топ спид модула (топ спид классная вещь, но осталась очень уж в далёком прошлом :(
> ftp://ftp.pmoylan.org/Weasel/WeaselSrc_2.54.zip
> Weasel v. 2.54 (28/2/2019, Peter Moylan)
> (сползает под стол) он ещё и развивается!? Петеру долгого здравия. Упорный гражданин.классно.
> кроме топ спид модула (топ спид классная вещь, но осталась очень уж в далёком прошлом :(Я помню слегка в шоке был, когда выяснил, что совсем уже запредельная по тем временам (для полуоси) штука - Virtual Pascal (VP/2), продаваемая английской конторой разрабатывалась Виталием Миряновым, а "немецкий" Injoy PPP dealer парнем из Пензы.
..блин я ещё что-то помню по полуоси. удивительно...
Deno.js от создателя Node.js, часть написана на расте. Причём раньше эта часть была написана на голанге, но общественность продавила в проект раст.
> нет покровительствующей корпорации.Как раз наоборот проект развивала компания Digital Mars, очень известная в былое время (Zortech C их рук дело). Потом её скупил Symantec и получил права в том числе на код DMD. Так как они все были заядлыми проприетарщиками, код открыли только в последний момент, когда интерес к языку D у сообщества почти полностью пропал.
Семантики - те ещё днища и уб***дки, но я вот не верю, что какие-то мегатонные сорсы помогают популяризации. Вы много разбираетесь в кишках компилеров? А как написан именно Ди? Чтобы въехать в типичные проект, нужно затратить до полугода при полном погружении в разработку, 40 часов в неделю.
К тому же, ну что вам сорсы? Писать свою реализацию goto? :) Сам язык уже стабилен, пиши - не хочу. Всё, что представляло ценность, уже внесено. Либа тоже как бы повзрослела. Но всё ещё нехватает ключевых вещей - ГУИ и СУБД.
> какие-то мегатонные сорсы помогают популяризацииименно их наличие с соотвествующей публичной офертой как бы намекает - написанное с намного меньшей накроется медным тазом лет через пять, когда в компании-разработчике поменяется курс.
> Вы много разбираетесь в кишках компилеров?
в мире порядка 20 млн разработчиков. Есть и те, кто разбирается.
До недавнего времени компилятор был проприетарным и развивался мелкой коммерческой конторой.
https://www.opennet.dev/opennews/art.shtml?num=46354
Зачем ещё один очередной язык со сборкой мусора?
>Зачем ещё один очередной язык со сборкой мусора?акцент на скорости разработки при достаточной надёжности. не очевидно? без сборки есть тот-же с++.
Его погубил "опциональный" сборщик мусора, который многие начали использовать, и он дефакто стал обязательным.
В ражавом его нет.
Он настолько опциональный, что без него BCL не работает.
Чушь не городи! Язык предназначен для написания программ. "Мусор" - последнее, о чём должен думать разработчик.
Его можно просто не творить...
>Язык предназначен для написания программ.
>"Мусор" - последнее, о чём должен думать разработчик.А вот и java кодеры подтянулись.
Со своими hello world в 200 Mb.
(gwm ~) >> cat hello.java
public class hello {
public static void main(String[] args) {
System.out.println("C++ sucks");
}
}
(gwm ~) >> cat hello.c
#include <stdio.h>
int main() {
printf("Java sucks!\n");
return 0;
}
(gwm ~) >> javac hello.java
(gwm ~) >> gcc -o hello.a hello.c
(gwm ~) >> java hello
C++ sucks
(gwm ~) >> ./hello.a
Java sucks!
(gwm ~) >> ls -lh hello.class
-rw-r--r-- 1 gwm users 413 Mar 4 23:23 hello.class
(gwm ~) >> ls -lh hello.a
-rwxr-xr-x 1 gwm users 17K Mar 4 23:24 hello.a413 байтов у неправославной джаву, против 17 килобайтов у правслоного С...
1. Используйте флаги оптимизаций при компиляции С++ (например -Os)
2. Создайте исполняемый файл для java программы (содержит в себе jre), ведь вы для С++ программы создаете исполняемый файл
3. Тогда уже сравните размер
1. не -Os, а -O3 и strip -s
> 1. Используйте флаги оптимизаций при компиляции С++ (например -Os)а что, много сишных программ продолжают после "например -Os" правильно работать?
1. Попробовал. Я видимо (без сарказма) делаю что-то не так, потому-что размер не меняется..
Не судите строго, не Сишник..
(gwm ~) >> gcc -o hello.a hello.c
(gwm ~) >> gcc -o hello.ao3 -O3 hello.c
(gwm ~) >> gcc -o hello.aos -Os hello.c
(gwm ~) >> ls -lh hello.a
-rwxr-xr-x 1 gwm users 17K Mar 6 00:31 hello.a
(gwm ~) >> ls -lh hello.ao3
-rwxr-xr-x 1 gwm users 17K Mar 6 00:31 hello.ao3
(gwm ~) >> ls -lh hello.aos
-rwxr-xr-x 1 gwm users 17K Mar 6 00:31 hello.aos
2. Вопрос был не о размере JRE, а о размере HelloWorld'а на Java, который "весит 200 мб"
> 1. Попробовал. Я видимо (без сарказма) делаю что-то не так, потому-что размер
> не меняется..
% cat hello.c
#include <stdio.h>int main() {
printf("Java sucks!\n");
return 0;
}
% gcc8 -s -O2 -o hello hello.c && ls -lh hello
-rwxr-x--- 1 анонн wheel 4,8K 6 Mar 06:49 hello% ldd -a hello
hello:
libc.so.7 => /lib/libc.so.7% ls -lh /lib/libc.so.7
-r--r--r-- 1 root wheel 1,8M 26 Feb. 16:45 /lib/libc.so.7% ls -lh /boot/kernel/kernel
-r-xr-xr-x 1 root wheel 13M 26 Feb. 23:38 /boot/kernel/kernel
Вот, грубо говоря, все зависимости.
> 2. Вопрос был не о размере JRE, а о размере HelloWorld'а на
> Java, который "весит 200 мб"Не вопрос, если его можно запустить без JRE (который конечно не 200 МБ весит, а "всего" 90 ))
А если не учитывать зависимости, то и тогда:
% echo "#\!/bin/sh\n echo Жаба проигрывает даже шелл скрипту" > hello.sh && chmod u+x hello.sh && ls -lh hello.sh && ./hello.sh
-rwxr----- 1 анонн wheel 81B 6 Mar 06:52 hello.sh
Жаба проигрывает даже шелл скрипту
Запусти, плиз, в java vm нечто вроде
while(1) {
sleep(1);
print("I'm dummy\n");
}и посмотри размер кода и хипа в системе.
Потом улыбнись. =)
>Так и не понял, почему он не взлетел.Потому, что слишком надолго затянулось его включение в состав GCC, а эталонная реализация слишком долго была проприетарной.
> Внесены улучшения в сборщик мусора. В состав DRuntime добавлен новый сборщик мусора, реализующий более быстрый режим выборочного (в зависимости от типов) сканирования содержимого кучи для выявления актуальных указателей или ссылок, указывающих на объекты в кучеОни до сих пор использовали консервативный сборщик мусора, который работает по принципу: просканируем всю память, будто это массив из void*, пометим все объекты кучи внутрь которых найдём ссылки в этом "массиве", а затем удалим все те объекты кучи, которые остались непомеченными. Такой сборщик мусора вполне можно использовать в C программе (google://boehm+gc). И такой сборщик мусора отличается тем, что это самый тормозной вариант сборщика мусора, который при этом не может проводить дефрагментацию памяти, с целью повышения cache-locality данных, или с целью возврата операционной системе неиспользуемых двух гигабайт памяти, которые были разбиты на 100k несвязанных кусочков.
Вряд ли это основная причина, но одна из них точно.
Я боюсь, что 99% ваших программ не нагружают GC и до половины. Зачем тогда гнать эту пургу про производительность?? Сначала напишите что-то тяжёлое, потом уже жалуйтесь на *реальную* проблему. А пока я вижу большинство комментаторов вытаскивает аргументы из носа и пытается оправдать фэйл Ди.
> Я боюсь, что 99% ваших программ не нагружают GC и до половины.Половина -- это в каком смысле? Это когда 50% доставшихся ей тактов процессора программа тратит на сборку мусора? Да элементарно, вот смотри, я сейчас пишу программу, чтобы натягивать звуковую дорожку с одного видеофайла на другой, при необходимости растягивая эту дорожку или сжимая, потому что один из файлов имеет покорёженную ось времени. Для этого я декодирую первый файл, перебирая кадры, находя там ключевые, потом второй файл. Потом сопоставляю две последовательности кадров, строю отображение оси времени второго файла на ось времени первого, ну и дальше режу звуковую дорожку на кусочки и каждый кусочек немного растягиваю или сжимаю. Я не знаю, сработает это или нет, но это не суть, в данном случае.
Так вот, давай представим себе, что я декодируя видеофайл выделяю под каждый новый кадр новый кусок памяти. Некоторые куски я сохраняю, но большинство я выкидываю обратно в кучу. Понятно, что можно было бы не выкидывать, а использовать повторно, но, во-первых, задача-то в том, чтобы убить программу сборщиком мусора, а не реализовать максимально эффективно, а во-вторых, при ручном вызове free на ненужные кадры, это будет иметь несущественное влияние на производительность, на фоне декодирования кадров и сравнения последовательных кадров на предмет различий.
В случае же GC, доступное место в куче будет уходить в ноль постоянно. И сборщик мусора будет постоянно искать мусор. И это может быть не очень страшно было бы с generational сборщиком мусора, такой сборщик мусора по-крайней мере гарантировал бы мне постоянство задержек, как бы много кадров я не обработал. Но консервативный будет при каждом запуске сканировать каждый мой сохранённый кадр, ища в rgb данных указатели. Как думаешь, сколько мне надо набрать кадров в оперативке, чтобы программа 50% времени проводила бы за сборкой мусора?> Зачем тогда гнать эту пургу про производительность?? Сначала напишите что-то тяжёлое,
> потом уже жалуйтесь на *реальную* проблему.Речь не о "реальной" проблеме, а о причинах фейла D. Разные проекты и особенно начинания часто фейлятся не из-за "реальных" проблем, а из-за какой-нибудь совершеннейшей фигни. Скажем сам факт того, что в D есть сборщик мусора, является очень серьёзной преградой для перетягивания C и C++ программистов в D. И не потому, что сборщик мусора не позволит этим программистам решать их задачи, а потому что у них голова не приемлет идеи. "Реальная" ли это причина? Я не знаю как ты отвечаешь на этот вопрос, я отвечаю положительно: я уверен, что она реально повлияла на успехи D в привлечении программистов.
Как гугл со своим Go боролся с этой проблемой? Он лил программистам в уши маркетингового буллшита: https://blog.golang.org/go15gc
Но начал он с того, что действительно реализовал конкурентный, трёхцветный, mark'n'sweep для Go. Тоже позорный gc, но всё ж не консервативный, и при этом они реально добились снижения задержки. Но суть в том, что Google сначала реализовал, а потом включил генераторы буллшита. D не льёт в уши буллшита и не реализовывает хороший сборщик мусора. Безнадёжно.
а зачем заведомо делать по приниципу "назло бабушке отморожу уши"?>Речь не о "реальной" проблеме, а о причинах фейла D.
никакая реклама + реальные проблемы при развитии экосистемы. ещё 5 лет назад порог вхождения, из-за недоработок, был ну очень крутой.
Плюс литературы очень мало (зы: заканчиваю книжку, принимаю пожелания :)
> Разные проекты и особенно начинания часто фейлятся не из-за "реальных" проблем, а из-за какой-нибудь совершеннейшей фигни.
да.
>Скажем сам факт того, что в D есть сборщик мусора, является очень серьёзной преградой для перетягивания C и C++ программистов в D.
да. да.
> И не потому, что сборщик мусора не позволит этим программистам решать их задачи, а потому что у них голова не приемлет идеи. "Реальная" ли это причина?
триста раз, да. но и отказ от мусорщика неприемлим: тогда лесом идёт идея быстрой разработки.
>аргументы из носа и пытается оправдать фэйл Ди.как показывает практика, если нет рекламы --- (быстро) взлетает только на пустой площадке. или не взлетает вообще.
> как показывает практика, если нет рекламы --- (быстро) взлетает только на пустой площадке. или не взлетает вообще.я не знаю какая реклама может быть у компилятора. это не ирония, не сарказм - вот без подвоха. я подозреваю - с пяток крупных проектов, хорошо используемых, хорошо реализованных, имеющих явные и очевидные преимущества. но даже такое на мой взгляд - не гарантия.
D (опять как мне кажется) сильно помешало то, что уже тут описано: пляски вокруг сырцов и позднее включение в GCC (например в генту его включили и потом выкинули. можно даже посмотреть за что)
Я бы мог назвать десяток причин :) Но проблема в том, что даже их устранение не гарантирует взлёт.1. Совсем никакая роль в коммерческом девелопменте. Используй его хотя бы 3-5 средних фирм, можно было бы смело брать хотя бы "на попробовать". Все боятся.
2. Вообще никакая работа в сторону наиболее востребованных компонент: GUI, Database. Те ГУИ-поделия, что есть, либо убогие врапперы (что как бы юзабельно, но ставит крест на любой расширяемости), либо такие чухонские поделия, что в продакшен такое просто стыдно ставить. Либо багов много. Дизайнер ГУЯ отсутствует как класс. Нет настоящей, нативной библиотеки, которая бы использовала Ди в полный рост (за счёт чего и выигрывала бы у других языков). Причём ей даже не надо быть "мультиплатформенной", к чёрту эти линynсы - пусть даже Win32, но на самом низком уровне - без использования вендовых отрыжек.
А СУБД - там вообще уже плесенью покрытый модуль, который ещё и поддерживает не всё. А без СУБД на сервере делать нечего - одна из главных причин, почему "не взлетает" даже у энтузазистов.
3. IDE. Опять же, есть жалкие попытки одиночек, есть "прикрученные сбоку" к другим редакторам, но вот такой, чтобы прям "насквозь Ди" - их нет. Есть довольно паршивенький плагин к VS, который безбожно тормозит и не делает и половину необходимого.
4. Доки - тоже больное место. Пока язык развивался, Александреска вроде что-то там написал, но много воды. Нужна "продвинутая" книга для тех, кто уже знает C++/C# и хотел бы перейти на Ди, сразу получив отличия языков или особенностей ООП в Ди - тогда дело пойдёт быстрее. Документация по самой библиотеке - вообще автогенерённый шлак, даже MSDN и то иногда отличается в лучшую сторону.
5. Большая инертность прогеров. Лучше они будут получать по лбу 100 раз от любимой сипипишечки, чем 10, но от непонятного языка, к которому надо привыкать. И непонятно кого винить - сам накосячил или язык такой или ещё чего. Раздражает и отпугивает.
6. Огромное количество либ на замшелых сях-сипипях. Куда проще дописать свой си-код к существующему проекту, чем прикручивать сбоку Ди, компилять отдельно, собирать, править make... Весь этот легаси-отстой ещё долго будет мотивом не переходить на современные языки. К слову, фэйл Го-Растов обусловлен и этим тоже.Ну вот как-то так. Сам с удовольствием смотрю на Ди, что-то изучаю, но написать даже простую визуальную приблуду - не могу, потому что без гуя она нафиг не нужна, а юзать отстой, который даже не обновлялся 3 года - не хочу тратить время впустую.
дигиталмарсу надо очень серьёзно подумать, сесть и сделать хотя бы каркас ГУЁВ, без них язык просто обречён.
Что сабж взлетел, нужна популяризация от харизматических личностей. Таких, таких как Керниган-Ритчи для С и Страуструп для С++. Ждем книгу такого же уровня.
>Дизайнер ГУЯ отсутствует как класс.Это достоинство.
Ага, все программы должны быть консольными, а компьютерами пользоваться исключительно сертифицированные специалисты.
Сравнение D, Go и Rust от самого Александреску:https://www.quora.com/Which-language-has-the-brightest-futur...
> Сравнение D, Go и Rust от самого Александреску:Спасибо, интересное сравнение.
Интереснее rust, вы серьёзно? С опциональным (на самом деле нет) gc он никому не интересен, и из фичей rust в нём нет ничего.
Потрудитесь раскрыть тему конкретнее, чем же это он "Всяко интересней ржавчины."?
А то похоже на "пук в муку" от очередного анонимного иксперда.
Не поленитесь и еще раз посмотрите Rust. Называть D интереснее как минимум необразованно.
этот D уже лет 20 делают, но бесполезно;
лучше бы они вложили силы в развитие C++;
> этот D уже лет 20 делают, но бесполезно;
> лучше бы они вложили силы в развитие C++;Cи++ уж надо не _раз_вивать, а скручивать, сворачивать, завивать, сжимать и обратно "в бутылку" упихивать.
не то чтобы... но усилий на его причёсывание надо чудовищное количество
почему?
> почему?потому что Си(++) это главная ошибка современного IT-человечества
из разряда "ну прям щас надо хоть как-то, но не на асемблере, мы же обязательно скоро сделаем нормальные инструменты"собсно как и JavaScript
есть сомнения, что D - это главная ошибка
С++ мёртв ещё и потому, что неуклюжий синтаксис, приемлемый _для_Си_ и в 70-ые, раздражает нас, адекватных людей из 201*ых :) Точнее, помимо кракозябр самого Си, туда ещё и классы нахлобучили. Хуже того - любой компилятор С++ полагается на какие-то эмпирические правила, ибо язык не имеет однозначной грамматики. И на этом кто-то отчаянно пишет...
С и С++ совершенны. До такой степени, что все остальное неприемлемо.
На счёт Си соглашусь, а вот СиПлюсы - нет.
>потому что Си(++) это главная ошибка современного IT-человечествавряд-ли.
скорее, этот инструмент просто начинает трещать под собственной тяжестью.
Потому, что он пытается повторить "успех" языка PL/1. Который тоже был сильно распухшим.
> Потому, что он пытается повторить "успех" языка PL/1. Который тоже был сильно распухшим.а чем D распухший?
Это про нынешний C++.
Потому что в С++ постоянно приходится добавлять const&
До сих пор не понимаю - чего все ноют про новые стандарты? Не нравится - бери и пиши на ANSI C++.
А как прикажете, разбираться в чужом коде на C++2x ?
Иногда удобнее написать свой код, а не разбираться в чужом.
Иногда это невозможно
> сжимать и обратнополучить Си!
Не дожимать до некуда, чтобы получить C с классами.
"Cи++ уж надо не _раз_вивать, а скручивать, сворачивать, завивать, сжимать и обратно "в бутылку" упихивать."Очередной умник-неосилятор.
С++ и так замечательно развивается, без неадекватов со "своим путём".
>В состав DRuntime добавлен новый сборщик мусора, реализующий режим полного сканирования содержимого кучи для выявления актуальных указателей или ссылок...GC-precise - "вернувшийся" режим работы GC с НЕполным сканированием памяти на "фальшивые" указатели. А вот conservative режим (по умолчанию) как раз сканирует ВСЕ выделенные блоки на указатели. Так что теоретически precise работает быстрее.
Говоря проще, если есть выделенный блок памяти new long[1_000_000], то conservative режим будет его сканировать на указатели, а precise - НЕ будет.
>Классы Objective-C теперь могут быть определены напрямую как классы D, без промежуточных прослоекВот бы для классов Qt также. Жизнь бы стала просто малиной.
C++
> поддерживает FreeBSDА там об этом знают?
http://www.freshports.org/search.php?query=dmd
> dmd1 Official compiler for the D 1.0 programming language
> No package is available: No redistribution of non validated binaries|
> dmd2 D 2.0 compiler, not officially validated for FreeBSD
> 2.073.2 lang
> BROKEN: fails to build
> IGNORE: is marked as broken: fails to build
>
Это Дэ ещё более бесполезное, чем ржавчина. На той хоть 2 процента огнелиса написано, а на Дэ вообще ничего.
> Это Дэ ещё более бесполезное, чем ржавчина. На той хоть 2 процента
> огнелиса написано,Вы хоть раз в год методичку бы обновляли
https://4e6.github.io/firefox-lang-stats/
C++ 28.3%
JS 25.7%
С 14.2%
Rust 6.8%
Это какая-то пропагандистская агитка. Там даже жаба зачем-то есть, когда в реальности её нет.
У Firefox весь пользовательский интерфейс на JS.
JS и Java - это совершенно разные языки. У JS с Java примерно столько же общего, сколько с Си.
> Это какая-то пропагандистская агитка. Там даже жаба зачем-то есть, когда в реальности
> её нет.Может жаба ради всяких андроидов?
Есть она там, как минимум часть кода под андроид написана на java
Вот почему FF такой безобразный продукт - намешали г**вна бочку, а теперь пытаются ещё и взлететь.
ОДИН язык должен быть у проекта. Остальные три вообще ничем не оправданы.
Там ещё HTML и CSS - с ними как?
А они уже стали языками программирования?
Здрасти посрамши. Уже лет десять как.
Да, это декларативные языки программирования. Подучите матчасть.
>Это Дэ ещё более бесполезное, чем ржавчина. На той хоть 2 процента огнелиса написано, а на Дэ вообще ничего.и?
ты сам пробовал? и убедился, что для *твоих* целей, этот инструмент бесполезен, не нужен и неспособен принести ощутимую выгоду?нет? а зачем тогда ты обворовываешь сам себя?
ещё раз, д и раст -- не конкуренты. у них разные цели: д --- быстро пишем, компилятор пытается не дать получить дырявый код,
раст -- пишем долго, может быть, матеря сами себя. зато никаких ошибок, поддающихся обнаружению во время компиляции, быть не должно. надеемся...
Плохо, что у D нет виртуальной машины.
Не для сэндбоксинга, а чтобы не компилировать программу на 100500 платформ. По аналогии с JVM. Типа, DVM.
Можно, конечно, вытворять вот такое вот:
https://stackoverflow.com/questions/44550353/dlang-llvm-erro...
> Можно, конечно, вытворять вот такое вот:
> https://stackoverflow.com/questions/44550353/dlang-llvm-erro...не знал про lli, спасибо, интересно
LDC2 даже уже собранный распространяется под множество платформ. Я правда не пробовал использовать его подобным образом (lli + druntime + phobos + программа в виде ll). https://github.com/ldc-developers/ldc/releases/tag/v1.14.0
>lli is not an emulator. It will not execute IR of different architectures and it can only interpret (or JIT-compile) for the host architecture.Блин.
>Плохо, что у D нет виртуальной машины.D с виртуальной машиной, называется C#
И хотя у дотнета скорее рантайм нежели виртуалка, в общем-то да.
От Александреску ждали улучшения крестов, а он сделал новый шарп, только по своему и как-то странно.
Почему александреску? Автор языка Walter Bright
Довёл до 1.0 и продолжил развивать именно Александреску. И сборщик мусора лежит на нём.
Можно запускать через шебанг:
https://tour.dlang.org/tour/ru/welcome/run-d-program-locally