LINUX.ORG.RU
Ответ на: комментарий от anonymous

про linear types:

``The case for resource aware type systems'' argued for teaching a notion of resource to GHC’s type system. We show how adding a notion of linear types, a particular form of resource typing, addresses the challenges exposed therein.

Linear types for resource management We argue that linear types offer a solution to static resource management and help address the challenges of latency. The benefits from linear types can be gained incrementally:

linear types и region-based analysis может использоваться для автоматического выведения хинтов, и оптимизации доступа к ресурсам.

отменяя GC в каком-то виде. другое дело – что лайфтаймы в расте это совсем другое.

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

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

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

В D есть RAII?

Есть

Вкратце: классы в D это типы-ссылки, они по умолчанию выделяются на куче (но при желании можно и на стеке) и используют сборщик мусора и RAII не поддерживают. Структуры в D это типы-значения, по умолчанию размещаются на стеке (но могут и на куче, конечно) и полностью поддерживают RAII как в С++

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

Иначе к чему эти разговоры?

Я всего лишь объясняю свою точку зрения. Она состоит вот в чем:

  • лично мне D интересен именно тем, что это быстрый и безопасный нативный язык с GC. Ибо кроме него в этой нише есть разве что Go и Eiffel, ибо какой-нибудь OCaml с Haskell-ем – это уже совсем другие парадигмы (да и OCaml не то, чтобы хорошо и активно развивается, насколько я помню). Поэтому меня совсем не смущает наличие GC в D, скорее наоборот;
  • но при этом как раз наличие GC в D для меня означает, что D не конкурент C++. Уже объяснял почему: потому что там, где в прикладной задаче можно использовать GC, С++у уже давно делать нечего;
  • при этом мне не нравится стремление Брайта и Ко усадить D сразу на два стула: вот вам D как язык с GC, и вот вам этот же самый D как язык без GC. Имхо, так не бывает. Тут либо одно хорошо нужно делать, либо другое. И даже в разговоре с вами выясняется, что программирование на D без GC будет ну вот совсем-совсем другим, чем без GC. Собственно, два разных мира. И не получится просто так в мире D переиспользовать куски кода из D с GC в D без GC (а может и наоборот). Доказательством чему пока еще является сама стандартная библиотека D, которая в D без GC наполовину недоступна (а может и больше).

Вы же пытаетесь убедить меня в том, что D без GC будет иметь преимущества перед C++, хотя у вас у самого подобного опыта не было, т.к. вы давно работаете с D с GC.

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

Во-вторых есть более адекватные вещи для повышения популярности.

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

poor adoption и отсутствие хайпа - это кардинально разные вещи, как по мне.

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

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

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

Согласен.

Разве что уточню свою позицию: хайп может помочь набрать критическую массу и тогда даже когда наступит «прозрение» (ну или разочарование), то язык уже захватит какую-то нишу, появится легаси, вакансии. Поэтому я не вижу в этом ничего плохого.

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

Поэтому я не вижу в этом ничего плохого.

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

Типа, вот появилась Java, давайте все делать на Java. Появился RoR, давайте все делать на RoR. Появился Go, давайте все делать на Go. И т.д.

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

Тем не менее, у хайпа есть не только положительные, но и отрицательные стороны.

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

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

D тоже в свое время, лет пятнадцать назад, вовсю раскручивали, и восторженные поклонники, например я и или присутствующий тут eao197, тоже бегали по форумам, нахваливали :) Хайп вполне заметный поднялся тогда, почему из этого большого толка не вышло тут уже eao197 вполне объяснял.

Из последнего - реализуется поддержка вызова Java из дишного кода и обратно

Тогда рекламировалась очень легкая прямая трансляция ява кода в D.

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

В gcc v.9.0 был официально добавлен D. А вот Раста в gcc так и нет, действительно. И не предвидится.

Если такими же темпами что и D будут добавлять, то не пройдет и 15 лет как добавят :)

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

он же очень сильно зависит от llvm, не?

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

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

Хайп это хорошо. Например, где бы был руби без хайпа? Да никто бы не узнал, что есть такой интересный ЯП, и корячились бы все дальше с пхп. А так получилось и покодить в удовольствие, и подзаработать. Еще можно над хайпожорами всячески насмехаться и хейтить их (опция для старперов). Одни выгоды.

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

Например, где бы был руби без хайпа?

ХЗ. Я о Ruby в первый раз узнал в году 2001-ом. А использовать начал в 2004-ом и вовсе не для Web-разработки. В 2006-ом, в самый хайп вокруг RoR у меня Ruby активно использовался и опять же, совершенно не для Web-а.

Так что не думаю, что хайп вокруг Ruby-On-Rails настолько однозначно полезный был для Ruby. И что Ruby без этого хайпа бы не взлетел.

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

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

А нет ли ключика компилятора типа –no-gc который на любые попытки использовать то что требует gc выдает ошибку компиляции? Просто в C++ всегда нужно быть осторожным это понятно, но вот rust опасное просто не скомпилирует, и подход раста мне все больше и больше нравится.

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

Можно к функции main добавить ключ nogc и это будет примерно тоже самое.

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

Без рельсов не было бы оплачиваемой работы. Хотя я знаю, что были вакансии и до рельсов, но это единичная экзотика. Если за спиной у технологии нет корпорации с резиновым рекламным бюджетом, то без хайпа тем более никуда. Хотя вот загадка: с растом это не работает: там и коммерс за спиной, и толпа фанбоев в наличии, а выхлоп околонулевой. То ли этот хайп иллюзорный, то ли одного хайпа маловато, нужен еще и продукт какой-никакой.

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

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

Ну ок, попробую отказаться от сборщика мусора у себя, просто чтобы поиметь опыт)

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

D тоже в свое время, лет пятнадцать назад, вовсю раскручивали, и восторженные поклонники, например я и или присутствующий тут eao197, тоже бегали по форумам, нахваливали :) Хайп вполне заметный поднялся тогда, почему из этого большого толка не вышло тут уже eao197 вполне объяснял.

Большого толка не получилось так как разработчики языка решили значительно его изменить и получился D2, который заметно отличался от D1 и это-то и отпугнуло значительную часть его пользователей. И это объясняет текущую ситуацию. А сборщик мусора тут вообще не причем. Когда сделают сборщик мусора 100% опциональным - найдется другая причина критиковать язык.

Тогда рекламировалась очень легкая прямая трансляция ява кода в D.

Да в принципе и сейчас это осталось. Тот же сишный, плюсовый и ява код зачастую можно тривиально портировать на D с минимальными правками.

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

Есть атрибут @nogc, который позволяет пометить функцию, которая не использует сборщик мусора. Его использование в этой функции будет давать ошибку компиляции.

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