LINUX.ORG.RU

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

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

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

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

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

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

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

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

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

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

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

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

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

anonymous ()

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

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

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

vertexua ★★★☆☆ ()

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

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

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

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

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

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

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

      <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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

red75prim ★★ ()
Последнее исправление: red75prim (всего исправлений: 1)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

куча идей

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

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

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

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

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

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

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

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

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

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

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

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

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

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

yetanother ()