Комментарии 34
P.S. Примерно в такой же ситуации, мою статью модераторы убрали с сайта, указав, что недопустимо пользоваться автоматическими переводчиками при публикации статьи на ресурсе, согласно правилам сервиса.
(это не автоматический перевод, если кто не заметил, и в то же время этот переводчик с элементами ИИ весьма помогает)
он, наверное, думает — если уж вручную подредактировал текст, то это не автоперевод, это, наверное, какой-то «полуавтоматический» получается
Жена работает в крупном международном агенстве переводов, там переводятся все самые топовые компании. И весь перевод делается из машинного с последующей правкой. Даже если они заявляют обратное.
В D можно использовать динамическую память и без GC (можно как в C руками, а можно как в C++ с RAII), а можно выделять участки программы в которых не будет GC-выделения памяти с помощью атрибута @ nogc. Есть целая серия статей тут.
А если GC отключить, то тогда нельзя использовать некоторые конструкции языка типа ренджей, лямбд по-моему тоже, и стандартной библиотекой тоже нельзя было пользоваться в этом случае, так как она использовала такие конструкции (возможно её уже отвязали от GC).
Какая то работа над новым GC ведется, но я не разбирался в деталях, см презентацию со скоростными характеристиками с DConf 2019
Да, программу с полным отключением GC в D надо планировать писать совсем по-другому — практически без Фобоса и без исключений — это очень тяжело. Но вот вариант совмещения (только критичная часть или тред без GC) выглядит привлекательным для лентяев )
Про тесты не знаю, но я так понимаю что сборщики мусора в C# и Java достаточно хороши
Уже реализован dip для исключений на RC.
Насчёт неиспользуемости стандартной библиотеки без gc не совсем верно сказанно. Большая часть вкусностей перестаёт быть доступна, но многое остаётся. Сами по себе диапазоны как концепция не требуют gc. Можно реализовывать свои диапазоны без gc и такие уже есть в сторонних библиотеках. Единственная конструкция языка, которая не позволяет обойтись без gc это захват контекста делегата.
Людям нужен язык способный быстро и просто решать насущные задачи.
Важны не общие задачи программирования, а быстрое решение задач пользователей, за которые они готовы платить.
Взгляните на php: язык — жуть такой же кривой как javascript, но из коробки и работает с базами данных, изображениями, архивами и еще много с чем. И ресурсов не много требует.
Например нужен не контроль над памятью или отслеживание владения, а упаковка файлов в архив или распаковка видео, работа с векторными форматами, вывод на печать или pdf… Да даже с тем же интерфейсом пользователя пока полная шляпа.
Плюс язык должен обеспечивать поддержание контроля при росте кодовой базы или придётся постоянно и пристально за этим следить самим. Иначе бардак, затык и тепловая смерть.
Во-первых, не стоит путать прикладное ПО и системное. Разные цели и разные средства.
Во-вторых, условный С++ или его условный убийца, нужны, в скажем, в 3-5% задач. Но решить их эффективно в итог можно только на нём, а уже потом поверх городить все остальное. Не стоит забывать, что рантайм к некоторым из прикладных языков написан на Си или С++.
Так что никуда от этого не деться) Даже ассемблер жив до сих пор, просто теперь на нем выполняется 0,001% задач.
Однако современный С++ я бы хоронить не стал даже и для прикладных задач. В нем есть много из современных плюшек всех прикладных языков, а за памятью уже тыщу лет как принято следить через умные указатели.
Я думаю что людям не нужен хороший язык программирования.
Людям нужен язык способный быстро и просто решать насущные задачи.
Хороший язык это тот, который помогает быстро и просто решать насущные задачи.
Важны не общие задачи программирования, а быстрое решение задач пользователей, за которые они готовы платить.
Если язык достаточно мощный, то велика вероятность, что за вас проблему уже кто-то решил, причем лучше и надежнее, чем вы когда-либо могли бы самостоятельно. Я в последней статье собственно в этом в очередной раз убедился.
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 так вообще родом откуда-то из древности, сейчас так даже на Си не пишут.
А как позиционируется D — как убийца С++?
Вы сами задали вопрос и, тут же, сами же и начали критиковать язык за свой же вопрос?
Тогда в чем его киллер-фича по отношению именно к плюсам?
Вы сами задали вопрос и, тут же, сами же и начали критиковать язык за свой же вопрос?Я задал вопрос, ответ на который всем известен. И критикую я именно ответ.
А вот с этим я как раз согласен.
Язык задумывался как системный универсальный — потому охват всех платформ — важная цель.
Еще я переводил сравнение D/Rust/Go от Александреску.
Я как закоренелый сиплюсплюсник уважаю Александреску — в какой-то мере. Но смею напомнить что выражение "укушенный Александреску" появилось весьма не зря. Так что любое сравнение от него я бы "take with a grain of salt". Году эдак в 2017-м он на своей презентации натурально заявлял что концепты в С++ это плохо потому что помешают ему кодить так, как он хочет.
Часто пишу на 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 например, мог бы стать потрясающим языком для машинного обучения.
У D прогрессивная сложностьИМХО это как раз плохо — появляются разные стили языка. Возможно именно поэтому не взлетела Scala. Идеальная кривая для любого промышленного ЯП — невысокая ступенька _|¯
У D тоже получается собрать весьма эффективный код с ldc2, но оптимизаций бэкенда недостаточно. И он никогда не будет столь же быстр как C++.Я бы уточнил тут немного, что потери тут на оптимизации составят единицы процентов. Но только дело не столько в оптимизаторе, а и в спорных технических решениях — классы ссылочные, строки иммутабельные, что тянет постоянную нагрузку на хип.
А вот когда сравниваем с питоном (и пхп), то получаем типичную выгоду в вычислениях 50раз, что есть 5000%… Хотя когда в том же питоне либы сишные, то потери этим нивелируются (пока не придется свои переписывать)
Так что стоит делать оговорки, в каких случаях оптимизатор «плохой» и насколько.
Мое видение будущего D