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

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

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

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

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

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

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

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

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

тестового редактора нет

Всё может изменится:

https://github.com/xi-editor/xi-editor

https://github.com/atom/xray

https://github.com/Wilfred/remacs туда же.

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

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

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

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

Только вот 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. Ты не мог бы оформлять цитаты нормально?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Так понятно?

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

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

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

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

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

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

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

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

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

Так понятно?

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

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

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

Классика: vim, emacs

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

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

Минусы Qt переходит с qmake на CMake (комментарий)

Плюсы на главной rust-lang.org

Но так как мне нужна альтернатива плюсам, то с ним и сравниваю.

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

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

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

Ок, спасибо.

Специально для вас:

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

В ответе мне вы процитировали другого человека.

Так понятно?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что интересно, в отличие от Go и Rust для D есть таки готовое нативное кроссплатформенное GUI! https://github.com/buggins/dlangui (нативное в смысле не обёртка над widget тулкитом)

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

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

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

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

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

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

Там только маленький кусочек на нем... и то для пиара Раста я думаю написали.

Пол года назад там было 2 ляма строк. Совсем маленький кусочек.

Это сколько от общего объема? процентов 10 или меньше?

процентов 10

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Трейты раста тоже тьюринг полные, но я не уверен что это однозначно плюс.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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