Мое видение будущего D

Автор оригинала: Atila Neves
  • Перевод
Когда Андрей Александреску покинул пост заместителя руководителя отдела языка программирования 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.

Комментарии 34

    +3
    Допустимо ли при публикации статьи указывать в сноске к ней, что она подоготвлена с помощью сервиса автоматического перевода?

    P.S. Примерно в такой же ситуации, мою статью модераторы убрали с сайта, указав, что недопустимо пользоваться автоматическими переводчиками при публикации статьи на ресурсе, согласно правилам сервиса.
      0
      кстати — да
      (это не автоматический перевод, если кто не заметил, и в то же время этот переводчик с элементами ИИ весьма помогает)


      он, наверное, думает — если уж вручную подредактировал текст, то это не автоперевод, это, наверное, какой-то «полуавтоматический» получается
        0
        Замечания по качеству перевода — прошу в личку. Я пока не понял, как для меня лучше — с помощью дипла или со словарем.
          0

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

        0
        Не совсем понимаю почему D ругают за наличие в языке GC? Нет полного контроля за памятью?
          0
          Скорее это мешает обеспечить realtime.
            +2
            Скорее по инерции тяжелого взросления GC на примере Явы.

            В D можно использовать динамическую память и без GC (можно как в C руками, а можно как в C++ с RAII), а можно выделять участки программы в которых не будет GC-выделения памяти с помощью атрибута @ nogc. Есть целая серия статей тут.
              +2
              Потому что GC в D медленный. Причина в том что в D не стали вводить write barrier, аргументируя это тем что это приведёт к снижению производительности, которое непозволительно для системного языка программирования. А без write barrier нельзя сделать сборщик мусора с поколениями. Поэтому в D каждая сборка мусора — это полная сборка мусора.
              А если GC отключить, то тогда нельзя использовать некоторые конструкции языка типа ренджей, лямбд по-моему тоже, и стандартной библиотекой тоже нельзя было пользоваться в этом случае, так как она использовала такие конструкции (возможно её уже отвязали от GC).
                0
                А есть тесты сравнения быстродействия GC в разных языках? Хотя, конечно это сложно, ведь нагрузка на хип сильно зависит от языка.

                Какая то работа над новым GC ведется, но я не разбирался в деталях, см презентацию со скоростными характеристиками с DConf 2019

                Да, программу с полным отключением GC в D надо планировать писать совсем по-другому — практически без Фобоса и без исключений — это очень тяжело. Но вот вариант совмещения (только критичная часть или тред без GC) выглядит привлекательным для лентяев )
                  0
                  Я так понял что они работают над precise GC, чтобы точно отличать при сборке мусора ссылку от набора битов, но сделать сборку мусора с поколениями это не поможет. И параллельную сборку мусора в другом потоке они тоже сделать не смогут по причине отсутствия write barrier. Только stop the world и полная сборка.
                  Про тесты не знаю, но я так понимаю что сборщики мусора в C# и Java достаточно хороши
                    0

                    Уже реализован dip для исключений на RC.

                    0

                    Насчёт неиспользуемости стандартной библиотеки без gc не совсем верно сказанно. Большая часть вкусностей перестаёт быть доступна, но многое остаётся. Сами по себе диапазоны как концепция не требуют gc. Можно реализовывать свои диапазоны без gc и такие уже есть в сторонних библиотеках. Единственная конструкция языка, которая не позволяет обойтись без gc это захват контекста делегата.

                      0
                      А сложение строк разве не требует GC?
                        0

                        Стандартный синтаксис (операция конкатенации ~) требует, но строки это просто массивы и с ними можно работать как и с другими массивами. Это менее удобно и наглядно, но всё же возможно.

                    +3
                    D себя позиционирует (или позиционировал) как улучшенный C++. При этом, C++ разработчики используют C++ потому, что он позволяет держать память под контролем. Позволяет «не платить за то, что не используешь». Да, GC в D отключаемый, но отключив его мы теряем возможность использовать классы (пока, динамический полиморфизм), а так же динамические и ассоциативные массивы. Конечно существуют библиотеки контейнеров, не использующих GC, но тут уже встает вопрос — зачем все это, если в C++ мы уже имеем тоже самое? При этом в C++ отсутствует проблема interop'а с C++ кодом по определению.
                      +1

                      У D помимо GC ещё есть много разных фишек. Метапрограммирование читабельное и мощное, модули, пакетный менеджер, работа с массивами и т.д. Наконец синтаксис более приятный.

                        +3

                        Если вам нужен современный системный язык с метапрограммированием и мощным пакетным менеджером, то вы всегда можете взять язык youknowwhatimean. И использовать всю мощь std с потенциально нулевым использованием кучи.

                    +1
                    (del)
                      +3
                      Я думаю что людям не нужен хороший язык программирования.
                      Людям нужен язык способный быстро и просто решать насущные задачи.
                      Важны не общие задачи программирования, а быстрое решение задач пользователей, за которые они готовы платить.
                      Взгляните на php: язык — жуть такой же кривой как javascript, но из коробки и работает с базами данных, изображениями, архивами и еще много с чем. И ресурсов не много требует.
                      Например нужен не контроль над памятью или отслеживание владения, а упаковка файлов в архив или распаковка видео, работа с векторными форматами, вывод на печать или pdf… Да даже с тем же интерфейсом пользователя пока полная шляпа.
                      Плюс язык должен обеспечивать поддержание контроля при росте кодовой базы или придётся постоянно и пристально за этим следить самим. Иначе бардак, затык и тепловая смерть.
                        +1

                        Во-первых, не стоит путать прикладное ПО и системное. Разные цели и разные средства.


                        Во-вторых, условный С++ или его условный убийца, нужны, в скажем, в 3-5% задач. Но решить их эффективно в итог можно только на нём, а уже потом поверх городить все остальное. Не стоит забывать, что рантайм к некоторым из прикладных языков написан на Си или С++.


                        Так что никуда от этого не деться) Даже ассемблер жив до сих пор, просто теперь на нем выполняется 0,001% задач.


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

                          0
                          Ну 3-5% это очень интересная оценка. Я бы предложил заглянуть, скажем в «установку и удаление программ» и посчитать процент там =)
                          0
                          Я думаю что людям не нужен хороший язык программирования.
                          Людям нужен язык способный быстро и просто решать насущные задачи.

                          Хороший язык это тот, который помогает быстро и просто решать насущные задачи.


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

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

                          +1
                          Хотя бы свойства (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 так вообще родом откуда-то из древности, сейчас так даже на Си не пишут.
                            +3
                            Лично меня до сих пор от __property корежит. Когда D/D2 вышел — он был красивым, чистым языком, в который потом натащили со свалки отовсюду атрибуты, трейты итд и этот процесс продолжается…
                              0
                              Да, производит впечатление некоторой бессистемности. Как будто сначала продумывали язык, а в какой-то момент просто стали добавлять возможности «абы как». Хотя все это и хорошие возможности, но вот не хватает продуманности в мелочах.
                            +2
                            А как позиционируется D — как убийца С++? Тогда в чем его киллер-фича по отношению именно к плюсам? А тогда при чем здесь мобильная разработка? Не слишком ли широко берут его создатели?
                              –2
                              А как позиционируется D — как убийца С++?

                              Вы сами задали вопрос и, тут же, сами же и начали критиковать язык за свой же вопрос?


                              Тогда в чем его киллер-фича по отношению именно к плюсам?
                                +1
                                Вы сами задали вопрос и, тут же, сами же и начали критиковать язык за свой же вопрос?
                                Я задал вопрос, ответ на который всем известен. И критикую я именно ответ.
                                А вот с этим я как раз согласен.
                                0
                                Не убийца, но скорее преемник. Киллер-фичи — безопасность по умолчанию и удобное метапрограммирование, вылившееся в кардинально другую стандартную библиотеку.

                                Язык задумывался как системный универсальный — потому охват всех платформ — важная цель.

                                Еще я переводил сравнение D/Rust/Go от Александреску.
                                  0

                                  Я как закоренелый сиплюсплюсник уважаю Александреску — в какой-то мере. Но смею напомнить что выражение "укушенный Александреску" появилось весьма не зря. Так что любое сравнение от него я бы "take with a grain of salt". Году эдак в 2017-м он на своей презентации натурально заявлял что концепты в С++ это плохо потому что помешают ему кодить так, как он хочет.

                                    0
                                    Слепо доверять чужому мнению конечно не стоит. Я например, сначала прочитал учебники по D/Rust/Go/Python итд

                                    Кстати, concepts и ranges, которые появятся в С++20, давным давно есть в D. Оттуда Комитет заимствовал идею или нет, уж не знаю.
                                +8

                                Часто пишу на D и C++ и как C++ разработчик вижу проблему D в неправильном позиционировании.
                                Слоган D: "write fast, read fast, run fast" и это в целом правда. На D действительно можно быстро писать читаемый код, который при этом будет относительно быстро исполняться. Есть режим "интерпретатора" для быстрой отладки и прототипирования.
                                Язык очень удобен, но ни как замена C++, а как замена Python!
                                Современный С++ самодостаточен и хорош для тех кто его знает. Пытаясь стать заменой C++ D плывёт против течения.
                                Высокая производительность C++ обусловлена:


                                1. Возможностью полностью контролировать поток выполнения как на высоком так и на низком уровне
                                2. Возможностью фронтенда компилятора выполнять оптимизации, недоступные в более безопасных языках. Все эти вещи, которые помечены в стандарте как UB дают компилятору возможность для оптимизаций.
                                  У D тоже получается собрать весьма эффективный код с ldc2, но оптимизаций бэкенда недостаточно. И он никогда не будет столь же быстр как C++. Даже без учёта GC.

                                А вот использовать D там, где используют, например Python, действительно круто.
                                У D достаточно много библиотек (хотя многие и весьма сырые). У D прогрессивная сложность. На нём легко начать писать с минимальной подготовкой. Код получается компактный и читаемый. Потрясающая шаблонная магия позволяет делать красивые библиотеки, которыми легко пользоваться. Встроенные юниттесты. Типобезопасность. Бинарь без зависимостей на выходе. И много много чего ещё.


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

                                  +2
                                  У D прогрессивная сложность
                                  ИМХО это как раз плохо — появляются разные стили языка. Возможно именно поэтому не взлетела Scala. Идеальная кривая для любого промышленного ЯП — невысокая ступенька _|¯
                                    +1
                                    У D тоже получается собрать весьма эффективный код с ldc2, но оптимизаций бэкенда недостаточно. И он никогда не будет столь же быстр как C++.
                                    Я бы уточнил тут немного, что потери тут на оптимизации составят единицы процентов. Но только дело не столько в оптимизаторе, а и в спорных технических решениях — классы ссылочные, строки иммутабельные, что тянет постоянную нагрузку на хип.
                                    А вот когда сравниваем с питоном (и пхп), то получаем типичную выгоду в вычислениях 50раз, что есть 5000%… Хотя когда в том же питоне либы сишные, то потери этим нивелируются (пока не придется свои переписывать)

                                    Так что стоит делать оговорки, в каких случаях оптимизатор «плохой» и насколько.

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое