LINUX.ORG.RU

Вышла первая версия компилятора D, написанная на D

 


3

6

Сегодня состоялся очень важный релиз компилятора языка D — DMD 2.069.0. До настоящего момента компилятор D был написан на С++, однако новая версия теперь написана на самом D. Процесс конвертации исходного кода с С++ на D занял значительный промежуток времени, однако позволил многократно упростить поддержку компилятора.

Значительным улучшениям подверглась стандартная библиотека Phobos. Теперь ещё больше функций в ней были рэнджефицированы (ranges — концепция, позволяющая упростить доступ и переборку элементов структур и классов).

DMD теперь поддерживает формат mscoff, используемый в библиотеках VS2015.

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

Для пользователей Linux выложена первая пробная версия компилятора Calypso, позволяющая в D использовать практически все существующие С++-библиотеки, даже такие большие и сложные, как Qt5 и Ogre3D.

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

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

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

Новая версия сервера DCD, реализующая автодополнения исходного кода, также готова к использованию с новой версией DMD.

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

★★

Проверено: Shaman007 ()
Последнее исправление: Wizard_ (всего исправлений: 5)

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

Не сказал бы, что новые фичи в нём - хлам.

Вот ты сможешь назвать язык более сложный чем D?

По сложности он будет на уровне С++, но есть сложность языка и сложность использования. Вот тут думаю у D будет преимущество. Да и необязательно учить сразу все навороты.

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

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

К сожалению, нет.

Но речь-то не обо мне. Вот до сих пор вспоминают D1/D2, на питон3 тоже не все перешли. И наоборот - уверен, что обратная совместимость джавы/шарпа/плюсов влияют на их популярность.

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

По моему, всё-таки лучше добавить новую ногу, старую объявить «deprecated», а не выкидывать сразу. Да, какой-то груз совместимости придётся тащить, но тут уже от языка зависит насколько легко и удачно в него новые идеи интегрируются.

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

Не сказал бы, что новые фичи в нём - хлам.

Так и в С++ можно даже препроцессор оправдать - совместимость с С, можно заинклудить какой-нибудь sqlite3.h и напрямую пользоваться. Т.е. это типа просто фича такая. Другое дело, что со временем фичи переосмысливаются и устаревают. Как тот же препроцессор. И вот тогда они стают еще и хламом.

По сложности он будет на уровне С++, но есть сложность языка и сложность использования. Вот тут думаю у D будет преимущество. Да и необязательно учить сразу все навороты.

Он сложнее С++ хотя бы потому, что он во многом надстройка из фич над ним. И этих фич много и они зачастую сложные. А насчет использования - С++ многие используют на уровне Java, а на код в стиле С смотрят круглыми глазами.

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

Это когда?

Когда мы этим не пользуемся, а всё равно вынуждены иметь счётчик.

Чуть ли не основная врайт-операция над строкой.

Вообще-то я сразу оговорился, что с удобством Qt-шных строк согласен (хотя суррогатные пары там ведь могут быть? а значит доступ по индексу уже не такой и полезный) и речь шла про остальные контейнеры. А для них пользы от реплейса не вижу.

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

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

Я то выразился так. И кто поумнее, тот мысль уловил сразу.

А так ты придираешься к вырванным из контекста словам.

К вырванным из контекста словам как раз придирается школота, которая слова воспринимает буквально. Чем себя и выдает.

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

вот как же так получилось, что вместо элегантного и лишенного недостатков (пусть будет недостатков C++) D перфекционистам через десять лет пришлось изобретать Rust, как альтернативу тому же C++ для написания браузеров?

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

D для их целей не подходит не потому что слишком сложен или «неэлегантен», а как раз наоборот - недостаточно строг и слишком многое разрешает разработчику.

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

А вот с «движками» пока слышал только про vibed. Этого конечно мало, но в принципе писать-то можно!

Написал себе казуальный бложик на vibe.d, остался жив :) https://github.com/Dicebot/mood

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

D для их целей не подходит

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

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

В таком случае D не подходит для того, для чего подходит C++.

Логический провал. С++ для этих целей подходит ещё меньше (иначе бы они вообще бы ничего не переписывали) :)

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

Да, если нам не нужно остальное stl-ное барахло.

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

То есть на инфраструктуру оно не завязано.

всё это было в кути за долго до того, как это впихнули в стл - уже говорит о многом.

О том, что стандарт плюсов не развивался долгое время? Или ты какие-то другие выводы делаешь?

Стримы - да, уродливые. Поэтому все, кому надо, брали тот же boost::format, например. Arg - штука удобная, но тащить только ради неё Qt я бы не стал.

Аргументируй.

В сообщении, на которое я отвечал, никакой аргументации не было.

Можем обсудить, если ты готов оставить несчастные строки в покое. Стандартная библиотека плюсов (не вся, разумеется, но речь-то про контейнеры шла) нравится мне зато что она задаёт «интерфейс» и позволяет удобно комбинировать стандартные контейнеры/алгоритмы со сторонними. Собственно, даже Qt поддерживает итераторы. Более того, они прямым текстом пишут:

Historically, Qt used to provide functions which were direct equivalents of many STL algorithmic functions. Starting with Qt 5.0, you are instead encouraged to use directly the implementations available in the STL

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

Rust
Язык был сделан намеренно очень сложным

O_O, это все-таки серьезно? Rust прост как пробка, единственное, что надо смириться с его строгостью. Но это опять плюс к простоте.

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

иначе бы они вообще бы ничего не переписывали

Так они как раз идут по пути упрощения, в обратную сторону от D. С++ по середине.

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

Логический провал. С++ для этих целей подходит ещё меньше (иначе бы они вообще бы ничего не переписывали) :)

Они пока ничего и не переписывали. Все подобные задачи по-прежнему решаются на С++. А они пока проверяют может ли Rust в принципе оправдать их ожидания или нет. Пока не видно что может. А даже если и сможет, то не понятно зачем он будет нужен, если в C++17 будет всё то же самое, даже лучше. Впрочем, D в любом случае останется неудачной попыткой улучшить C++. Это видно уже сейчас.

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

Не льсти себе.

Мне и не надо. Понимаешь в чём отличии между нами? Вам надо пытаться делать вид, кукарекать, юлить и пытаться что-то доказать. Пытаться унизить и врать, а после обсираться.

Мне же ничего этого делать не надо, ибо итак понятно где я, а где адепт.

Ты по природе агрессивное быдло

Естественно. Только вот одна неувязочка. Как бэ я быдло, а мусор адепты, хотя вроде как не быдло.

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

Без этого обвинение в быдлячестве не имеет смысла.

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

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

При этот на сам «разговор» и на его контекст это никак не влияет.

и тебе это нравится

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

Имею право. Я не могу вести себя как недобитая мразь и использовать приёмы убогих, но ставить на место их надо.

Поэтому я популярно объясняю адепту кто он, но ничего противопоставить моим словам он не может и не ответить так же не может, ибо он обосрётся.

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

Никакой проблемы для тебя это не представляет.

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

Которые сруться со мною ради высших целей, а не ради защиты своей жопы.

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

O_O, это все-таки серьезно? Rust прост как пробка

Я специально посетил один Rust Meetup для новичков, где никто, кроме меня, не был знаком с D (так что никакой предвзятости по этой части). Всё было очень интересно, но общее мнение по окончанию - «я не могу представить себе проекта, в котором _так_ упарываться было бы экономически оправдано».

Говорить «прост как пробка» про язык, где написание простейшей угадайки с лёгкостью займёт час времени новичка? Шутить изволите? :) На Rust нельзя написать ни одной программы, не имея хорошего понимания lifetime & ownership. Это автоматически делает его очень сложным.

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

Пока не видно что может.

Это видно уже сейчас.

Могут только позавидовать такой наблюдательности. Всё ещё готов отвечать на вопросы по существу.

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

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

Человеку, который пытается неудачно косить под царя, не следовало задавать вопросы про C++ на форуме. Царь на то и царь, чтобы декларировать свой высочайший уровень, но нигде его не демонстрировать. А уж если кто-то сам про C++ спрашивает, то какой же он нафиг царь. Самозванец какой-то.

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

На Rust нельзя написать ни одной программы, не имея хорошего понимания lifetime & ownership. Это автоматически делает его очень сложным.

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

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

Ок, это всё интересно, только разве мы о чём-то спорим?

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

PS: stl убог по определению.

Да ну? По какому определению?

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

Ну ответь чего такого полезного было написано на D за 15 лет.

«полезное»? Язык живёт и используется в коммерческих проектах, пусть и редко. Какое ещё определение «пользы» нужно? Тот же Erlang в таком состоянии пробыл многие годы, пока внезапно не начал становиться снова модным.

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

пока внезапно не начал становиться снова модным.

Действительно внезапно.

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

«полезное»? Язык живёт и используется в коммерческих проектах, пусть и редко. Какое ещё определение «пользы» нужно?

Что-то из опенсорса, или хотя-бы из проприетарщины, что можно было бы реально «пощупать», а не выслушивать рассказы об этом. Я не имею в виду поделки вроде недоделанных GUI-тулкитов или IDE. Нужно что-то вроде Firefox, OpenOffice или MySQL, чем пользовались бы пользователи.

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

Это автоматически делает его очень нужным.

А я разве говорил, что Rust не нужен? Но проектов, где это целесообразно - очень мало. Embedded, hard real-time (а вот в soft real-time - уже не так критично), требовательные к ресурсам монстры вроде браузеров и фотошопов. Это капля в море разрабатываемого софта.

Так что вот с этим утверждение я согласиться не могу:

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

Часто вполне хватает GC и/или библиотек, написанных более компетентными людьми. Даже если на конкретном проекте это в целом нужно, требовать от каждого junior практического понимания lifetime - нереально.

А классы и шаблоны - это просто инструменты абстракции, совсем не связанная тема.

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

Против питонов, жаб и пхп'ов это дохлый номер. На C++, вон, тоже есть веб-фреймворк. И не один. И они хотя-бы стабильные и действительно быстрые. Но в качестве примера не катят ибо маргинальщина.

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

С++ сосёт например потому...

Я, вроде, не собирался плюсы защищать? Хотя аннотации там «появились», когда-то и до рефлексии доживём.

Но и в D всё не так уж здорово. Скажем, ты про миксины заговорил, но метапрограммирование на строках - отстой.

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

Что-то из опенсорса, или хотя-бы из проприетарщины, что можно было бы реально «пощупать»

Совем пощупать не получится, так как все известные мне крупные коммерческие проекты - серверные (http://www.economicmodeling.com , http://www.sociomantic.com , http://www.weka.io) или вообще закрытого пользования (http://dconf.org/2015/talks/smith.html).

Десктопные приложения (== «чем пользовались бы пользователи») никто никогда даже не пытался серьёзно делать, насколько мне известно.

Хороший пример нетривиального проекта, который можно поизучать - https://github.com/higgsjs/Higgs , JIT компилятор для JavaScript.

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

Есть в этом «если - то» что-то наркоманское.

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

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

Часто вполне хватает GC и/или библиотек, написанных более компетентными людьми. Даже если на конкретном проекте это в целом нужно, требовать от каждого junior практического понимания lifetime - нереально.

Вот поэтому и есть та же Java, где крайне трудно отстрелить себе ногу, а новичку практически нереально. А D в этом плане не то, что недалеко ушел от С++, он еще и все усложнил. Там все так же легко отстрелить себе ногу:

int* p = cast(int*)0;
*p = 10;

Но к этому еще и добавился GC со всей его непредсказуемостью по поводу очистки памяти, и scoped, и cow, и непонятно нахрен нужный и опасный RefCounted и пр. Да тут понимание lifetime гораздо важнее и сложнее чем в Rust.

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

Ни в одном современном языке нет заголовочных файлов

Это не очень хорошо в плане скорости обработки кода, но сейчас на это можно забить. Да. Хотя...

и почти везде есть сборщик мусора: Java, OCaml, Haskell, C#, D, Go. Получается, что все разработчики современных языков криворукие и тупоумные мартышки.

А вот это 100% верно. Любой язык с GC нишевый уродец. Просто в свое время возобладала религия GC. Мы и видим результат работы этой секты.

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

Я доступно излагаю?

Нет, ты передёргиваешь. Когда тебе показывают реально написанный код, то начинается виляние жопой в духе «ну я же просил что-то полезное».

Тот, кому действительно интересно, может пойти на тот же this week in rust и лично посмотреть/почитать как люди что-то делают и делятся опытом, в том числе, негативным.

И кто после этого болтун?

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

Совем пощупать не получится

Десктопные приложения (== «чем пользовались бы пользователи») никто никогда даже не пытался серьёзно делать, насколько мне известно.

No comment.

Хороший пример нетривиального проекта, который можно поизучать - https://github.com/higgsjs/Higgs , JIT компилятор для JavaScript.

А нафига он нужен? Чтобы запускать ублюдочный JavaScript на серверной стороне, вроде Node.js? То есть D настолько «хорош» в качестве языка для веба, что нужны такие вот костыли?

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

Любой язык с GC нишевый уродец.

Это не так. Существует множество задач, в которых realtime и предельная производительность вообще вовсе не обязательны. Собственно, на Java, которая по идее должна быть «нишевым уродцем», написано много всего и разного.

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

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

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

Интерфейс указателя/«get_next()» существовал задолго до стл"а и крестов.

В целом ты приписал плюс в стл лишь потому, что qt сделали совместимым с ним? Ну да, молодец. Только к стл это не имеет никакого отношения и не является его плюсом.

То есть на инфраструктуру оно не завязано.

Чё?

О том, что стандарт плюсов не развивался долгое время? Или ты какие-то другие выводы делаешь?

И в этом виноват я, да?

Выводы я делаю на основании того, что раз это взяли - это нужно.

Стримы - да, уродливые.

Подумаешь, всего лишь ио. Такая незначительная вещь и дерьмо.

Поэтому все, кому надо, брали тот же boost::format

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

Нет, если нам не нужно остальное boost-шное барахло.

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

например. Arg - штука удобная, но тащить только ради неё Qt я бы не стал.

Это не аргумент. А типа буст тащить ради формата стал бы?

Мы уже выяснили, что ио в крестах кусок непотребства, а строки и форматирование не удобны.

В сообщении, на которое я отвечал, никакой аргументации не было.

Было.

Тебе сказали, что кути-стиль удобен. Я объяснил почему - ты согласился. Значит аргументы были.

Ты говорил, что крестовая либа не вызывает «удручающее впечатление», при этом как оказалось - такой она стала только пару лет назад, при этом форматирование, io и строки - как были говном так и остались.

Опять же - ты не прав.

Можем обсудить, если ты готов оставить несчастные строки в покое.

Строки, ио и форматирование - это то, что любой адепт юзает в 50%+ случаев, не считая написания собственной логики. И я должен об этом забыть?

не вся, разумеется, но речь-то про контейнеры шла

Какие такие контейнеры и кому они нахрен нужны не ясно.

все эти контейнеры, нормальные строки с юникодом - куча плюшек в довесок к крестам.

Контейнеры малая и примитивная часть stl и qtcore. Только вот в кути их больше и они фичастей.

Допустим вот я создавал тему - мне надо было удалять из «вектора» елемент и передавать его дальше. В кути есть take(), который делает то, что нужно мне.

А вот в убогом стл - ничего нет.

T* ptr = ref_queue.front();//типичный крестовый код
        ref_queue.pop();

Выше уже подробнее о том, чем удобнее те же кутишные типи и контейнеры - пацаны уже писали.

Ты попытался на это ответить чем-то типа:

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

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

При этом выше ты называл тот же аргумент, который сам же назвал убогим - «интеграция». Ты понимаешь в чём твоя проблема, либо мне пояснить?

нравится мне зато что она задаёт «интерфейс» и позволяет удобно комбинировать стандартные контейнеры/алгоритмы со сторонними.

Интерфейс никакого отношения к «стандартной библиотеки» не имеет.

Интерфейс - это интерфейс, причём интерфейс stl, которая к крестам не имеет никакого отношения, а то, что её впилили в стандарт - ничего не значитл.

Стл - это такой же кути/буст, только впиленный в стандарт.

А вот стандартная библиотека крестов - это стримы и прочее убожество.

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

Собственно, даже Qt поддерживает итераторы. Более того, они прямым текстом пишут:

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

Вся суть стл"а и связь его с крестами в том, что интерфейс вида «get_next()» замаскировали под обычный интерфейс указателя, благодаря наличию у крестов перегрузки операторов. Т.е. это не просто значение, а состояние из которого можно получить значение.

В целом - мне не ясно как ты связал интерфейс stl'а и крестов. Как ты вывел за плюс stl'a совместимость с ним других реализаций алгоритмов/контейнеров и прочее. Я жду пояснений.

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

Нет, ты передёргиваешь. Когда тебе показывают реально написанный код

Можно ещё раз ссылочку на этот пост, где ты мне показал реально полезный код?

в духе «ну я же просил что-то полезное»

Разумеется. Потому что, скажем, servo, про который пишут в твоем this week in rust - совершенно бесполезный с точки зрения пользователя проект.

И кто после этого болтун?

Тот, кто болтает про бесполезные язычки вместо того, чтобы написать на них что-то полезное.

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

Там все так же легко отстрелить себе ногу:

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

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

И в джаве GC доставляет реальный, а не теоретический геморрой. Именно потому, что на ней много чего написано.

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

А ты в своем D без IDE будешь как мартышка бегать по всему файлу, чтоб увидеть цельную картину.

В D разве нельзя разнести объявление и реализацию?

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

А ты в своем D без IDE будешь как мартышка бегать по всему файлу

Visual-D, Mono-D

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

Зачем же вы указателем-то пользуетесь! Не надо писать на D ничего через указатели, если только в этом нет крайней, особой необходимости. И да, пометьте свой код как safe и такое просто не скомпилируется.

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

Вот поэтому и есть та же Java, где крайне трудно отстрелить себе ногу, а новичку практически нереально.

Да, Java в этом отношении остаётся вне конкуренции. На мой взгляд ниша D - как раз в компромисе, когда нужно больше контроля, чем в Java, но больше удобства, чем в С++ (бизнес-логика составляет значительную часть). Насколько эта ниша велика - не знаю.

А D в этом плане не то, что недалеко ушел от С++, он еще и все усложнил

Очень субъективное утверждение, поэтому возражать с аргументами трудно :) Но мой рабочий опыт (~4 года C++, ~3 года D) пока говорит об обратном. Мы нанимаем людей без опыта D вообще (С/Java) и уже через пару недель они могут писать адекватный код в production, с поправкой на code review.

Например, `cast` вне библиотек в D - аномалия и всегда предмет особого внимания. Это инструмент специально предназначенный для того, чтобы «всё сломать, если очень хочется».

Непредсказуемость GC создаёт довольно много проблем, но в ряде задач не играет никакой роли (например, тестирование), зато значительно экономит время. При этом http://dlang.org/phobos/std_experimental_allocator.html - это лучшее, с чем я когда-либо сталкивался в плане ручной работы с ресурсами, во времена моей работы с C++ я бы не раздумывая отдал почку за такую библиотеку.

Проблемы с lifetime (если не использовать GC) остаются, но это именно та цена, которую пришлось заплатить, чтобы не усложнять всё до уровня Rust. Все известные мне косяки scoped / unique как раз связаны с отсутствием строгого контроля lifetime.

А CoW пока что в D вообще нет (и я не думаю, что оно нужно) :)

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

Не будем забывать, что D все же быстрее Джавы.

Это зависит от компилятора. У меня в расчётных задачах dmd примерно на одном с нею уровне, а вот gdc --- втрое быстрее.

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

Не будем забывать, что D все же быстрее Джавы.

Это надо читать как «может быть, мог бы быть быстрее, если бы на нем это написали». И то не факт. И уж точно не факт, что это кого-то волнует. А вот тормоза GC волнуют.

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

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

Так и в С++ можно так же. Стек + умные указатели вполне себе заменяют GC.

А если вы все же пользуетесь ими - предполагается, что вы знаете, что делаете.

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

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

Зачем же вы указателем-то пользуетесь! Не надо писать на D

Чего уж там.

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

В D разве нельзя разнести объявление и реализацию?

Можно, но этого никто не делает :) Потому что лишняя головная боль, а размер проектов не оправдывает строгого разделения на статические библиотеки.

// example.d class C { void foo () { } }

// example.di

class C { void foo (); }

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

DMD и не должен использоваться для продакшена, это reference-компилятор. Финальную версию все равно все собирают GDC/LDC, и кодогенерация у них лучше.

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