D vs C++ , почти сурковская пропаганда: не пора ли C++ потихоньку готовиться к пенсии?

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

Хороший С++ класс - это такой, глядя на который появляется чувство скуки.

Перенастрой подсветку кода, чтоб было нескучно, спроси у Попова как.

Я тебя, надеюсь, правильно понял, korvin?

Цитата Qraizer @ 26.12.14, 21:58

Я тебя, надеюсь, правильно понял, korvin?

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

Цитата Kray74 @ 10.12.14, 15:27

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

Бегло глянул в сети - есть в разработке Qt Creator plugin for D language support, не пробовал пока. На гите указано, что два релиза уже вышло.

Давненько я тут не писал.

Случилась перемога:
JSON-парсер написанный на D стал самым быстрым JSON-парсером среди всех языков, обогнав более чем в два раза (!) предыдущего чемпиона RapidJSON написанного на C++.
Бенчмарки
Обсуждение на реддите

Одна из причин такой шустрости, а заодно преимущество D перед C++:
Благодаря использованию opDispatch обращения к полям JSON-объекта возможно как к свойствам D-шной структуры.
Например:
json.coordinates будет скомпилировано в json.singleKey!("coordinates") - вызов функции с одним компайл-тайм аргументом и без ран-тайм аргументов вообще. В итоге парсер уже на стадии компиляции "знает" какие поля ему нужно парсить и валидировать, а какие можно пропустить.

Цитата applegame @ 22.10.15, 16:37

обогнав более чем в два раза (!) предыдущего чемпиона RapidJSON написанного на C++.

Ага, 226 MB vs 1 MB.

P.S. И да, баян, на LOR'е уже обсудили. =)
https://www.linux.org.ru/news/opensource/12...omment-12028092
https://www.linux.org.ru/news/opensource/12...00?cid=12028749
https://www.linux.org.ru/news/opensource/12...00?cid=12028855
https://www.linux.org.ru/news/opensource/12...00?cid=12028984

Сообщение отредактировано: korvin - 22.10.15, 21:18

Цитата korvin @ 22.10.15, 21:01

Ага, 226 MB vs 1 MB.

Это вырвиглазная SAX-версия, которой без слез нельзя пользоваться, тем более, что по скорости все равно проигрывает. А юзабельный DOM-вариант - 243 Мб против D-шного 226.

P.S. Это не баян - неделя всего прошла.
А приведенные тобой ссылки - жалкий лепет. Никто не мешает включать в парсер на C++ такие же куски асма, SIMD и прочие оптимизации, но пока как-то слабо.

Кроме того я выше описал чисто D-шную фичу.

Добавлено 22.10.15, 21:59
korvin, но вообще обсуждение доставляющее, спасибо за ссылку

Цитата applegame @ 22.10.15, 21:41

Это вырвиглазная SAX-версия, которой без слез нельзя пользоваться, тем более, что по скорости все равно проигрывает. А юзабельный DOM-вариант - 243 Мб против D-шного 226.

Чего? Какой SAX/DOM у JSON?

Цитата applegame @ 22.10.15, 21:41

P.S. Это не баян - неделя всего прошла.
А приведенные тобой ссылки - жалкий лепет. Никто не мешает включать в парсер на C++ такие же куски асма, SIMD и прочие оптимизации, но пока как-то слабо.

Не слабо, а нафиг никому не упало в современном мире. D'шники просто живут в прошлом веке. =)

Ещё Эрик Реймонд в "Философии Unix" писал, насколько незначительны затраты на парсинг текста (причём там речь шла о разборе произвольного текста, а не какого-то строгого формата) по сравнению с преимуществами использования текста вместо бинарных форматов. Ну и опять же, если уж нужен минимальный оверхед на сериализацию/десериализацию, таки используют бинарные форматы (gob, bson и т.п. Erlang, например использует бинарный формат для своих структур) либо более специализированный текстовый формат, который разобрать на любом языке будет не проблема. Впрочем, людей даже разбор xml (который в этом плане сложнее, чем json) не напрягает...

Зато компилятор Go установить на винду (и, возможно, на осх) значительно проще, чем любой из трёх D'шных. =) И это сильно решает, на самом деле.

Цитата applegame @ 22.10.15, 21:41

но вообще обсуждение доставляющее, спасибо за ссылку

Всегда пожалуйста.

Сообщение отредактировано: korvin - 22.10.15, 22:26

Цитата applegame @ 22.10.15, 16:37

Случилась перемога

Перемога имеет привычку превращаться в зраду.

Цитата applegame @ 22.10.15, 16:37

JSON-парсер написанный на D стал самым быстрым JSON-парсером среди всех языков, обогнав более чем в два раза (!) предыдущего чемпиона RapidJSON написанного на C++.

Трудно без профилирования сказать, где самое слабое место SAX варианта. Но сама идея некую схему JSON интегрировать в парсер мне понравилась. Если дело действительно в лишних вызовах обработчика в SAX, то есть есть мнение, что встраивание схемы даже во время исполнения даст тот же результат. Во время компиляции в C++ можно использовать для этого constexpr. В любом случае я над этим поразмышляю - здесь ещё может быть чёткое/нечёткое соответствие схеме, опциональные поля, действия для неуказанных в схеме полях... Интересно, короче.

Цитата applegame @ 22.10.15, 21:41

Никто не мешает включать в парсер на C++ такие же куски асма, SIMD и прочие оптимизации, но пока как-то слабо.

Это серьёзно аргумент за D?

Цитата applegame @ 22.10.15, 21:41

Это вырвиглазная SAX-версия, которой без слез нельзя пользоваться, тем более, что по скорости все равно проигрывает. А юзабельный DOM-вариант - 243 Мб против D-шного 226.

Стоп-стоп. Чемпион никакой DOM не даёт, а фактически массив десериализованных структур. Здесь, кстати, используется рефлексия, которая для C++ пока только в виде предложений.
А вот DOM версия на D даёт результат 12.42 секунд и 1417.1 Mb против C++ DOM 0.94 секунды и 243.6 Mb. Это многое говорит о кодогенерации и потреблении памяти D. И именно эти два примера эквивалентны по функционалу, ибо мы вовсе не всегда знаем структуру JSON.

Цитата korvin @ 22.10.15, 22:23

Чего? Какой SAX/DOM у JSON?

Ну, просто такие выражения. Имеется в виду способ парсинга.

Сообщение отредактировано: MyNameIsIgor - 22.10.15, 23:05

Цитата korvin @ 22.10.15, 22:23

Чего? Какой SAX/DOM у JSON?

Условное название способа парсинга. Можно сказать pull/push парсер, если тебе так больше нравится.

Цитата korvin @ 22.10.15, 22:23

Не слабо, а нафиг никому не упало в современном мире. D'шники просто живут в прошлом веке. =)
бла-бла-бла...

Если не можем обогнать, скажем, что это просто не нужно
На самом деле другим еще как упало, народ возбудился и начал реагировать, например тот самый С++ RapidJSON SAX бенчмарк пояаился буквально вчера.

Цитата korvin @ 22.10.15, 22:23

Зато компилятор Go установить на винду (и, возможно, на осх) значительно проще, чем любой из трёх D'шных. =) И это сильно решает, на самом деле.

Ну это явная ложь. DMD ставится на линупс, макось и винду не сложнее чем Go. Качается бинарный пакет и устанавливается стандартными средствами OS. Для винды это обычный exe-установщик. GDC и LDC - это да на винду поставить еще тот гемор.

Цитата MyNameIsIgor @ 22.10.15, 23:04

Перемога имеет привычку превращаться в зраду.

Ага, именно поэтому это перемога, а не победа.

Цитата MyNameIsIgor @ 22.10.15, 23:04

Стоп-стоп. Чемпион никакой DOM не даёт, а фактически массив десериализованных структур. Здесь, кстати, используется рефлексия, которая для C++ пока только в виде предложений.
А вот DOM версия на D даёт результат 12.42 секунд и 1417.1 Mb против C++ DOM 0.94 секунды и 243.6 Mb. Это многое говорит о кодогенерации и потреблении памяти D. И именно эти два примера эквивалентны по функционалу, ибо мы вовсе не всегда знаем структуру JSON.

По показателям потребления памяти RapidJSON SAX бенчмарк не эквивалентен, потому что не запоминает результаты парсинга. Если еще заполнять массив, а потом в цикле считать сумму как сделано в D-шном бенче, то результаты потребления памяти и скорости ухудшатся.
Что же касается "честного" DOM-парсера, то то что приведено в бенчмарке - это встроенный в стандартную либу достаточно убогий JSON-парсер, который устарел и планируется к замене. Самый быстрый на данный момент "честный" DOM-парсер на D - это кандидат в стандартную либу - std.data.json. Его в бенче нет, надо сделать соответствующий pull-request.
Память он кушает также в районе 200Мб (фктически массив для хранения результатов парсинга), но по скорости уступает раза в три RapidJSON. Тут да, таки зрада.

Цитата MyNameIsIgor @ 22.10.15, 23:04

В любом случае я над этим поразмышляю - здесь ещё может быть чёткое/нечёткое соответствие схеме, опциональные поля, действия для неуказанных в схеме полях... Интересно, короче.

Обработчики - это очень неудобно. В vibe.d сериализаторе аналогичная функциональность реализована через мета-атрибуты, в частности изменение имени поля, опциональность и игнорирование:

struct Data {
    @optional int a = 10;
    string b;
    @name("field") int[] c;
    @ignore List list;
}

Цитата applegame @ 23.10.15, 05:40

Обработчики - это очень неудобно

Это не вопрос удобства, это вопрос необходимости, о чём нам говорит потребление памяти при SAX.

Цитата MyNameIsIgor @ 23.10.15, 07:43

Цитата applegame @ 23.10.15, 05:40

Обработчики - это очень неудобно

Это не вопрос удобства, это вопрос необходимости, о чём нам говорит потребление памяти при SAX.

Низкое потребление памяти - следствие потокового парсинга с обработкой данных на лету, без запоминания результатов парсинга. Обработчики не имеют к этому прямого отношения. Аналогичное поведение можно сделать с помощью ленивых итераторов или ренджей. Я могу написать бенч для std.data.json с таким же мизерным потреблением памяти, правда не такой быстрый как рапид, но зато без обработчиков. Те 200+ мб кушают не сами парсеры, а распарсенные данные в массиве.

Сообщение отредактировано: applegame - 23.10.15, 07:58