Стоит ли начинать изучать программирование с D?

Изучение программирования следует начинать с алгоритмизации. Тут чем проще язык, тем лучше. Однако если вы хотите изучить Си-подобный язык, то D будет правильным выбором. Синтаксис C/C++ не прост. Это отвлекает от сути. Вместо того, что бы вникать в основы программирования, приходится вникать в язык C/C++. Т.е. начиная с C/C++, вы изучаете именно C/C++, а не программирование как таковое. В этом проблема.

Чем D лучше C#/Java?

Основные затраты по производительности съедают виртуальные машины и run-time компиляция, поэтому и в C# и Java есть компиляторы позволяющие производить компиляцию напрямую в нативный код. D предлагает полную независимость от виртуальных машин и зачастую более простые и понятные для программиста конструкции сравнимые по краткости с Python.

Чем D лучше С++?

Плюса у С++ только два. Минусы стремятся к бесконечности. C++ проектировался очень давно, на основе еще более древнего Си (который сам по себе содержит массу архитектурных решений, которые в современном мире выглядят как ошибки), метапрограмминг на шаблонах С++ вообще получился «случайно» и только потом язык стали ориентировать на эту возможность (но все равно там очень много случайных по сути решений). C++ развивался скорее не благодаря тому, что в него вложили авторы, а вопреки. Авторы вводили нечто, расширяющее возможности обобщенного программирования, а пытливые умы пользователей выискивали пути использовать побочные эффекты от этих нововведений, чтобы обеспечить поддержку того, чего действительно не хватало в языке.

У D есть одно большое преимущество - в нем учтены ошибки, которые были допущены в С++. С++ не может отказаться от совместимости и местами там всё довольно криво и это уже никогда не исправить. Более того, с добавлением новых фич С++ становится сложнее выучить - ведь старые возможности никуда не деваются и о них надо знать.

Также сама концепция ООП наложенная на C++ приводит к наследованию, делегированию и расширению количества ошибок. Это способствует «маскирующему размытию» багов, которые накапливаются по экспоненте. В результате появляются fatality баги, которые можно исправить только путем очередной смены концепции/платформы.

Что касается скорости разработки. Чудес не бывает, unmanaged код практически всегда будет разрабатываться медленее managed кода даже при одном и том же языке, причина — unmanaged код добавляет изрядное кол-во ручное работы по отлову багов. Можно поверить что код на unmanaged и managed языке наберут программисты примерно за одно время, но потом отладка и поиск багов в unmanaged займет значительно больше времени, просто потому что много багов при сборщике мусора просто нет.

Опыт показывает, что при переходе на D с C++ программисты экономят до 50% времени на написание и до 3-4 раз на отладку приложений. Особенно хорошо эта экономия видна при написании продакшен кода с жесткими сроками сдачи проекта, когда нет возможности неделями искать утечки памяти.

Чем D лучше Python?

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

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

На самом деле можно извернуться так чтобы это было можно поддерживать: на 100% покрыть юнит-тестами. но «быстро писать на питоне» - это не тоже самое, что «быстро покрывать тестами на 100%» или «быстро модифицировать все поломаные тесты». В общем реклама как обычно врёт.

Чем D лучше Swift?

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

Чем D лучше Rust?

Крайне сложно представить себе реальный проект в котором писать Rust было бы экономически оправдано. Вся структура языка заточена на то, чтобы вынуждать человека указывать достаточно низкоуровневые подробности не тогда, когда это действительно нужно, а ПОСТОЯННО. Исключение где Rust может быть реально полезен могут составлять только Embedded и hard real-time системы. Однако это капля в море разрабатываемого софта. На Rust нельзя написать ни одной программы, не имея хорошего понимания lifetime & ownership. Это автоматически делает его очень сложным. Так же стоит отметить очень свобразный апострофо-кавычечный синтаксис Rust значительно усложняющий написание кода. D в этом отношении гораздо проще и универсальнее. К тому же в D есть режим `betterC` позволяющий использовать ручное управление памятью и сводящий 80% преимуществ Rust к нулю.

Что значит слово Rust?
  • коррозия; ржавчина
  • моральное разложение; коррупция, продажность
  • вредное влияние безделья, бездеятельности (на характер, способности)
  • ухудшаться, портиться, притупляться, вырождаться (от бездействия)
  • притуплять, ослаблять (память, ум)
  • томиться от безделья
  • портить, развращать, разлагать
Чем D лучше Go?

Go не простой, Go -- примитивный. Go не позволяет делать элементарные обобщения и, как следствие, на нем практически невозможно писать алгоритмы и обрабатывать данные. Структура языка Go стимулирует программистов к написанию лапшеобразного трудноподдерживаемого говнокода. Больше кода, больше ошибок, тяжелее поддержка, дольше разработка, сложнее тестирование, отладка, рефакторинг. В Go полностью отсутствуют инструменты управления сложностью, вроде шаблонов/дженериков, нормального ООП или (спорно) исключений, что фактически делает Go не пригодным для разработки больших проектов.

Пример 1
Пример 2
Пример 3

Go Хорош только для:

  • - людей, не знающих ничего другого;
  • - людей, не писавших на нём ничего, кроме хеллоуворлдов;
  • - людей, исповедующих copypaste-driven programming.

Снижает ли производительность наличие сборщика мусора?

Нет. В реальных проектах, а не синтетических тестах, сборщик мусора делают автоматическую оптимизацию (сборку, копирование, уплотнение объектов в памяти), что повышает производительность, а unmanaged код заставлет тоже самое делать вручную, причем в большинстве своем у программистов нет ресурсов/квалификации повторить тоже самое.

Cейчас производительность машинных кодов вообще дело десятое для 99% бизнес приложений: чтение с диска, чтение с сети, работа с БД, параллельное выполнение, dead lock'и, плохая архитектура — все куда более страшные причины, убивающие prefomance. Есть вещи, где ручное управление памятью может быть действительно необходимо (драйвера, игровые движки и движки СУБД). Для таких случаев в D предусмотрена возможность полного отключения сборщика мусора.

Зачем писать на D если на С++ уже написано миллионы строк кода?

В реальной жизни вы не встретите ни одного серьезного приложения, которое бы базировалось на своей изначальной реализации. Каждые 5 лет мы шагаем в новые измерения и только самый прозорливый разработчик может себе позволить код, который не выкинут через 10 лет. Поэтому не надо бояться использовать современные языки. Они позволяют вам реально сэкономить свое время.

Зачем нужны толстые бинарики если есть Docker?

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

  • - Docker полезен исключительно для воссоздания кривых окружений кривых программ (непременно stateless)
  • - В подавляющем большинстве случаев люди пытаются внедрением Docker компенсировать изначально кривую архитектуру своих приложенияй. Когда это не помогает начинаются разговоры о том, что Kubernetes поможет решить проблемы, но это приводит лишь к новым сложностям
  • - Docker вводит лишний уровень абстракции, зачастую там где она не нужна
  • - Содержимое Docker контейнера крайне плохо поддается аудиту
  • - Docker крайне не прост в настройке и поддержке. Большинство людей которые все же используют докер редко уходят дальше "Just use the docker image"
  • - Корректная настройка Docker требует найма дополнительного персонала с очень специфическими навыками. Уметь правильно настраивать сесть != уметь правильно настраивать сесть в Docker
  • - Docker никогда не бывает один и тянет за собой огромную экосистему. Этим он похож на NodeJS, когда очень скоро оказывается, что ваше Hello World приложение зависит от 300 разных библиотек и плагинов.
  • - Большинство проблем с масштабированием проще\надежнее решить без использования Docker

D позволяет сделать экосистему значительно более простой и прозрачной, а софт переносимым.

Подходит ли D для написания интерпрайз приложений?

В настоящий момент бизнес логику на D пишут такие компании как Sociomantic, EMSI, Weka.IO, Netflix и др. Так же D широко используется в BigData проектах в частности в биоинформатике, так как позволяет писать код эффективно работающий с большими и сверхбольшими объемами данных.

Зачем нужен режим betterC?

Режим betterC позволяет включить усеченный диалект D позволяющий решить огромное количество врожденных проблем Си. Полный список очень большой. Вот лишь краткий перечень возможностей:

  • - Полноценная система импортов
  • - Шаблоны
  • - Удобные unit-тесты
  • - Встроенная система профилирования
  • - User-defined атрибуты
  • - Встроенный и очень удобный генератор документации
  • - Поддержка Unicode
  • - RAII
  • - Ветвление на этапе компиляции
  • - Многое другое.