Создание D foundation, организации, которая будет заниматься развитием языка

как бы язык формально с 2001 года существует.

Не очень понятно, что вы вкладываете в «формально существует». А история языка D от Вальтера Брайта идет с 1999-го года. В 2001-ом он начал публичные релизы и инфу о языке в публичный доступ выкладывать.

Надо ему на D начать писать «большой и важный» проект, типа как Servo на Rust.

Серво-то денег не приносит.

В 2015 до сих пор надо с памятью руками работать.

Ну положим, не «надо», а «можно». И ничего, что тот же раст тоже про память думать заставляет? А язык-то новый.

Rust кстати отлично заменяет C++.

Но ведь там же нет ГЦ, как же так?

Там нет указателей, вставленных по самые гланды и торчащих изо всех щелей.

это всё на тему «не платишь за те фичи, которые не используешь». но здесь у D потенциальные плюсы

Если мне не изменяет память, то создатели языка где-то писали, что готовы жертвовать производительностью (в разумных пределах) ради других преимуществ.

Там нет указателей, вставленных по самые гланды и торчащих изо всех щелей.

Да ладно? Конечно, кое-что для ГЦ они сделали, посмотрим насколько это реально поможет.

Это убогие костыли

Это не костыли. Это единственный известный способ получить детерминированное удаление объектов/освобождения ресурсов, без ручной работы.

и нормальный GC ими не заменишь.

Так это и не замена GC.

Это не фича

Это фича. И она позволяет в том числе делать RAII, который невозможен в языках с GC. Что приводит к страшным костылям в виде finally, или к неочень страшным в виде with/using/defer.

Просто GC нормально хрен приделаешь когда у тебя указатели присунуты в язык по самые гланды и без них шагу ступить нельзя.

Можно сделать и номормальный GC с определенными ограничениями на использования типов указателей. Уже есть консервативный GC для C/C++. Можно сделать лучше. Просто смысла особого нет. Если нужен GC, проще взять другой язык.

Если у гугла рукожопые разработчики

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

то где чёрт возьми они вообще нормальные?

Во многих местах понемногу=)

Java отлично заменила C++ в энтерпрайзном софте.

Я бы не сказал, что это была замена. Это был качественно новый уровень. И дело тут не в C++. А в отличной приспособленности Java к рукожопым разработчикам, что до сих пор позволяет создавать и писать на Java достаточно сложные штуки достаточно большими коллективами, с возможностью достаточно спокойно менять людей. Идеальный язык, если не со стороны разработчика смотреть.

Сравни треш и угар середины 90х и сейчас.

В России я наблюдал Delphi, в основном. И проекты на C++, как правило, отличались лучшим качеством. Хотя казалось бы.

Rust кстати отлично заменяет C++.

Где?

Это ещё предстоит выяснить.

Выясняйте. Пока она дерьмовая. Хотя бы потому, что не позволит так же просто и постепенно перейти на Rust в моих проектах. В отличие от C++, который позволял таки вполне плавный переход с Си.

Nim нормальная замена) Реквестирую D vs Nim.

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

Так о том и речь... D без сборки уныл.

вот А. Столяров

Не знаком. Не вижу смысла обсуждать его фантазии. Совсем универсальных языков не бывает. Язык нужно выбирать.

Хотя бы потому, что не позволит так же просто и постепенно перейти на Rust в моих проектах.

Модель перехода на Rust, наверное, должна быть такая же, как модель перехода на Python.

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

Тупо «нормальная замена» и все? Ни доводов, ни аргументации?

Я вижу минус в питонообразном синтаксисе и «логике отступами». Вкусовщина, конечно.

Как-то глупо приводить доводы, я на ниме пару хелловорлдов написал. Интересно мнение человека который и его и д попробовал.

Вот и замена C++... Как же я пересяду на rust в своём крестовом проекте? Как же я начну новый, если хочу использовать свой и чужой(библиотечный) код на крестах?

Довольно радикальные изменения. Это тоже от языка отпугивает.

Нет, API не меняется, только то, что «под капотом».

Использование GC не может быть просто «под капотом».

чужой(библиотечный) код на крестах

Через биндинги

Как же я пересяду на rust в своём крестовом проекте?

Старую кодовую базу придётся частично похоронить, а частично - выделить в изолированные библиотеки, и написать для этих библиотек биндинги. Как варинат для больших и хорошо отлаженных крестовых проектов, новые модули (плагины, etc) можно писать на расте, а стрые крестовые модули и некое давно устаканившееся крестовое ядро так и оставить на крестах. Короче, сыграть на low cohesion.

Low coupling, ты хотел сказать?

Точно. Спать больше нужно :(

А скоро ещё и Swift в опенсорс подтянется, будет из чего выбирать :)

Любой ЯП изначально создается под задачу, либо оригинальная задача воспроизводится на не популярном ЯП:

- Java создавался, чтобы пилить софт, который тяжело было пилить на C++. И этот софт сразу же пилили, вкладываясь баблом, по мере развития языка.

- Go создавался, чтобы проще пилить сетевые приложения и их пилят потихоньку.

- Rust как другой взгляд на системное программирование, с фичами которых нет в С. Если они еще добавят важную фичу как переносимый из С++ ООП, то точно взлетит )

- Ruby взлетел из-за оригинального фреймворка

- PHP создавался для простого запила HTML страничек

Проблема этого D, что это сферический ЯП в вакууме. Нет на нем как оригинальных фреймворков. Так и каких-то интересных преимуществ.

По сути он пытается вклиниться в нишу между С++ и Java, но судя по всему в этой нише всего 2.5 человека. Кому надо модулей и простоты хватает Java. Кому надо перформанса хватает C++.

Если они еще добавят важную фичу как переносимый из С++ ООП, то точно взлетит

А как же жить без плюсовых говношаблонов? Срооочно надо добавить в ржавчину и эту важную фичу11 :-D

https://users.rust-lang.org/t/transition-c-c-codebase-to-rust/2562 - Клабник и фаерфокс официально плюсуют вариант с модулями-плагинами.

D создавался, чтобы пилить софт, который тяжело было пилить на C++, но при этом не хотелось отказываться от native performance.

как оригинальных фреймворков

Есть vibe.d, веб-фреймворк, который по производительности может засмущать node.js, но при этом позволяет писать без «лапши колбеков» (и без костылей, которые ее героически преодолевают).

ниосиляторы такие ниосилятора. хотя чо там. Ублюдочность синтаксиса руста уже обогнала ублюдочность плюсовых шаблонов.

А как же жить без плюсовых говношаблонов?

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

Так он уже не нужен, чего его выбирать.

интересная и мощная вещь

Не спорю. А еще они на раз убивают возможность поддерживать код при любом хоть сколько нибудь не примитивном использовании. По крайней мере я не раз был этому свидетелем.

давшая достаточно много в своей области

Плюсам она и правда много всего дала, но в чистом виде в другой язык тащить это точно не надо. Как и плюсовое ооп - пускай в плюсах и остается.

D создавался, чтобы пилить софт, который тяжело было пилить на C++, но при этом не хотелось отказываться от native performance.

Как можно получить нативный перформанс с GC? Где бенчмарки? Его чего-то даже на benchmarksgame нету. Судя по всему перформанс будет сравнимый с Java. А в этом случае какой смысл?

Есть vibe.d, веб-фреймворк, который по производительности может засмущать node.js, но при этом позволяет писать без «лапши колбеков» (и без костылей, которые ее героически преодолевают).

Это даже не смешно, фреймворков уровня vibe сотни на гитхабе, только на java подобных штук 15 (я тут недавно изучал данную тему). Так что тут ничего оригинального нет.

А еще они на раз убивают возможность поддерживать код при любом хоть сколько нибудь не примитивном использовании.

Например?

По крайней мере я не раз был этому свидетелем.

Это где, в игрострое?

Плюсам она и правда много всего дала, но в чистом виде в другой язык тащить это точно не надо.

А в другой и не получится просто так. Уникальность C++ в том, что в нем нет различий между value и reference types. Отсюда и таки шаблоны с такими возможностями.

Уникальность C++ в том, что в нем нет различий между value и reference types

В Rust так же.

Отсюда и таки шаблоны с такими возможностями.

Просто шаблоны Си++ случайно получились Тьюринг-полными %)

А еще они на раз убивают возможность поддерживать код при любом хоть сколько нибудь не примитивном использовании. По крайней мере я не раз был этому свидетелем.

Все зависит от использующих. За шаблоны на шаблонах без внятной цели и пользы конечно нужно отрывать руки. Но при разумном использовании это отличная возможность упростить код. Причем даже <> торчать из кода не будут.

Плюсам она и правда много всего дала, но в чистом виде в другой язык тащить это точно не надо. Как и плюсовое ооп - пускай в плюсах и остается.

«Плюсовое» (если не вдаваться глубже в историю) ООП вполне себе нашло применение в Java и C#. По сути ООП в данном виде самое популярное и широко используемое. Насчет шаблонов - это чуть ли не отдельный язык, причем сложный и еще развивающийся, так что да, копировать его как есть смысла не имеет.

В Rust так же.

Rust пока присутствует в индустрии на уровне статпогрешности или даже ниже. Что будет с Rust-ом нужно посмотреть хотя бы через два-три года.

Просто он понял, что время идет, а как говорится: «Учения не создал, учеников разбазарил...»

Фреймворков то, может, и куча. Но производительность у vibe.d крутая, т.к. он, по сути, хорошая обёртка над libevent. На java по производительности есть только vert.x, приближающийся к vibe.d, но там самому нужно искать/писать middleware, template engine и прочее, короче vert.x не совсем web фреймворк, скорее, это просто сетевой фреймворк типа node.js. Но, в отличии от node.js, под который 100.000 пакетов, под vert.x/java не так много софта.

Например? Это где, в игрострое?

Например, на прошлой работе надо было поддерживать казуалку на кастомном движке. И как-то понадобилось добавить новый тип объектов в местный RPC фреймворк, а там шаблон на шаблоне с хитрой компайлтаймовой логикой. Мне чертовски не понравилось с этим возиться.

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

Фреймворков то, может, и куча. Но производительность у vibe.d крутая

Где бенчмарки?

А в другой и не получится просто так. Уникальность C++ в том, что в нем нет различий между value и reference types.

В Rust так же.

Rust пока присутствует в индустрии на уровне статпогрешности или даже ниже.

Так мы ж про перетягивание в новые языки, которые в индустрии пока присутствуют мало, и говорим. Я не вижу, что технически мешает этого монстра и в компиляторе ржавчины воспроизвести при должном упорстве.

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

Да ладно, половина разбежится только от вида подобного кода:

macro_rules! tuple_impls {
    ($(
        $Tuple:ident {
            $(($idx:tt) -> $T:ident)+
        }
    )+) => {
        $(
            impl<$($T:PartialEq),+> PartialEq for ($($T,)+) {
                #                fn eq(&self, other: &($($T,)+)) -> bool {
                    e!($(self.$idx == other.$idx)&&+)
                }
                #                fn ne(&self, other: &($($T,)+)) -> bool {
                    e!($(self.$idx != other.$idx)||+)
                }
            }
...

И это даже не аналог «шаблона на шаблоне».

Мне чертовски не понравилось с этим возиться.
Но я уверен

Как и следовало ожидать, в лучшем случае ваши претензии объясняются вкусовщиной.

то ровно та же логика, только реализованная на нормальных макросах ржавчины, nim`а или чего подобного

Ну так взяли бы и реализовали. Делов-то...

Только вот, полагаю, реализовать что-то можно на том, что есть и работает. А не на том, что может быть, когда-нибудь, где-нибудь, как-нибудь будет пригодно к использованию в продакшене.

Все это к тому говориться, что рабочие и работающие инструменты таковы, какими их сделала практика использования. Это не только к C++, а к любому мейнстримовому языку относится. Когда же люди пытаются сделать что-то идеальное (или идеализированное) получается долгострой вроде того же D, который здесь рекламирует очередной восторженный неофит.

В интернете, не поверишь. Ищи по «libevent performance».

Зачем мне libevent, когда мы говорим о фреймворке в целом, а значит о цикле: request и respone клиенту. Или когда оно захлебнется от непрерывной загрузки, из-за кривого GC, ты не приделах будешь?

Вы его «захлебните» сначала. А потом посмотрите, как себя поведет под аналогичной нагрузкой Node, RoR и иже с ним Django.

Чисто ЛОРовская фишка - еще в глаза не видели, но уже хороним.

Да ладно, половина разбежится только от вида подобного кода

Боже, какая мерзость! Не то чтобы я плохо относился к Расту, но синтаксис бесчеловечен. И это еще ничего, в вашем коде даже нет ни одного ::

Я думаю, что тебе стоит просто самому протестировать его. Все мы люди взрослые, поэтому убеждать тебя здесь нет смысла. Лично меня от D отталкивает только отсутствие хорошей IDE. В этом плане мне симпатизируют scala+vert.x для rest api, swift + c static lib для числомолотилок. D тоже очень хороший язык, но будущее его туманно, слишком много конкуренции и мало бабок в него вбахивают... Тот же Go, не привнеся ничего нового - вон как развернулся, в принципе, это тоже хорошо, если потеснят java в мобилках... А то Qt, вон, уже пасть разинула на мобилы!