Язык D включен в коллекцию компиляторов GNU (gcc 9)

А это не ИИ. Это бум подгоночных моделей

Неистово плюсую. В данном случае «ИИ» — баззворд в чистом виде.

Ok. Тогда поясни, ты Gentooshnik'а одобряешь или осуждаешь, за то, что он «осилил в
конце концов Common Lisp» чтобы писать на нём «наколенные поделки» (вместо D,
насколько я понимаю).

поясняю. одобряю? нет осуждаю? тоже нет.

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

верю, что товарищу удастся оставаться целиком и полностью в рамках Лисп? не-а.

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

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

PS:

: Gentooshnik BEGIN «Всему в мире есть своё время и место!» . AGAIN ;

Gentooshnik

форева! :)

Ясно, спасибо. Я-то для себя интересуюсь, на чём писать наколенные поделки. В плюсы точно не полезу, а вот Common Lisp и D вполне интересны.

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

Раст и Ди --- языки с очевидно разными базовыми целями

Не считая GC, оба для системщины и частично для прикладного кода.

Для достижения этой цели пришлось отказаться от напластований C++ и в большой степени, совместимости с С++.

При этом пилят совместимость с плюсами. Зачем?

Зубодробительный синтаксис в хакерском стиле

Наша песня хороша...

Для драйверов и крайне ответственного кода (хотя, чем хуже Ада?) — отлично, ждём, пока взлетит.

Там намного больше вкусностей, чем один memory safety.

а есть хотя бы одна вакансия на D в России?

Раст и Ди --- языки с очевидно разными базовыми целями

Не считая GC, оба для системщины и частично для прикладного кода.

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

системщина, ну надо же...

Зубодробительный синтаксис в хакерском стиле

Наша песня хороша...

я неправ?

Там намного больше вкусностей, чем один memory safety.

да нисколько не сомневаюсь (кстати, огласите весь список).

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

хм. на днях в телеграм канале dlang.ru кинули ссылку на вакансию в моём городе. удивительное рядом...

При этом пилят совместимость с плюсами. Зачем?

взаимодействие с накопленным кодом. неочевидно?

Раст не ставит целью быструю разработку с легкочитаемым кодом

А D ставит? Это же не скриптота в конце концов.

высоким доверием к компилятору

Шта?

я неправ?

Если забыть про лайфтаймы/макросы - то обычный Си-подобный язык.

кстати, огласите весь список

• zero-cost abstractions
• move semantics
• guaranteed memory safety
• threads without data races
• trait-based generics
• pattern matching
• type inference
• minimal runtime
• efficient C bindings

этот баланс и есть самое сложное

Кто же спорит. Только не похоже, что это про D.

Зубодробительный синтаксис в хакерском стиле

Наша песня хороша...

я неправ?

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

Я видел одну на одном анонимном форуме. Обещали конечно немного, но тем не менее - хотя бы одну я видел.

Писать на Расте *всё* --- не кажется хорошей идеей. Зубодробительный синтаксис в хакерском стиле --- прикольно, но имхо, очень быстро станет слишком дорого (трудоёмкость!).

Странное мнение. Математический язык тоже имеет «зубодробительный синтаксис» с точки зрения филолога. Но ведь задачи у этого языка отличные от литературных.

Раст не ставит целью быструю разработку с легкочитаемым кодом

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

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

Really? Perl6? Можно подробнее

Ну если выбирать между D и Perl6, то почему бы и нет. :)

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

А за это время ты уже женился развелся дети пошли в институт...

И бац, учить программированию будут на знакомом языке :)

Вот теперь и думайте стоит ли этим заниматься.

Твоего сына с институте. Вместо С++. А он «Пап, почему тут так убого сделано?». И легаси аргумент не прокатит.

а к Go какие претензии?

а к Go какие претензии?

GENERICS

Проще спросить, к чему в Go нет претензий. Пожалуй, нет их только к реализации CSP-шной модели в языке.

Я с вами согласен, но с другой стороны своей цели язык достиг - это просто язык для джуниоров. Если бы еще была возможность с гоу легко перейти на язык мидлов или сеньеров это было бы вообще хорошая вещь. Но нет, джуниоры так и останутся на гоу писать простой код.

Нет претензий к простоте сборки компилятора, генерации быстрого нативного кода, отсутствию зависимости от стандартных glibc, высокой скорости компиляции, элементарной кросскомпиляции, быстрому gc.

Замечательно, что у вас нет претензий к инфраструктуре вокруг языка. Особенно когда вы пытаетесь сравнивать Go не с D, а с С++.

Но я говорил о претензиях именно к языку.

Кроме того, ряд тезисов из вашего списка для меня вообще не релевантны. Например, «простота сборки компилятора» и «быстрый GC». Поскольку никогда не было надобности собирать компилятор самому. Ну вот вообще, от слова совсем.

Да и «скорость GC» — это какой-то странный фетиш, ибо если вам нужна скорость и предсказуемость, то GC здесь вообще не причем. Если вам нужен GC, то речь не про скорость и предсказуемость. Хотя, может вы просто сравниваете Go не с D, а с Python-ом или Ruby. Ну или говорите про скорость написания кода, а не скорость его работы.

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

Раст не ставит целью быструю разработку с легкочитаемым кодом

А D ставит? Это же не скриптота в конце концов.

D --- ставит. Это одна из заявленных целей. Скриптота --- как ласково, однако. Каждому средству --- своя ниша. И делать сценарии на компилируемом языке --- можно, но нужно ли (по крайней мере, всегда ли нужно)?

Между прочим, программу на D можно запускать именно как классический скрипт, с компиляцией на лету.

Если забыть про лайфтаймы/макросы - то обычный Си-подобный язык.

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

> zero-cost abstractions

кто этого не обещает? только вот ЗИРО не выпадает и н евыпадает. печаль...

move semantics

опять: разве эта абстракция не стала общим местом? вообще, удивительно. *костыль*, подсказка компилятору (именно так, ну нет абстракции перемещения на уровне двоичного кода ни в одном из известных процессоров (за Эльбрус не скажу, не в курсе), выдаётся за священный Грааль.

guaranteed memory safety

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

D достигает примерно тех-же целей за счёт пометки кода @safe и @trusted, с ужесточением проверок. Посмотрим, какой подход лучше и какой компилятор покажет лучшие, в этом смысле, результаты.

threads without data races

реклама. Все этого хотят. D тоже обещает. Вопрос в цене.

trait-based generics

Чем это лучше шаблонов D?

pattern matching

Чем это лучше выноса на уровень библиотеки (с возможностью расширения без исправлений в компиляторе)? Кстати, реализация регекспов в D имела (возможно, и имеет) некоторый баг: при некоторых условиях, компилятор не мог справится с кодом, так как начинал жрать память, как не в себя (реализация работает на этапе *компиялции*, порождая оптимальный автомат). Не уверен, что более сложная задача сравнений по образцу в общем виде, да ещё на уровне компилятора, не будет страдать подобными багами.

type inference

чем это отличается от того, что есть в D и вообще говоря, в C++ старше 14?

minimal runtime

Вот это хорошо. Смотрим.

efficient C bindings

Чем это отлично от существующих языков? И кстати, в D *полная* совместимость с C (за исключением, пардон за тавтологию, внимательности и вообще говоря, необходимости принятия мер при исключениях).

Итого, остаются только ДВА действительно существенных свойства:

* безопасность по памяти * минималистичный рантайм.

Вывод: отличный, перспективный вариант для драйверов и особо ответственного кода. Как вариант, способный занять нишу D (быстрая разработка на компилируемом языке с /достаточной/ надёжностью), пока не представляется имеющим достаточную перспективу. *Пока*, хайпа больше, чем реальных успехов. Напомню, что D (второй версии), без особого шума, пилят уже больше 11 лет, большинство младенческих болячек уже прошли. Пилят люди, собаку съевшие на построении реальных, промышленных компиляторов и теории. И тем не менее, до сих пор имеются весьма неприятные моменты.

этот баланс и есть самое сложное

Кто же спорит. Только не похоже, что это про D.

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

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

Про GC --- всё-таки, сборщик мусора, видимо, необходим для обеспечения лёгкости разработки и уменьшения ошибок по памяти. Касательно D --- была статья Ольшанского о неудовлетворительной работе существующего GC в D (я её переводил, https://yadi.sk/i/dftROrt33KLww6 ). Насколько ситуация с того времени улучшилась, не могу сказать, сам на проблемы с мусорщиком не наступал.

Странное мнение. Математический язык тоже имеет «зубодробительный синтаксис» с точки зрения филолога. Но ведь задачи у этого языка отличные от литературных.

Не имеет. Средний филолог заявляет, что у него нет способностей к математике (как правило, следствие лени или/И не вполне удачных учителей), но признаёт, что язык математики шлифовался веками и вполне адекватен своим целям (не будем трогать тонкие отличия, принятые у чистых математиков и физиков — теоретиков, которые иногда, не понимают друг друга, а первые жалуются, что вторые применяют инструменты, которые не понимают :) .

Rust-не читатель, Rust - писатель ) Можно улучшать читаемость, жертвуя скоростью написания, а можно улучшать написуемость, жертвуя читаемостью.

Бред, конечно. Таких языков и без Раста с Ди было, есть и будет --- целое болото. В том-то и цель, дать достаточно ясный и компактный язык, подходящий для современной разработки, сохраняющий лёгкость написания и чтения.

А если серьезно, то самое нечитаемое место в Rust - это сигнатуры функций, использующие

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

про излишнюю многословность в криптостиле

О чем это?

pattern matching

Чем это лучше выноса на уровень библиотеки (с возможностью расширения без исправлений в компиляторе)? Кстати, реализация регекспов в D
регекспов

Хм. Pattern matching - это, по твоему. регэкспы? Это многое объяснило бы.

Хм. Pattern matching - это, по твоему. регэкспы? Это многое объяснило бы.

нет, но регекспы --- частный случай со схожей реализацией.

Хм. как быть с вызовом деструкторов?

Не проверял, но вроде как реализовали в 2.081.0

но ведь для получения полноценной, не урезанной, Ди — программы, требуется (по крайней мере, сейчас) существенно больше влинкованного (в т.ч. библиотечного) кода. Да ещё пока ещё вызывающий известные нарекания сборщик мусора...

Ну это типичное заблуждение. Не требуется больше кода, просто пока линкуется весь доступный код и поэтому его много. Но в ldc уже есть средства избавиться от лишнего в виде --gc-sections Да, некоторые плюшки завязаны на сборщик мусора. Но сборщик мусора не обязателен. Просто не используйте его или используйте в некритичных местах. Ведь и на С++ если вы внутри нагруженного цикла будете выделять память - ничего хорошего не будет.

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

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

Pattern matching - это, по твоему. регэкспы? Это многое объяснило бы.

нет, но регекспы --- частный случай

Тоже неплохо.

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

А получится «просто» не использовать его? Еще когда я следил за D, уже говорили, что стандартная библиотека завязана на сборщик мусора.

Еще когда я следил за D, уже говорили, что стандартная библиотека завязана на сборщик мусора.

Там вроде не только stdlib, но и часть языковых фич на GC завязана, например, лямбды (делегаты).

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

Что из себя может представлять D вообще без GC можно, наверное, определить по такой странной штуке, как betterC: https://dlang.org/spec/betterc.html

А получится «просто» не использовать его? Еще когда я следил за D, уже говорили, что стандартная библиотека завязана на сборщик мусора.

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

Что из себя может представлять D вообще без GC можно, наверное, определить по такой странной штуке, как betterC: https://dlang.org/spec/betterc.html

Ну, по сравнению с Си, это просто счастье - дженерики, CTFE, RAII. Кстати, лямбды с делегатами тоже есть. А вот стандатной либы похоже нет. Не назвал бы это «просто».

Что из себя может представлять D вообще без GC можно, наверное, определить по такой странной штуке, как betterC: https://dlang.org/spec/betterc.html

Трудно всем угодить) Кто-то жалуется, что в Ди есть рантайм и сборщик мусора, а когда появляется подмножество Ди без рантайма и сборщика мусора - его обзывают странным))

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

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

Конечно это может быть не удобно.

Конечно, это будет неудобным, я гарантирую это на 146%.

Кстати, лямбды с делегатами тоже есть.

Они перечислены, но т.к. в D-шных лямбдах не capture list, как в C++, то не очень представляю себе как они в лямбдах захватывают только то, что нужно. И как затем управляют временем жизни захваченных объектов.

Я забыл про nogc еще. Но да, простого и отшлифованного способа выключить гц в Ди нет.

а когда появляется подмножество Ди без рантайма и сборщика мусора - его обзывают странным))

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

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

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

Да просто выяснилось, что много где объективно гц не нужен/не возможен. Например на мк.

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

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

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

Да просто выяснилось, что много где объективно гц не нужен/не возможен. Например на мк.

Тогда там просто не нужен D. Есть другие варианты, как современные, так и не очень: С++, Ada, Rust.

Но вот D вообще по большому счету мало где нужен. Поэтому хоть куда-то нужно его воткнуть. Пусть и без GC.

Тогда там просто не нужен D. Есть другие варианты, как современные, так и не очень: С++, Ada, Rust.

Ну не соглашусь полностью. Мета возможности D намного лучше оных у c++, про Ада и Раст промолчу, так как не знаю их. И иметь всю эту мощь на мк более чем полезная вещь - вы можете в компайл-таме построить оптимизированную структуру данных под конкретные условия и все это в виде вменяемого кода. Шаблонный код у плюсов не сильно лучше читается чем код Раста, это снаружи буст/стл приятно выглядит, а как внутри вы и без меня знаете. Ну и никто не планирует втыкать D куда-то. Нет такой задачи у разработчиков. У разработчиков есть свои задачи которые они решают и для их решения они используют D. Потому и нет хайпа у D - люди его просто используют. Да и кто из технарей будет заниматься продвижением языка? А D развивается именно технарями и для технарей.

Ну не соглашусь полностью.

Да это сколько угодно.

Мета возможности D намного лучше оных у c++

А вы попробуйте продвинуть хотя бы C++ в среде матерых embedded-разработчиков. Они вас закидают гнилыми помидорами только за одно упоминание C++. И отдельно за упоминание C++ных шаблонов (хотя мало кто из них вообще имеет представление о шаблонах и связанных с ними накладных расходах).

Что уж тут про D говорить.

Ну и никто не планирует втыкать D куда-то. Нет такой задачи у разработчиков.

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

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

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

То есть массовости написания проектов на rust нет и в ближайшем будущем не ожидается. Да и утверждать что у них популярнее, ничем не подтвердив, странно

продолжай игнорить тренды, кто-то и биткоины считал пирамидой...

А вы попробуйте продвинуть хотя бы C++ в среде матерых embedded-разработчиков. Они вас закидают гнилыми помидорами только за одно упоминание C++.

Прекрасно понимаю и согласен с вашей оценкой ситуации. Но это в первую очередь социальный фактор, а не технический.

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

Ну так если вам инструмент подходит - берите и пользуйтесь, а если не подходит - не пользуйтесь. Делов-то. Хайпа у Ди не будет никогда, надеюсь. Зачем вам хайп? Одного универсального языка как раньше С и потом С++ уже не будет. Их будет множество и вам нужно просто выбрать что вам подходит больше. Когда вам нужно забить гвоздь, вы же не ищете в интернете какой инструмент модный на сегодня для забивания гвоздей, а какие молотки маргинальные. Если молоток делает то, что вам нужно вы просто берете и забиваете гвоздь. Биндинги вам придется делать на любом языке, если это не родной. Но в Ди как раз это проще и эффективнее сделать. Ну а то, что Ди это не изкоробочный продукт - ну так это понятно. В этом то и сила его - без корпоративной поддержки язык развивается. В условиях такой высокой конкуренции это означает высокий потенциал языка. Его тут хоронят, хоронят, а он бац - и в гцц принят. А это реально большой шаг вперед.

Зачем вам хайп?

Чтобы в язык приходили люди и делали инструментарий (библиотеки хотя бы).

Вот у Rust-а есть хайп и библиотеки для него пилят. Понятное дело, что многие потом зачахнут, но если из 10K сторонних библиотек умрет затем 9K, то это сильно лучше, чем если из 1K сторонних библиотек умрет 900.

Чтобы в язык приходили люди и делали инструментарий (библиотеки хотя бы).

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

Один грамотный технарь-интраверт вам сможет написать то, что 20 социально активных студентов не напишут никогда.

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

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

Это в принципе не может работать. Невозможно заранее предсказать, что конкретно будет нужно в будущем, какие именно библиотеки.

Тут лучше 10К библиотек, из которых 1К окажутся «грамотными и практическими», чем ровно 1К «грамотных и практических» библиотек.