Когда Андрей Александреску покинул пост заместителя руководителя отдела языка программирования D, меня попросили взять на себя эту роль в будущем. Нет необходимости говорить об этом, но я все равно скажу, что эта шапка на меня великовата.Я все еще вхожу в свою новую роль в обществе и выясняю, как я хочу действовать и что это вообще такое. Этот процесс происходит не в вакууме, так как Уолтер тоже с нами.
На форумах D меня попросили написать в блоге о моих «мечтах и дальнейших шагах для D», так вот результат. Что бы я хотел, чтобы стало с D в ближайшем будущем:
Безопасность памяти
«Но D — язык с GC!», слышу я ваши восклицания. Да, но это также системный язык программирования с нессылочными типами и указателями, что означает, что сегодня D не является полностью безопасным по работе с памятью. DIP1000 был шагом в правильном направлении (прим.пер.система заимствования, как в Rust, см.тут), но работа с памятью должна стать безопасной до тех пор, пока программист не откажется через «Я знаю, что я делаю» с помощью @ trusted атрибута блока или функции. Это подразумевает переход на @ safe по умолчанию.
Простая и надежная многопоточность
Мы в большинстве своем уже в нужной точке — использование модели акторов устраняет многие проблемы, обычно возникающие. Осталось закончить работу над атрибутом shared и сделать всё @ safe.
Сделать D языком программирования по умолчанию
Возможности D в плане статической рефлексии и генерации кода делают его идеальным кандидатом для создания кода, который должен вызываться из нескольких различных языков и окружений (например Python, Excel, R и т.д.). Обычно это делается путем спецификации структур данных и вызовов RPC на языке определения интерфейсов (IDL), а затем переводится на поддерживаемые языки с соответствующим протоколом обмена.
В случае с D, ничего из этого не нужно. Можно написать промышленный код на D и с помощью библиотек этот код можно будет автоматически вызывать из других языков. Добавьте ко всему этому, что можно легко писать код на D, который работает так же быстро или быстрее, чем альтернативы, и это будет победа на всех фронтах.
Непревзойденная рефлексия
Вместо разрозненных способов работы с фрагментированными API (__traits, std.traits, велосипеды), я бы хотел, чтобы была библиотека, которая централизовала бы все потребности в рефлексии с прекрасным API. Я уже работаю над этим.
Упрощение интероперабельности с С++
Как я уже упоминал в своем выступлении на DConf 2019, C++ достиг успеха, сделав переход от языка Си практически бесшовным. Я бы хотел, чтобы нынешние программисты на языке C++ с устаревшей кодовой базой так же легко могли начать писать код на D. Вот почему я написал dpp (прим.пер.транслятор заголовков С++ в D), но это еще не все, и нам, возможно, придется внести изменения в язык, чтобы адаптировать это в будущем.
Быстрота разработки
Я думаю, нам нужен невероятно быстрый интерпретатор, чтобы мы могли отказаться от постоянной машинной генерации кода и компоновки. По-моему, это должен быть стандартный способ запуска unittest блоков (прим.пер.юнит-тесты встроены в язык) для обеспечения быстрой обратной связи, и чтобы программистам приходилось компилировать свой код только для достижения максимальной производительности и/или для развертывания конечным пользователям. Это также позволило бы ввести REPL.
Интерполированные строки
Изначально я был против этого, но чем больше я об этом думал, тем больше это было логично для D. Почему? Строковые миксины. Генерация кода является одной из сильнейших сторон D, а строковые токены позволяют визуально радовать блоками кода, которые на самом деле являются «просто строками». Интерполяция строк значительно упростила бы их использование. Пока что в разработке находится черновой вариант DIP.
Именно это мне и пришло в голову после долгой прогулки вдоль Женевского озера. Я хотел бы знать, что сообщество об этом думает, какие у них любимые мозоли и возможности в D, и как, по их мнению, это поможет или затруднит прогресс для D.
Обсуждение на D-форуме тут
Переведено с помощью www.DeepL.com/Translator (это не автоматический перевод, если кто не заметил, и в то же время этот переводчик с элементами ИИ весьма помогает)
P.S. Кто пропустил предыдущую статью из блога про планы D для мобильной разработки. Ее заподозрили в рекламе (ах, упоминается донат) и исключили из хаба D.
Комментарии (31)
neurocore
17.10.2019 18:53Не совсем понимаю почему D ругают за наличие в языке GC? Нет полного контроля за памятью?
Siemargl Автор
17.10.2019 19:31+2Скорее по инерции тяжелого взросления GC на примере Явы.
В D можно использовать динамическую память и без GC (можно как в C руками, а можно как в C++ с RAII), а можно выделять участки программы в которых не будет GC-выделения памяти с помощью атрибута @ nogc. Есть целая серия статей тут.
DieselMachine
17.10.2019 20:38+1Потому что GC в D медленный. Причина в том что в D не стали вводить write barrier, аргументируя это тем что это приведёт к снижению производительности, которое непозволительно для системного языка программирования. А без write barrier нельзя сделать сборщик мусора с поколениями. Поэтому в D каждая сборка мусора — это полная сборка мусора.
А если GC отключить, то тогда нельзя использовать некоторые конструкции языка типа ренджей, лямбд по-моему тоже, и стандартной библиотекой тоже нельзя было пользоваться в этом случае, так как она использовала такие конструкции (возможно её уже отвязали от GC).Siemargl Автор
17.10.2019 22:55А есть тесты сравнения быстродействия GC в разных языках? Хотя, конечно это сложно, ведь нагрузка на хип сильно зависит от языка.
Какая то работа над новым GC ведется, но я не разбирался в деталях, см презентацию со скоростными характеристиками с DConf 2019
Да, программу с полным отключением GC в D надо планировать писать совсем по-другому — практически без Фобоса и без исключений — это очень тяжело. Но вот вариант совмещения (только критичная часть или тред без GC) выглядит привлекательным для лентяев )DieselMachine
17.10.2019 23:54Я так понял что они работают над precise GC, чтобы точно отличать при сборке мусора ссылку от набора битов, но сделать сборку мусора с поколениями это не поможет. И параллельную сборку мусора в другом потоке они тоже сделать не смогут по причине отсутствия write barrier. Только stop the world и полная сборка.
Про тесты не знаю, но я так понимаю что сборщики мусора в C# и Java достаточно хороши
deviator
18.10.2019 12:23Насчёт неиспользуемости стандартной библиотеки без gc не совсем верно сказанно. Большая часть вкусностей перестаёт быть доступна, но многое остаётся. Сами по себе диапазоны как концепция не требуют gc. Можно реализовывать свои диапазоны без gc и такие уже есть в сторонних библиотеках. Единственная конструкция языка, которая не позволяет обойтись без gc это захват контекста делегата.
DieselMachine
18.10.2019 19:46А сложение строк разве не требует GC?
deviator
21.10.2019 12:09Стандартный синтаксис (операция конкатенации
~) требует, но строки это просто массивы и с ними можно работать как и с другими массивами. Это менее удобно и наглядно, но всё же возможно.
phantom-code
17.10.2019 21:09+1D себя позиционирует (или позиционировал) как улучшенный C++. При этом, C++ разработчики используют C++ потому, что он позволяет держать память под контролем. Позволяет «не платить за то, что не используешь». Да, GC в D отключаемый, но отключив его мы теряем возможность использовать классы (пока, динамический полиморфизм), а так же динамические и ассоциативные массивы. Конечно существуют библиотеки контейнеров, не использующих GC, но тут уже встает вопрос — зачем все это, если в C++ мы уже имеем тоже самое? При этом в C++ отсутствует проблема interop'а с C++ кодом по определению.
deviator
18.10.2019 12:31+1У D помимо GC ещё есть много разных фишек. Метапрограммирование читабельное и мощное, модули, пакетный менеджер, работа с массивами и т.д. Наконец синтаксис более приятный.
PsyHaSTe
18.10.2019 15:18Если вам нужен современный системный язык с метапрограммированием и мощным пакетным менеджером, то вы всегда можете взять язык youknowwhatimean. И использовать всю мощь std с потенциально нулевым использованием кучи.
kovserg
17.10.2019 23:17Я думаю что людям не нужен хороший язык программирования.
Людям нужен язык способный быстро и просто решать насущные задачи.
Важны не общие задачи программирования, а быстрое решение задач пользователей, за которые они готовы платить.
Взгляните на php: язык — жуть такой же кривой как javascript, но из коробки и работает с базами данных, изображениями, архивами и еще много с чем. И ресурсов не много требует.
Например нужен не контроль над памятью или отслеживание владения, а упаковка файлов в архив или распаковка видео, работа с векторными форматами, вывод на печать или pdf… Да даже с тем же интерфейсом пользователя пока полная шляпа.
Плюс язык должен обеспечивать поддержание контроля при росте кодовой базы или придётся постоянно и пристально за этим следить самим. Иначе бардак, затык и тепловая смерть.MooNDeaR
18.10.2019 01:26Во-первых, не стоит путать прикладное ПО и системное. Разные цели и разные средства.
Во-вторых, условный С++ или его условный убийца, нужны, в скажем, в 3-5% задач. Но решить их эффективно в итог можно только на нём, а уже потом поверх городить все остальное. Не стоит забывать, что рантайм к некоторым из прикладных языков написан на Си или С++.
Так что никуда от этого не деться) Даже ассемблер жив до сих пор, просто теперь на нем выполняется 0,001% задач.
Однако современный С++ я бы хоронить не стал даже и для прикладных задач. В нем есть много из современных плюшек всех прикладных языков, а за памятью уже тыщу лет как принято следить через умные указатели.
Siemargl Автор
18.10.2019 09:26Ну 3-5% это очень интересная оценка. Я бы предложил заглянуть, скажем в «установку и удаление программ» и посчитать процент там =)
PsyHaSTe
18.10.2019 15:20Я думаю что людям не нужен хороший язык программирования.
Людям нужен язык способный быстро и просто решать насущные задачи.Хороший язык это тот, который помогает быстро и просто решать насущные задачи.
Важны не общие задачи программирования, а быстрое решение задач пользователей, за которые они готовы платить.
Если язык достаточно мощный, то велика вероятность, что за вас проблему уже кто-то решил, причем лучше и надежнее, чем вы когда-либо могли бы самостоятельно. Я в последней статье собственно в этом в очередной раз убедился.
NeoCode
17.10.2019 23:20Хотя бы свойства (properties) сделали бы для сокращенных операций:)
module d_properties; import std.stdio; struct Foo { int z; @property bar() { writeln("getter"); return z; } @property bar(int x) { writeln("setter"); z = x; } } int main() { Foo foo; int x = foo.bar; // ok foo.bar = 10; // ok foo.bar = foo.bar + 20; // ok foo.bar += 20; // error: `foo.bar()` is not an lvalue and cannot be modified getchar(); return 0; }
А вообще впечатление интересное. Я уже писал здесь что изучаю компилятор с целью создания на базе Ди своего языка программирования. Даже пришлось для этой цели написать систему разметки кода маркерными комментариями.
Код, скажем так, весьма специфический. Глядя на исходники компилятора, лучше всего понимаешь, что сам синтаксис языка нуждается в серьезном редизайне. Причем переписывание авторами исходников с С++ на D лишь причесало некоторые «формальные» стороны, а по сути осталось все то же самое. Backend так вообще родом откуда-то из древности, сейчас так даже на Си не пишут.Siemargl Автор
17.10.2019 23:43+2Лично меня до сих пор от __property корежит. Когда D/D2 вышел — он был красивым, чистым языком, в который потом натащили
со свалкиотовсюду атрибуты, трейты итд и этот процесс продолжается…NeoCode
18.10.2019 09:21Да, производит впечатление некоторой бессистемности. Как будто сначала продумывали язык, а в какой-то момент просто стали добавлять возможности «абы как». Хотя все это и хорошие возможности, но вот не хватает продуманности в мелочах.
Vlad800
18.10.2019 05:08А как позиционируется D — как убийца С++? Тогда в чем его киллер-фича по отношению именно к плюсам? А тогда при чем здесь мобильная разработка? Не слишком ли широко берут его создатели?
keksmen
18.10.2019 08:49А как позиционируется D — как убийца С++?
Вы сами задали вопрос и, тут же, сами же и начали критиковать язык за свой же вопрос?
Тогда в чем его киллер-фича по отношению именно к плюсам?
Siemargl Автор
18.10.2019 09:30Не убийца, но скорее преемник. Киллер-фичи — безопасность по умолчанию и удобное метапрограммирование, вылившееся в кардинально другую стандартную библиотеку.
Язык задумывался как системный универсальный — потому охват всех платформ — важная цель.
Еще я переводил сравнение D/Rust/Go от Александреску.
rotor
18.10.2019 12:35+1Часто пишу на D и C++ и как C++ разработчик вижу проблему D в неправильном позиционировании.
Слоган D: "write fast, read fast, run fast" и это в целом правда. На D действительно можно быстро писать читаемый код, который при этом будет относительно быстро исполняться. Есть режим "интерпретатора" для быстрой отладки и прототипирования.
Язык очень удобен, но ни как замена C++, а как замена Python!
Современный С++ самодостаточен и хорош для тех кто его знает. Пытаясь стать заменой C++ D плывёт против течения.
Высокая производительность C++ обусловлена:
- Возможностью полностью контролировать поток выполнения как на высоком так и на низком уровне
- Возможностью фронтенда компилятора выполнять оптимизации, недоступные в более безопасных языках. Все эти вещи, которые помечены в стандарте как UB дают компилятору возможность для оптимизаций.
У D тоже получается собрать весьма эффективный код с ldc2, но оптимизаций бэкенда недостаточно. И он никогда не будет столь же быстр как C++. Даже без учёта GC.
А вот использовать D там, где используют, например Python, действительно круто.
У D достаточно много библиотек (хотя многие и весьма сырые). У D прогрессивная сложность. На нём легко начать писать с минимальной подготовкой. Код получается компактный и читаемый. Потрясающая шаблонная магия позволяет делать красивые библиотеки, которыми легко пользоваться. Встроенные юниттесты. Типобезопасность. Бинарь без зависимостей на выходе. И много много чего ещё.
D например, мог бы стать потрясающим языком для машинного обучения.
Vlad800
18.10.2019 14:59У D прогрессивная сложность
ИМХО это как раз плохо — появляются разные стили языка. Возможно именно поэтому не взлетела Scala. Идеальная кривая для любого промышленного ЯП — невысокая ступенька _|?
FForth
Допустимо ли при публикации статьи указывать в сноске к ней, что она подоготвлена с помощью сервиса автоматического перевода?
P.S. Примерно в такой же ситуации, мою статью модераторы убрали с сайта, указав, что недопустимо пользоваться автоматическими переводчиками при публикации статьи на ресурсе, согласно правилам сервиса.
w3ga
кстати — да
он, наверное, думает — если уж вручную подредактировал текст, то это не автоперевод, это, наверное, какой-то «полуавтоматический» получается
Siemargl Автор
Замечания по качеству перевода — прошу в личку. Я пока не понял, как для меня лучше — с помощью дипла или со словарем.
JKot
Жена работает в крупном международном агенстве переводов, там переводятся все самые топовые компании. И весь перевод делается из машинного с последующей правкой. Даже если они заявляют обратное.