Разработчики коллекции компиляторов GCC объявили (https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html) о принятии решения по включению в число поставляемых в составе GCC компиляторов фронтэнда GDC (Gnu D Compiler) и runtime-компонентов, необходимых для сборки программ на языке программирования D (http://dlang.org/index.html).
Процесс включения поддержки языка D в GCC начался (https://www.opennet.ru/opennews/art.shtml?num=28607) ещё в 2011 году, но затянулся (http://dconf.org/2017/talks/buclaw.pdf) из-за необходимости приведения кода к соответствию требованиям GCC и проблем с передачей прав на интеллектуальную собственность компании Digital Mars, развивающей язык программирования D. Проблемы с интеллектуальной собственностью были достаточно быстро решены, но для решения технических проблем и синхронизации разработки с компилятором DMD потребовалось почти полностью переписать GDC.
Язык D использует статическую типизацию, обладает синтаксисом, схожим с C/C++, и обеспечивает производительность компилируемых языков, при этом заимствуя некоторые полезные возможности динамических языков в области эффективности разработки и обеспечения безопасности. Например, предоставляется поддержка ассоциативных массивов, косвенное определение типов, автоматическое управление памятью, средства параллельного программирования, опциональный сборщик мусора, система шаблонов, компоненты для метапрограммирования, возможность использовать библиотеки на языке C, а также некоторые библиотеки на C++ и Objective-C.URL: https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=46739
>опциональный сборщик мусораопционально отключаемый же
попробуй отключить его для стандартных либ
Давно не следил, но стандартную либу в этом плане правили. мроблема с том, что GC обеспечивает непоторые довольно важные плюшки, вроде бесплатных слайсов массивов. Но на этот счёт были варианты какие-то.
> GC обеспечивает непоторые довольно важные плюшки, вроде бесплатных слайсов массивов.Но зачем, если есть языки с бесплатными слайсами массивов без GC?
Нет их. И быть не может, во всяком случае, в общем виде. Либо слайс будет не бесплатным, а refcounted (что в многопоточной среде даалеко не бесплатно) либо его время жизни будет явно ограничено.А вот примерно так оно используется: https://www.reddit.com/r/programming/comments/6bt6n/why_is_d.../ - ссылка древняя, и сейчас дишный XML-парсер вряд ли самый быстрый в мире, да и Tango уже выкинули. Но сама техника живее всех живых.
Есть: rust.
Не оно ни разу. Растовская borrow semantics сильно ограничивает использование слайсов. Сделать десяток (возможно перекрывающихся, возможно мутабельных) слайсов и сохранить их в разных объектах с неопределённым временем жизни rust не даст. То есть заставит копировать массив там, где этого можно избежать.
А нахрена его отключать, пиши сразу на сишке. D и хорош тем, что это по сути "компилируемая жава".
> А нахрена его отключать, пиши сразу на сишке. D и хорош тем,
> что это по сути "компилируемая жава".[Саммоним в тред Главного Эксперта Опенета по Джавве, iZEN-а.] iZEN, вы-хо-ди!
Этот ваш D умеет инклюдить сишные хидеры и использовать оттуда функции и структуры?
Вроде бы умеет, но только сишные (без С++ шаблонов).
Может использовать сишные и плюснутые библиотеки, как раз переписав хидеры. Для гиков можно использовать в коде ассемблерные вставки.
Программы компилируются очень быстро, да и по быстродействию не проигрывают сишным. Но исполняемые файлы получаются увесистые, так как тянут сборщик мусора.
Немного устаревшая информация насчёт увесистых. Они получались увесистые не потому, что тянут сборщик мусора, а потому что shared libraries не использовали. Как минимум для линукса было пофикшено пару лет назад: https://stackoverflow.com/questions/31366010/why-d-program-e...
Мне очень нравится D, но размер исполняемых файлов явно его слабая сторона. Shared libraries не спасает: размер поставки (bin+phobos.so) будет еще больше, чем для статики. Потребление памяти для простых приложений в любом случае очень сильно завышено (в сравнении с C).ИМХО основная проблема, что по-прежнему линкер не может выкинуть основную массу мертвого кода. Где-то было обсуждение этой проблемы, но сходу ссылку не найду.
Есть еще страница (http://digger.k3.1azy.net/trend/), на которой отслеживалась тенденция размера исполнимых файлов в зависимости от версии, но что-то у меня она ошибку выдавать стала.
На 32-битной платформе libphobos.so занимает 6 мегабайт. Учитывая, что это всё же общий рантайм, я никакой проблемы не вижу ни для чего кроме каких-нибудь сборок OpenWRT.Насчёт потребления памяти - в первой паре тестов, которые мне попались, всё вполне прилично: https://github.com/kostya/benchmarks и https://togototo.wordpress.com/2013/08/23/benchmarks-round-t.../
Надо бы ещё поискать, но как-нибудь потом.
Минимальный пример:D:
import std.stdio : writeln;
import core.sys.posix.unistd : usleep;void main() {
writeln("test");
usleep(10000000);
}
C:#include <stdio.h>
#include <unistd.h>void main() {
printf("test");
usleep(10000000);
}Размер бинарника (после strip): C - 5.4K, D - 312.6K.
Потребление памяти:
Private + Shared = RAM used Program
412.0 KiB + 147.5 KiB = 559.5 KiB test_d
68.0 KiB + 68.0 KiB = 136.0 KiB test_cДля больших программ разница будет несущественна. А вот когда пишешь небольшие системные утилиты - как-то жирновато.
Нет, я всё понимаю когда люди изнывают, что нужно ради одной софтины тащить пол гига жвм, но чтобы из-за 300 кб у кого-то проблемы возникали...Кстати, попробуйте с -betterC компилировать, для любителей микробинарей как раз делался.
> Нет, я всё понимаю когда люди изнывают, что нужно ради одной софтины
> тащить пол гига жвм, но чтобы из-за 300 кб у кого-то
> проблемы возникали...Зачем ориентироваться на худшее, а не на лучшее? KolibriOS в 1.5 MB вкладывается. Rockbox (почти полностью на C) - 500-600 KB. Я не понимаю почему простой вывод строки на экран должен весить столько же. На uC я могу написать драйвер LCD и вывод на него на C и это будет меньше 1 KB.
ИМХО при таком раскладе системное программирование (а также IoT и прочий embedded) так и останется на C.
> Кстати, попробуйте с -betterC компилировать, для любителей микробинарей как раз делался.
Да, но это уже будет не D, а именно better C.
Потому что важны затраты усилий и риски возникновения ошибок, в том числе в ходе поддержки. Для эмбеда - это одно соотношение ввиду слабости применяемого железа (кстати, судя по всему это скоро свой эффект потеряет). Для "большого" программирования - совсем другое, там пара сотен килобайт - совершенно копеечная цена за удобство.Кроме того, ваше сравнение вообще некорректно - я не думаю, что на C вы напишете драйвер для LCD в 1кб, используя стандартную библиотеку, тем более - десктопную. Максимум - что-то вроде musl.
P.S. Не знаю, чем вы там собирали, но при сборке вашего примерчика для 32-х бит dmd 2.0.74.0 я получил бинарник в 18376 байт, по top virt/res/shr= 9432/3706/3620. Динамическая линковка, разумеется.
Сишный пример вышел 6932 байта, 2156/512/460. Разница, конечно, есть, но отнюдь не такая катастрофичная, как в вашем примере. И тоже динамика, статика весит 720168 байт.
> Для эмбеда - это одно соотношение ввиду слабости применяемого железа (кстати, судя по всему это скоро свой эффект потеряет).Не факт. Производители по-прежнему хотят минимальной себестоимости. К примеру на новых плеерах Sansa памяти на порядок меньше, чем на старых, тоже с новыми китайскими SoC (RKnano*). На роутерах/модемах/etc тоже незаметно бурного роста свободных ресурсов. Опять же - рост производительности пагубно сказывается на времени автономной работы (при одном и том же технологическом процессе).
Только на смартфонах идет бурный рост, так как гигабайты и ядра вполне неплохо можно впаривать обывателям.
> Для "большого" программирования - совсем другое, там пара сотен килобайт - совершенно копеечная цена за удобство.
Согласен, поэтому все равно свои проекты пишу на D.
Sucless сообщество тоже когда-то рассматривало D - удобнее C и нет переусложненности C++, но по-прежнему они пишут проекты на C: st - 59K, dwm - 38.7K.
> P.S. Не знаю, чем вы там собирали, но при сборке вашего примерчика
> для 32-х бит dmd 2.0.74.0 я получил бинарник в 18376 байт,
> по top virt/res/shr= 9432/3706/3620. Динамическая линковка, разумеется.dmd-2.072, 32 бита, статика. О размере динамики нет смысла говорить без учета libphobos.so, так как полученный бинарник без нее не работоспособен.
> Сишный пример вышел 6932 байта, 2156/512/460. Разница, конечно, есть, но отнюдь
> не такая катастрофичная, как в вашем примере. И тоже динамика, статика
> весит 720168 байт.А для gdc все будет еще печальнее.
ИМХО на самом деле проблема может оказаться гораздо серьезнее: сейчас нет крупных библиотек для D, кроме phobos. Но что будет потом, когда они появятся? Не будет ли этой же проблемы, но в другом масштабе?
На железе, где потребление ресурсов напрямую влияет на себестоимость, а обновление проблематично, можно себе позволить потратить больше на разработку и оптимизацию, отбив удешевлением устройства. На десктопе/сервере выгоднее потратить ресурсы железа, но выгадать в скорости/качестве/стоимости разработки (тут уж кому что важнее). Вот об этом соотношении речь.Ну вот сишная статика у меня вышла 700 кб, стрип не забывал, так что какие-то странные разногласия у нас.
Для gdc - да, будет печальнее, он вообще слегка отстаёт от остальных двух. Я так понимаю - в последнее время стало лучше.
Но всё же я не понимаю этой боязни шаред либ - это ж амортизированные расходы получаются, если мы считаем, что D таки будет применяться - выходит совсем мелочь, учитывая, что 6 мегабайт сейчас и так совершенно незаметны на десктопе.
Насчёт дубущих библиотек - полагаю, особо резкого роста размера не будет. Здесь скорее есть какой-то минимум, а дальше нарастание идёт довольно плавно. Хотя может кто-то совсем с шаблонами заиграется, конечно... Но такие проблемы логично решать по мере поступления, причём чаще - в плане архитектуры самой библиотеки.
> На железе, где потребление ресурсов напрямую влияет на себестоимость, а обновление проблематично,
> можно себе позволить потратить больше на разработку и оптимизацию, отбив удешевлением
> устройства. На десктопе/сервере выгоднее потратить ресурсы железа, но выгадать в скорости/качестве/стоимости
> разработки (тут уж кому что важнее). Вот об этом соотношении речь.Как я уже сказал - с этим согласен и для десктопных приложений использую D именно поэтому.
> Ну вот сишная статика у меня вышла 700 кб, стрип не забывал,
> так что какие-то странные разногласия у нас.Это косяк glibc. Но ее как раз выгоднее использовать как shared, так как она используется практически всеми приложениями. Phobos наоборот - будет использовать одно-два приложения, так что выигрыша от shared не будет, скорее наоборот.
Если взять musl (http://www.etalabs.net/compare_libcs.html) то статика будет около 13K. Для D к сожалению пока ничего подобного нет.
> Но всё же я не понимаю этой боязни шаред либ - это
> ж амортизированные расходы получаются, если мы считаем, что D таки
> будет применяться - выходит совсем мелочь, учитывая, что 6 мегабайт сейчас
> и так совершенно незаметны на десктопе.Да, просто не люблю необоснованных затрат.
> Насчёт дубущих библиотек - полагаю, особо резкого роста размера не будет. Здесь
> скорее есть какой-то минимум, а дальше нарастание идёт довольно плавно. Хотя
> может кто-то совсем с шаблонами заиграется, конечно... Но такие проблемы логично
> решать по мере поступления, причём чаще - в плане архитектуры самой
> библиотеки.ИМХО dead code elimination должен работать максимально эффективно на уровне компилятора/linker'а, не требуя тучи #ifdef (или его эквивалентов).
> Для gdc - да, будет печальнееСегодня похоже добили баг с ожирением из-за TypeInfo (https://forum.dlang.org/post/qswoxnddbowkzpqqhcow@forum...). Возможно теперь разрыв между gdc и dmd сократится.
H. S. Teoh говорит, что жирность phobos связана с чрезмерной зависимостью модулей друг от друга (https://forum.dlang.org/post/mailman.2794.1496351236.31550.d...), но я по-прежнему не понимаю: почему компилятор не может сам определить мертвый код?
> быстродействию не проигрывают сишным. Но исполняемые файлы получаются увесистые, так как
> тянут сборщик мусора.Дело не в сборщике мусора, там тянется много несколько неожиданных вещей,
типа рантаймовой поддержки интроспекции и т.п. имхо, с этим можно мириться: скорость И простота разработки + скорость исполнения, перевешивают недостаток толстоватых бинарников.При динамической линковке, размер бинарника вовсе не получается катастрофическим.
Нет, так как сишные макросы не умеет (и правильно), да и система типов не совпадает. Для простых случаев есть тулза для трансформации, но правильный вариант - сделать нормальный модуль с вменяемым API. Собственно, основная идея D - "C++ done right", в первую очередь - без сишного легаси.А вот сишные функции использовать, разумеется, может - при условии, что они соответствующим образом объявлены.
"Сделать нормальный модуль с вменяемым API" - для чего? POSIX API? Или kernel-to-userspace API? Язык позиционирует себя как язык системного программирования, но мне надо воспроизвести половину системных инклюдников чтобы открыть банальный raw-сокет?
транслированные хидеры libc и так в комплекте. Но как раз сокет - хороший пример того, что лучше завернуть в класс, как минимум - чтобы иметь его закрытие в деструкторе. Так и сделано.Не беспокойтесь, там довольно много "батареек включено". http://dlang.org/phobos/index.html в помощь, если интересно.
Есть утилиты-трансляторы заголовочных файлов в дишные модули. Так дофига биндингов к сишным либам наделано.
Лучше всё же написать, что примерно каждый первый надо руками дочищать, так как в них макрос на макросе обычно, зависящие от того, Что определено во включающем файле. Да и нюансы с типами строк и подобным тоже автоматом не переведёшь. Но да, основную массу работы делает, да.
Хорошая новость=)
для полного фарша в GCC ещё Limbo добавить и будет совсем конанично. и да, ржавые напряглись! :)
Ждём gcc-rust :-D
Уже есть https://www.opennet.ru/opennews/art.shtml?num=38576
вот этот коммит мне нравится :-) :-)https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=349ea0af3752bfb...
Ну вот примерно так и GDC в 2011-м был ;-)
гццуст
> гццустGC-crust же. //~джи си краст
[jargon]:
GC
/G.C/
[from LISP terminology; Garbage Collect]
[...8<...][mueller7]:
crust
[krʌst]
1. _n.
1) корка (хлеба); _перен. средства к существованию; to earn one's crust
[...8<...]
>> Ждём gcc-rust-D- Сильно...
Многие вещи в Go взяты из Limbo. А Go сейчас - последний язык в этой цепочке (Newsqueak - Alef - Limbo - Go). Так что в каком-то смысле уже есть.
Кому интерфейсы с С++ нужны могут взять https://github.com/Syniurge/Calypso/ он даже Qt собирает.
> Кому интерфейсы с С++ нужны могут взять https://github.com/Syniurge/Calypso/ он даже Qt
> собирает.Класс. Вот этом может взлететь.
>Процесс включения поддержки языка D в GCC начался ещё в 2011 году, но затянулся из-за необходимости приведения кода к соответствию требованиям GCCGNU-бюрократия затормозила прогресс на шесть лет
>>Процесс включения поддержки языка D в GCC начался ещё в 2011 году, но затянулся из-за необходимости приведения кода к соответствию требованиям GCC
> GNU-бюрократия затормозила прогресс на шесть летgcj выкинули наконец. патчи free pascal только для gcc 4.3. Камрады _борются_ !
Там основной была синхронизация разработки с DMD. GDC/LDC долго сильно отставали.
> Там основной была синхронизация разработки с DMD. GDC/LDC долго сильно отставали.а сейчас GDC/LDC по поддержке фич (и качеству генерируемого кода ?) на сравнимом уровне с DMD ?
LDC или GDC лучше брать при ознакомлении с D в каком-нить своём простеньком проекте ?
Для ознакомления на простеньком проекте - вообще всё равно какой из них брать, они давным-давно практически вровень. DMD чуть впереди, но совсем чуть. По генерируемому коду LDC был получше, насколько я помню, но оно от задачи зависит, так что если всерьёз надо выжать всё, что можно - лучше мерять.
Если нужны все самые свежие фичи сиюминутно закомиченные в мастер ветку — dmd. Если нужен компилятор с нормальным оптимизатором и готовы недельку другую подождать свежих фич — ldc.gdc долго заброшенный стоял, и только сейчас резко начал обновлятся, стоит подождать прежде чем его использовать, кроме кpacноглaзия это ничем хорошим не грозит.
dmd генерит не самый оптимальный код.
ldc значительно лучше но до последнего времени в предкомпилированной поставке
не было динамической версии стандартной библиотеки, так что компиляция была
только в статику.последний gdc, похоже, делает хороший код, но багзилла полна.
по скорости компиляции dmd быстрее ldc быстрее gdc.
Добавьте, что по самому качеству кода компилятора dmd первый - в нём, как правило, в первом исправляются баги и он по-прежнему является эталоном.Но за исключением каких-то совсем уж серьёзных проектов всё это не прицнипиально совершенно, можно любой из трёх брать.
Поскольку FSF не любит C++, то, может, полюбит D. Идея для Gtk'шников - переписать Gtk на D и убить двух зайцев. 1) Помочь взлететь языку, использовав в популярном тулките. 2) Поправить пошатнувшииеся позиции Gtk, переписав его на настоящем ОО ЯП.
Идея отличная. Но на дишечке итак делается dlangui, проще тогда уже его доводить до конкурентноспособного состояния.
dlangui делается одним человеком, это любительский проект.
Gtk же штука покрупнее. Плюс, насколько я понял - в dlangui парсится строка текста как разметка, а очень хотелось бы описание интерфейса компайлтаймовым языком, как в Vibe.d diet-шаблоны описываются.
Я бы сказал, что Gtk - штука сильно покрупнее, чем вообще надо для GUI.А что пишется одним человеком - ну много чего так начинается, можно линуксовое ядро вспомнить ;-) Впрочем, идея D как гнушного базового языка в любом случае сомнительна. У них большинство архитектурных решений как-то странно принимается, у какой-нибудь Scheme и то больше шансов будет.
P.S. Судя по гитхабу их там всё же четверо. А вещь на вид неплохая, пригодится.
У dlin_hui название лучше.
Гномеры уже активно на Rust переползают, так что вряд ли.
откуда инфа?
http://lmgtfy.com/?q=gnome+rust
Тут не только и не столько в расстановке кроватей проблема.
(Как-то натыкался на такой проект) D программы быстро собираются поэтому вполне можно писать и скрипты на нем.
Скрипты с типизацией и с ООП? Да ну к черту вас.
Ты с джавой перепутал. ООП здесь не страшнее, чем в том же питоне. Можно и в чисто процедурном стиле свой код писать.Типизация - auto в помощь. Переменные объявлять придётся, но для скрипта больше, чем в пять строк, это только плюс. А если больше 50 строк - типизация резко становится полезной.
В скрипте не нужно ооп, типизация и python. Либо вы не совсем понимаете значение термина "скрипт".
В скрипте на пять строк - не нужно (хотя не мешают). В чём нибудь вроде скрипта бэкапа или для сборки строк на 400 - уже помогают. В скриптах вроде тех, которыми я в своё время музыку с торрентов в стандартный для себя формат преобразовывал (а там и парсинг метаданных, и генерация каталога и прочее) - уже очень к месту. Там, правда, перл был. Классы в скриптах, конечно, никто не пишет, а вот то, что библиотечные функции удобно сгруппированы по модулям/классам - гуд.
> Скрипты с типизацией и с ООП? Да ну к черту вас.на D есть такой замечательный проект, поддержка программирования в скрипотовом стиле.
легко писать "скрипты" на D практически в питоновском ключе.так что, вполне.
Python - это сильно "не первый сорт", поэтому очень зря ориентиро на него.
>Python - это сильно "не первый сорт", поэтому очень зря ориентиро на него.И что первый? PowerShell?
Если Python не первый сорт для клея, то я даже не знаю что тогда.
> Если Python не первый сорт для клеяРазве что нюхательного.
Скрипты можно и на Си писать, если уж так хочется - tcc.
Можно. Но жутко неудобно и полно страданий
Попробуйте Pike. Это как раз для "писать скрипты на Си" ...
Ты его используешь? Поделись впечатлениями.
Опоздали.Есть Nim и использует GCC как надстройка по умолчанию не дожидаясь включения.
А как решается вопрос о совмещении 1005000 компиляторов в одном?
(Я не техническую сторону вопроса имею в виду а организационно-управленческую: как это происходит - пишется стандарт взаимодействия, cогласовывается АPI, определяется политика? Может, проще разрабатывать не сам компилятор а специальный документ, описывающий математически верифицируемый и расширяемый общий интерфейс всех частей такой программы а также - грамматики описания поддерживаемого языка и налагать лицензионные ограничения свободного и открытого кода на всех кто им решит воспользоваться этими наработками в своих разработках. При этом остальные части программ пишут те, кому это нужно. Иначе компилятор "gcc" не осилит никогда даже поддержку и первых 150, по распространённости, языков программирования).
Назови хотябы 35 широкоиспользуемых компилируемых языков
> Назови хотябы 35 широкоиспользуемых компилируемых языковЭто сделать не получится - потому что, наверное, большая часть их ещё не создана, но будет создана кем то и когда то в будущем - под возникшие потребности.
Уже сейчас, разным оценкам, в настоящее время существует от двух с половиной до десяти тысяч различных языков программирования: если понимать язык как инструментальное средство труда под названием "программирование", то можно сказать, что это аналоги инструментов труда, самых разнообразных - от самопальных, до профессионального заказного инструмента и оснастки для машиностроительных заводов.
И всё это придётся поддерживать с минимальными усилиями - во имя работы унаследованного кода (ситуация с Коболом в банках сейчас или будущие горы археологического кода на Java).