[prog.flame] Андрей Александреску о том, что мешает D взлететь

Увидел любопытное на сайте языка D: обсуждение списка причин, которые препятствуют "взлету" D. Этот список Александреску построил на основании общения с разными разработчиками. Данный список содержит пункты, которые не дают потенциальным пользователям выбрать D в качестве рабочего инструмента:

* The garbage collector eliminates probably 60% of potential users right off.

* Tooling is immature and of poorer quality compared to the competition.

* Safety has holes and bugs.

* Hiring people who know D is a problem.

* Documentation and tutorials are weak.

* There's no web services framework (by this time many folks know of D, but of those a shockingly small fraction has even heard of vibe.d)...

* (On Windows) if it doesn't have a compelling Visual Studio plugin, it doesn't exist.

* Let's wait for the "herd effect" (corporate support) to start.

* Not enough advantages over the competition to make up for the weaknesses above.

Т.е. если кратко и по-русски, то получается что-то вроде:

• сборщик мусора мешает 60% потенциальных пользователей;
• набор инструментов так себе, у конкурентов лучше;
• в части безопасности есть и дыры, и баги;
• сложно нанимать людей, которые знали бы D;
• документация и руководства хреновые;
• нет фреймворка для Web-а (и крайне мало кто хотя бы слышал про vibe.d);
• под Windows нет нормальной интеграции с Visual Studio;
• многие ждут, пока за спиной у D встанет какая-нибудь корпорация;
• не так уж много у D преимуществ, чтобы компенсировать вышеперечисленные недостатки.

Общее впечатление от этого списка: наконец-то они начали о чем-то подозревать! :)))

Но вообще несколько удивлен увидеть пункт про сборщик мусора. Походу, ситуация такова:

• для части задач производительность не критична, поэтому можно сидеть на управляемых языках со сборкой мусора (Java, C#, Scala, Python, Ruby, Erlang -- имя им легион). Поэтому смысла связываться с нативным кодом нет от слова совсем;
• для части задач производительность важна, поэтому нужно иметь и нативный код, и сборщик мусора. Но здесь, имхо, получается что-то вроде:
• для части таких задач D со своей сложностью -- это просто оверкилл и вместо D можно использовать гораздо более простые Go и, например, Eiffel;
• для части таких задач с успехом могут использоваться языки "покруче". Скажем, Haskell или OCaml;
• для части задач производительность настолько важна, что нужно иметь и нативный код, и ручное управление памятью. А это вотчина C, Ada и C++ (плюс сюда же нацелен Rust). А языки со сборкой мусора просто идут лесом не смотря ни на какие достоинства.

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

Ну и в связи с этим перспективы Rust выглядят не так уж и плохо (по крайней мере в части бодания с plain old C, а не с C++). Тогда как перспективы Nim-а или какого-нибудь Zimbu -- напротив. Ибо ниша нативных языков с GC уже более чем плотно занята Go, Eiffel, Haskell, OCaml, ну и, возможно, Objective-C и Swift-ом.