Dlang VS Rust

Самим еще не надоело постоянные срачи разводить на тему «Rust vs <lang_name>»?

Потому что Dlang не создал community, экосистему, и потому что сборщик мусора хотя и опционален и не так страшен, но на деле сразу отбивает надежду что это настоящая замена С++. Если сборщик будет, то его используют в библиотеках.

Даже в Rust есть std и nostd. И библиотеки стремятся если могут даже nostd юзать, что открывает им путь в микроконтроллеры, ядра ос, драйверы и во все что можно где нету ОС как таковой. Это уже другой уровень

Ніт

Шо, опять?

Нужно было Rust vs Go, хотя бы. Кому интересен срач с мёртвым D?

Кому интересен срач с мёртвым D?

Я вон попытался ответить по сути

А вот как ни смешно, мне D показался гораздо более пригодным нежели Rust

Он был более пригодным году так в 2005-м. Всё, поезд уехал. Текущая альтернатива C++ - это Rust.

Суть в том, что ТС опоздал лет на 15.

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

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

Да, D может быть тоже был неплохой заменой С++ для множества продуктов. Как и Rust. Главное на чем-то более менее сойтись.

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

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

А вот как ни смешно, мне D показался гораздо более пригодным нежели Rust

Чем? Можешь перечислить достоинства D в сравнении с растом?

мы так С++ никогда не закопаем для новых проектов

У кого-то реально есть такая цель? O_o

В головах у тех, кто до сих пор думает, что С++ это С++03.

мы так С++ никогда не закопаем для новых проектов

Наконец-то до закапывателей дошло, что C++ еще придет положить цветочки на их обветшалые могилки.

У Rust есть несколько другой недостаток: его сложно читать без IDE/rls незнающему человеку.

Например, стоит открыть для сравнения код docker и servo и ткнуться в любой файл. Код на Go можно читать прямо в браузере и не испытывать никаких проблем. Код на Rust - хрен пойми, что тут написано, практически везде используется вывод типов, без поддержки умного редактора - надо хорошо знать Rust.

Любые ссылки могут быть null, исключения, злоупотребления макросами define (скромно притворяющимися миксинами)

D это GC, полупроприетарное прошлое, стагнация, отсутствие инфрастрктуры и по факту изначальное отсутствие новых идей относительно C++/Java. Rust как минимум вывел типобезопасность на новый уровень, как максимум красиво реализовал множество вещей которых (по крайней мере всех вместе) не было ни в одном компилируемом языке, начиная с pattern matching и заканчивая нормальными макросами, crates.io и поддержка мозиллы (хотя это уже не важно, т.к. он набрал собственную инерцию).

Да, у меня есть. Не хочу видеть это говно нигде. Хочу чтобы моя компания с него слезла. Чтобы даже пара опытных инженеров - разработчик кода и его ревьювер постоянно проморгивали тривиальные ошибки и это добиралось до продакшна. Десятки документов написаны в Google, Facebook, Amazon, Microsoft, Dropbox, Twitter, с кем ни поговори. Не просто болтание на форумах, на основе глубоких исследований вреда от С++, которое его устройство нанесло компании. Выраженого в долларах, а именно уже в миллиардах. И отмазы что мол это все быдлокодеры, нужно просто перестать делать ошибки тут не работают. Речь идет о Core C++ teams этих компаний, с авторами изменений в стандарт. Их работа заключается в поддержании общего здоровья кодовой базы через всю компанию, они руководят всем процессом. Они разрабатывают анализаторы, инструменты массового рефакторинга, системы оценки здоровья и сложности кода. Они уже опускают руки, это нельзя пофиксить. С годами становится только хуже. Комитеты же С++ полны бюрократии, противоположных интересов, там нельзя продуктивно работать. Короче все, решили закапывать, С++ хана

Да, у меня есть.

Акуеть. Обычно у людей цель сделать что-нибудь.

Да, все как ты сказал. Сделать - запустить трансформацию кодовых баз

Да ладно. Всех понятно. Смотри какая простая шука…https://github.com/libp2p/rust-libp2p/blob/master/swarm/src/lib.rs#L202 сразу видно зато, что надежно и повышает ЧСВ автора

Вы не поверите.

Да, далеко расту до плюсовых трейтов.

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

Когда у D были шансы оказаться востребованным (2002-2004 и 2011-2014) он был нестабильным. Когда он более-менее стабилизировался, то оказывалось, что он невостребованн, потому что были более модные и хайповые технологии. Сперва это были Java, C#, Scala. Потом Go и Rust.

Вообще одна из главных проблем D в том, что его локомотив (будь то один Вальтер Брайт, то Брайт за компанию с Александреску) никогда толком не знал, что он хочет получить. Начиналось все как почти что нативная Java с GC, без шаблонов/генериков. И Брайт говорил, что он принципиально не хочет видеть в D шаблонов. Прошло несколько лет и шаблоны в D добавили.

Аналогичное было и с константностью. Не хотел Брайт видеть в D константных методов, как в C++. Прошло несколько лет и в D константность появилась.

Теперь вот Брайт пытается спозиционировать D еще и в виде betterC, без GC, но и без ряда плюшек D.

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

Да ладно. Всех понятно. Смотри какая простая шука…

      <THandler as IntoProtocolsHandler>::Handler: ProtocolsHandler<InEvent = TInEvent, OutEvent = TOutEvent, Substream = Substream<TMuxer>, Error = THandlerErr> + Send + 'static,
      <<THandler as IntoProtocolsHandler>::Handler as ProtocolsHandler>::InEvent: Send + 'static,
      <<THandler as IntoProtocolsHandler>::Handler as ProtocolsHandler>::OutEvent: Send + 'static,
      <<THandler as IntoProtocolsHandler>::Handler as ProtocolsHandler>::Error: Send + 'static,
      <<THandler as IntoProtocolsHandler>::Handler as ProtocolsHandler>::OutboundOpenInfo: Send + 'static, // TODO: shouldn't be necessary
      <<THandler as IntoProtocolsHandler>::Handler as ProtocolsHandler>::InboundProtocol: InboundUpgrade<Substream<TMuxer>> + Send + 'static,
      <<<THandler as IntoProtocolsHandler>::Handler as ProtocolsHandler>::InboundProtocol as UpgradeInfo>::Info: Send + 'static,
      <<<THandler as IntoProtocolsHandler>::Handler as ProtocolsHandler>::InboundProtocol as UpgradeInfo>::InfoIter: Send + 'static,
      <<<<THandler as IntoProtocolsHandler>::Handler as ProtocolsHandler>::InboundProtocol as UpgradeInfo>::InfoIter as IntoIterator>::IntoIter: Send + 'static,
      <<<THandler as IntoProtocolsHandler>::Handler as ProtocolsHandler>::InboundProtocol as InboundUpgrade<Substream<TMuxer>>>::Error: Send + 'static,
      <<<THandler as IntoProtocolsHandler>::Handler as ProtocolsHandler>::InboundProtocol as InboundUpgrade<Substream<TMuxer>>>::Future: Send + 'static,
      <<THandler as IntoProtocolsHandler>::Handler as ProtocolsHandler>::OutboundProtocol: OutboundUpgrade<Substream<TMuxer>> + Send + 'static,
      <<<THandler as IntoProtocolsHandler>::Handler as ProtocolsHandler>::OutboundProtocol as UpgradeInfo>::Info: Send + 'static,
      <<<THandler as IntoProtocolsHandler>::Handler as ProtocolsHandler>::OutboundProtocol as UpgradeInfo>::InfoIter: Send + 'static,
      <<<<THandler as IntoProtocolsHandler>::Handler as ProtocolsHandler>::OutboundProtocol as UpgradeInfo>::InfoIter as IntoIterator>::IntoIter: Send + 'static,
      <<<THandler as IntoProtocolsHandler>::Handler as ProtocolsHandler>::OutboundProtocol as OutboundUpgrade<Substream<TMuxer>>>::Future: Send + 'static,
      <<<THandler as IntoProtocolsHandler>::Handler as ProtocolsHandler>::OutboundProtocol as OutboundUpgrade<Substream<TMuxer>>>::Error: Send + 'static,
      <NodeHandlerWrapper<<THandler as IntoProtocolsHandler>::Handler> as NodeHandler>::OutboundOpenInfo: Send + 'static, // TODO: shouldn't be necessary
      TConnInfo: ConnectionInfo<PeerId = PeerId> + fmt::Debug + Clone + Send + 'static

Я перекрестился на всякий случай да окропил свои чресла святой, православной Сишечкой.

тебе просто завидно, что ты так не можешь.

тебе просто завидно, что ты так не можешь.

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

<<<THandler as IntoProtocolsHandler>::Handler as ProtocolsHandler>:: – ну, на самом деле, это достаточно понятный … бойлерплейт. Вопрос в другом, неужели в расте нет нормальных механизмов, чтобы от него избавиться? Макросы там, то се.

Есть макросы. Тут решили без них.

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

Растовские макросы позволяют генерить такую копипасту более элегантно? Можешь привести какой-то коротенький пример конкретно по этому юзкейсу?

А вообще, по-нормальному, тут не нужны были бы и макросы, а просто возможность вводить синонимы. Как это идиоматично решается у вас?

Это tomaka писал. Он знаменит запихиванием невпихуемого в систему типов.

Это tomaka писал. Он знаменит запихиванием невпихуемого в систему типов.

«Это не язык плохой! Это просто люди используют его неправильно!»

Что-то напоминает.

Это tomaka писал. Он знаменит запихиванием невпихуемого в систему типов.

Это просто бойлерплейт-копипаста. И получается то ли это решается какими-то другими способами в языке (но почему-то здесь так не пишут), то ли неудачно выбран синтаксис для подобных определений (ошибка дизайна).

Вообще одна из главных проблем D в том, что его локомотив (будь то один Вальтер Брайт, то Брайт за компанию с Александреску) никогда толком не знал, что он хочет получить

интересно, а разрабы раста знают, что они хотят получить? Раньше там были опциональный GC и корутины. Потом они это выпилили. Сейчас вот потратили кучу усилий на async/await. Чем их не устроил tokio?

Вводить синонимы в where clauses нельзя. Сейчас занимаются автоматическим выводом ограничений на типы, чтобы не повторять уже написанное в определении структур и трейтов.

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

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

Язык развивается, используется коммерческими компаниями, у него все хорошо и есть будущее. Использую язык уже давно, больше 6 лет точно и вижу как язык развивается, сообщество и экосистема. Из последнего - реализуется поддержка вызова Java из дишного кода и обратно, в первую очередь для поддержки андроида. Язык активно развивается, пока местные хомячки хоронят то D, то C++, то что-то другое.

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

я где-то видел точно такой же код, только с примесью 'a, 'b, 'c Вот где реальный адище. даже перловые однострочники для парсинга всего понятнее читаются

D это GC, полупроприетарное прошлое, стагнация, отсутствие инфрастрктуры и по факту изначальное отсутствие новых идей относительно C++/Java.

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

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

Я слегка поглядываю за развитием D и вижу что, к примеру, выкинули Си из ядра DMD. Сообщество или Digital Mars планируют переписать стандратную библиотеку в GC - free стиле? А то это (dlang.org) ни в какие ворота.

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

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

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

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

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

В D можно обойтись без сборщика

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

язык активно развивается

инфраструктура в наличии

куча идей

Это пустые слова.

как неучи с пеной у рта доказывают кто круче

Это вы пытаетесь доказывать, притом без аргументов, а я просто объяснил почему D менее популярен чем Rust. Если у вас есть другое тому объяснение - даже интересно будет послушать. Или вы собрались спорить с фактом что он менее популярен?

А D разрабатывается сообществом профессиональных инженеров

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

Не совсем понял про выкидывание С из ядра dmd - dmd изначально на плюсах писался, там Си не было никогда, насколько я помню. А так да, последняя версия dmd, написанная на плюсах это 2.068, а недавно вышла уже 2.090. Так что dmd написан на D.

Сообщество или Digital Mars планируют переписать стандратную библиотеку в GC - free стиле?

Не слежу за этой темой - стараюсь все на стеке размещать, небольшое использование GC только упрощает жизнь, а фобиями не страдаю. Но даже я знаю, что планы есть. Сейчас Уолтер Брайт ведет подготовительную работу для этого, например релиз или два назад фобос стал собираться с dip1000 - поддержка scoped pointers, позволяет лишний раз не подсчитывать ссылки при использовании reference counting.

Что насчет betterC - это к GC не имеет никакого отношения, это подмножество языка для других целей было сделано.

Намного хуже обычно какой-то тихий data race.

В Расте тихие data race отменены окончательно?

Раст на хайпе, его специально раскручивали, а может и сейчас продолжают

Кто? Банда навального?

Стало быть Rust не разрабатывается сообществом профессиональных инженеров.

Согласен, я неверную формулировку выбрал. Нет, Раст разрабатывается профессионалами, но значительную часть сообщества составляют воинствующие фанатики, которые в теме не разбираются, но мнение имеют. У Раста не просто маркетинг, а агрессивный маркетинг.