LINUX.ORG.RU

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

 


3

8

GCC 9.1 будет первым стабильным релизом с поддержкой GDC.

Его выход ожидается приблизительно в конце первого квартала 2019 г.

Код для поддержки GDC включает библиотеку libphobos (D run-time library) и фреймворк для тестов D2.

Поддержка D потребовала внесения изменений в приблизительно 1 миллион строк кода.

>>> Подробности



Проверено: jollheef ()
Последнее исправление: maxcom (всего исправлений: 2)

Ответ на: комментарий от yetanother

Но вы то как раз фанбой Раста.

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

Иначе чего бы вам тут доказывать, в теме про включение Ди в гцц, что Ди хуже Раста?

И где я такое говорил? Я лишь спросил о преимуществах, которые я получу перейдя с Rust «для драйверов» на «божественный» D. Но так ничего внятного и не услышал.

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

А вы не вырывайте фразы из контекста. Речь шла про три языка. Из которых Go занимает порядка 80-90%. При этом D не то что бы 1% - его вообще нет.

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

Речь шла про новые проекты, а не легаси на сишке.

RazrFalcon ★★★★★
()
Последнее исправление: RazrFalcon (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

Я лишь спросил о преимуществах, которые я получу перейдя с Rust «для драйверов» на «божественный» D. Но так ничего внятного и не услышал.

Так тут никто не называет Ди божественным. В отличие от вас, который называет элементы Раста божественными:

Я молюсь на эту фичу. В том же C++, инициализация структур - боль.
Не менее божественная фича. Какие тут могут быть ошибки - не ясно.

Это же ваши комментарии по поводу Раста. В теме про включение D в gcc. Вы конечно можете отрицать, что вы не фанбой Раста, но люди то все видят.

yetanother ★★
()
Ответ на: комментарий от glebiao

Только вот ADT нет, печаль
как нет?

Просто нет.

Разверните мысль, пожалуйста.

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

Чем именно они гибче?

свойства (включая .stringof).

Ок.

полная интроспекция для любого типа.

Это применимо где-нибудь, кроме CTFE? Потому что CTFE - это не часть системы типов.

явный тип делегата

Я никогда не мог понять, что такое «делегат» (все называют этим словом слегка разные сущности), но если это что-то вроде std::function в Си++, то в Rust это, конечно же, есть - Fn traits: https://doc.rust-lang.org/book/second-edition/ch13-01-closures.html

интерфейсы (у производных пользовательских типов)

Это лучше, чем traits в Rust?

применимость квалификаторов типов (const, immutable, (inout) (shared)) к любому типу

Не уверен, что const, shared и immutable в D являются именно частью _типа_, ну да ладно. За исключением ненужного inout не нужен, остальное есть и в Rust.

преобразование типов

Ну это смешно. Преобразования типов есть примерно везде.

и возможность преобразования immutable/mutable shared/non-shared только при строгом выполнении безопасных условий

immutable может внезапно стать mutable shared? O_o IIRC, immutable нельзя преобразовать вообще никуда.

P.S. Ты не мог бы оформлять цитаты нормально?

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от yetanother

Так тут никто не называет Ди божественным

Перечитайте посты glebiao.

Это же ваши комментарии по поводу Раста.

Конечно мои. Но обратите внимание, что я пишу про себя, а не про всех.

В теме про включение D в gcc.

Это ЛОР, детка. (с)

RazrFalcon ★★★★★
()
Ответ на: комментарий от tailgunner

Только так и верно. Потому что в D _нет_ ADT. Средствами D можно изобразить что-то похожее.

Нет в языке, но есть в библиотеке. Еще раз повторю - поддержка ADT в Rust безусловно лучше и качественнее. Но говорить, что ADT в D/С++ просто нет - это преувеличение.

yetanother ★★
()
Ответ на: комментарий от yetanother

Но говорить, что ADT в D/С++ просто нет - это преувеличение.

Но их нет. Есть обычный tagged union прямиком из сишки. Но почему-то никто не говорит, что в Си есть ADT.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Перечитайте посты glebiao.

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

yetanother ★★
()
Ответ на: комментарий от yetanother

Нет в языке, но есть в библиотеке.

Да не вопрос - в библиотеке есть ADT, но языком он не поддерживается, а речь шла именно о наличии ADT в языке. Насчет библиотечных ADT - так можно сказать хоть о Си, хоть о Паскале, не говоря уже о Си++.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от yetanother

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

Так понятно?

RazrFalcon ★★★★★
()
Ответ на: комментарий от tailgunner

Да не вопрос - в библиотеке есть ADT, но языком он не поддерживается, а речь шла именно о наличии ADT в языке. Насчет библиотечных ADT - так можно сказать хоть о Си, хоть о Паскале, не говоря уже о Си++.

Именно это я и имел в виду.

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

yetanother ★★
()
Ответ на: комментарий от yetanother

языком он не поддерживается, а речь шла именно о наличии ADT в языке. Насчет библиотечных ADT - так можно сказать хоть о Си, хоть о Паскале, не говоря уже о Си++.

Именно это я и имел в виду.

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

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

Фраза «просто нет» звучит вполне подходяще для «нет в семантике языка».

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

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

Так понятно?

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

yetanother ★★
()
Ответ на: комментарий от RazrFalcon

Претензий к расту у меня полно, поэтому фанбоем себя назвать не могу.

Можешь озвучить тезисно +/- руста? Субъективно.

Hertz ★★★★★
()
Ответ на: комментарий от RazrFalcon

В ответе мне вы процитировали другого человека. Будьте внимательнее, пожалуйста.

Симметрично.

Вы решили толсто потроллить? Или это сбой форума?

yetanother ★★
()
Ответ на: комментарий от glebiao

стесняюсь спросить, какой современный компиялятор какого современного языка, этого НЕ поддерживает?

не надо стесняться

о как. а ещё он выводит бородавки, да?

морщины точно, чувствуешь себя моложе динозавров с++

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

ты просто не успел получить выгоду из-за того что стеснительный

rust_afari
()
Ответ на: комментарий от RazrFalcon

А, теперь понял. Т.е. вы считаете, что фраза glebiao о том, что шаблоны (что там обсуждалось) в D и Rust отличаются «Тем, что происходит откат к существенно менее совершенной структуре, которую осилили компиляторостроители.» равносильна фразе что D божественный? Вы серьезно это утверждаете?

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

yetanother ★★
()
Ответ на: комментарий от yetanother

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

Обычно у технарей есть чувство юмора. Но, возможно, ты являешься исключением.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

Все кто читал последнюю пару страниц прекрасно видят, что Ди никто не восхвалял ни в каким виде. В отличие от того, что фанбой Раста его в прямом виде назвал божественным. Это что, юмор у вас такой? Придти в тему другого языка и шутить таким образом? Хм, ну тогда да, я явно не обладаю чувством юмора в твоем понимании. И никогда не хотел бы обладать таким чувством юмора как у растофанов.

yetanother ★★
()
Ответ на: комментарий от eao197

Все просто: раньше свидетели Rust-а срались с C++никами. Со временем C++никами это надоело и срачи Rust vs С++ сошли на нет. Но свидетелям Rust-а недостает новых адептов, вот они и приходят с проповедями в любую, как им кажется, подходящую тему.

Справедливости ради, накидывали на С++, Python, Go, но накинуть на Rust эффективнее всего для вывода темы про D в топ, т.к. на это прибегут все вышеперечисленные. xD

anonymous
()
Ответ на: комментарий от glebiao

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

Очевидно, конечно. Впрочем, так же, как и любая современная денежная система.

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

anonymous
()
Ответ на: комментарий от glebiao

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

Тем, что это не шаблоны.

О да. Тем, что происходит откат к существенно менее совершенной структуре, которую осилили компиляторостроители.

Простите, что вклиниваюсь в дискуссию. А можно в двух словах, в чём основные отличия между дженериками раста и шаблонами ди?

anonymous
()
Ответ на: комментарий от Virtuos86

Да уж. От фанатиков, как обычно, вреда для репутации языка больше, чем пользы.

anonymous
()
Ответ на: комментарий от RazrFalcon

Фанбоев тут только два. И я не в их числе.

Если что-то ходит как утка и крякает как утка, то... Ну, ты понял. Не хочешь, чтобы тебя называли фанбоем, так не веди себя как фанбой.

anonymous
()
Ответ на: комментарий от anonymous

Простите, что вклиниваюсь в дискуссию. А можно в двух словах, в чём основные отличия между дженериками раста и шаблонами ди?

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

anonymous
()
Ответ на: комментарий от RazrFalcon

И где я такое говорил? Я лишь спросил о преимуществах, которые я получу перейдя с Rust «для драйверов» на «божественный» D. Но так ничего внятного и не услышал.

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

Int64 ★★★
()
Ответ на: комментарий от Int64

А вот и свидетели ООП подтянулись. Пора выводить тему в топ.

RazrFalcon ★★★★★
()
Ответ на: комментарий от gag

готовое нативное кроссплатформенное GUI

Не готовое и не нативное.

RazrFalcon ★★★★★
()
Ответ на: комментарий от anonymous

Почему на Расте не пишет даже Мозилла?

Разве не пишет? А зачем тогда файрфокс для компиляции требует наличия раста?

anonymous
()
Ответ на: комментарий от glebiao

поздравляю. вообще-то, Лисп всегда позиционировался как язык, программы на котором должны писать *программы*, а не люди.

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

Быстрота и лёгкость разработки лучше чем у D

это неверно. достаточно просто посмотреть, насколько быстро исправляются ошибки и недочёты в лисп (и аналогах) программах

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

писать легко. понять написанное и поддержать — сложно.

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

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

Gentooshnik ★★★★★
()
Последнее исправление: Gentooshnik (всего исправлений: 1)
Ответ на: комментарий от Gentooshnik

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

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

anonymous
()
Ответ на: комментарий от Gentooshnik

Cтранно, по моему опыту как-раз в долгосрочной перспективе лиспы начинают выигрывать ещё сильнее у плюсоподобных

Это не опыт, а фантазия. Применение всех видов Lisp-а очень ограниченно, поэтому опыту взяться неоткуда.

Похоже, это та же проблема что и с Tcl.

С TCL проблема в том, что он давно стал не нужен и уже забыт. А раз нашлось, чем его заменить, значит нет проблемы.

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

То есть, вы считаете себя умнее всех. Бывает. Хотя чаще всего этим страдают юные энтузиасты, только что узнавшие о языке Haskell и воображающие, что составят на нём гениальную программу, как только научатся программировать. Но и Lisp для этой фантазии подойдёт.

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

Фантазия. Вы удивитесь, но некоторые популярные языки не имеют макросов. Например, Java.

Сравнение Lisp и D лишено смысла. D иногда применяется и иногда может заменить собой C/C++. Lisp почти не применяется, а если бы применялся, то не для замены C/C++, для которой он непригоден.

Сравнение D с C, C++ и Rust имеет смысл. Но не надо приплетать к обсуждаемой теме Lisp.

Partisan ★★★★
()
Ответ на: комментарий от vlad9486

Если нет других средств метапрограммирования то конечно в плюс. Но при наличии нормальных макросов скорее ненужно.

anonymous
()
Ответ на: комментарий от yetanother

Что же вы проигнорили все, что было написано после «А если серьезно»? Я для вас повторю: быстрота чтения - еще не есть быстрота понимания. Вам что важнее, быстрее прочитать, или быстрее понять?

freecoder
()
Ответ на: комментарий от freecoder

Я для вас повторю: быстрота чтения - еще не есть быстрота понимания.

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

Что касается сигнатур функций, то сообщаю вам что эти сигнатуры перегружены информацией, которая полезна когда вы пишете драйвер. Но абсолютно ненужна, когда вы решаете задачу динамического программирования. Как там в классике - есть корм трех видов, у каждого свой набор полезных веществ и своя цена. Для максимального набора веса каждое животное должно получить минимальный набор полезных веществ. Нужно составить оптимальный рацион для того чтобы животноводческий комплекс показал наибольшую прибыль. Где здесь вы видите место для скоупа переменной `c`? Его здесь нет вообще, и именно это одна из причина почему Питон взлетел. Потому что там не нужно читать то, что не относится к задаче. Так что для каждой задачи свой инструмент, и где-то нечитабельность Раста и полезна, но чаще - она лишняя. Как сказал Александреску - в Расте в жертву одной фиче (безусловно полезной, но лишь одной) принесено практически все.

yetanother ★★
()
Ответ на: комментарий от yetanother

Ну как вы себе представляете чтение, в процессе которого вы ничего не понимаете? Что это за чтение?

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

Опять же, типы - это не только детали реализации, это также сущности, которые относятся к логике работы программы. Именно так их и нужно использовать. А всякие Питоны не позволяют этого делать, при этом время от времени заставляют программиста таки думать о типах, когда выясняется их несоответствие во время выполнения.

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

Что же касается синтаксиса. Может быть в Rust он и не идеален, но хотя бы он свободен от предрассудков, будто бы самый удобный синтаксис для описания программ это такой, который будет похож на литературный текст. Давайте мы еще и от математических обозначений откажемся и будем доказывать теоремы в повествовательной форме. Посмотрим, как изменится продуктивность математиков от этого. Зато любому филологу будет радостно читать такие математические тексты. Только понимать их от этого легче не станет: что компактно умещалось в строку и целостно схватывалось ранее, теперь будет размазано по всему тексту.

freecoder
()
Ответ на: комментарий от freecoder

Вы несколько однобоко воспринимаете термин «понимание». Есть понимание на уровне что делает функция и понимание на уровне как она это делает. В хорошо организованном проекте используется несколько слоев абстракции, например у меня обычно 3-4 слоя. Что-то типа бизнес-логики высокого уровня, бизнес-логики низкого уровня и просто нижний уровень. На первых двух уровнях идет работа исключительно в терминах предметной области и программист со стороны вообще ничего не поймет. Только на третьем уровне есть работа в терминах computer science. Вот на этом самом третьем уровне сложность сигнатур на уровне Раста может быть полезной. Все. На первых двух уровнях она излишняя 100%. Она несет информацию, которая на этих уровнях абстрации является не нужной. Ну и напоследок - кода в первых двух слоях абстракции намного больше чем в третьем. И при правильной организации проекта третий слой пишется в самом начале и потом редко расширяется и еще реже модифицируется по сравнению с первыми двумя. И в этом контексте перегруженность сигнатур функций в Расте для меня очевидна.

В лучшем случае тебе придется прочитать и понять само тело функции.

Если нужно понять как функция работает, то без этого никуда. Вы никогда не сможете затащить в сигнатуру тот же объем информации что и в теле функции. Так что это не аргумент.

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

Это проблема дизайна проекта и растовые сигнатуры функции тут вам никак не помогут. Это тоже не аргумент.

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

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

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

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

Что же касается синтаксиса. Может быть в Rust он и не идеален, но хотя бы он свободен от предрассудков, будто бы самый удобный синтаксис для описания программ это такой, который будет похож на литературный текст.

Ну а зачем вы передергиваете? Где я написал что программа должна быть похожа на литературный текст? Это ваши выдумки.

yetanother ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.