Массивы в ini делаются спокойно

Ключевое слово «делаются». В json они уже есть для всех языков

json можно автоматически отформатировать и получить конфетку. а в yaml если ошибся индентацией получишь фигу и иди ищи где накосячил. если от программистов на питоне еще можно требовать дисциплины и нужного количества пробелов, то юзера ты никак не заставишь (научишь). вывод: yaml - кусок говна.

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

Массивы в ini делаются спокойно

Ключевое слово «делаются». В json они уже есть для всех языков

Если говорить о готовых и вылизанных инструментах, то тут json вне конкуренции. Удивительно, но даже xml не дотягивает до него по охвату языков.

С другой стороны, вам эзотерические языки, и ли вам human-friendly конфиги?

Инфраструктура D развивается и это хорошо! Остальные нытики могут вернуться к своему похапэжабоскриптам и пахать на этом непотребстве.

Ну и? Это нихрена не «часть языка», а убогая паста из гнуцэ. При этом чисто для галочки.

О, царь в треде.

Это нихрена не «часть языка», а убогая паста из гнуцэ.

Показательно, что этой «части языка» в обсуждаемой библиотеке оказалось не достаточно, и аффтары свалились в x86 ассемблер Парсер JSON, написанный на D, стал самым быстрым парсером JSON в мире (комментарий)

- Rejects numbers with exponents of huge magnitude (>=10^28)

И что же из этого следует? С какого хрена он должен уметь в бигнум? Я не увидел даже намёка на бигнум в rfc7159.

Only works on Posix x86/amd64 systems

А из этого?

- No write capabilities

А с чего он должен это уметь? И нахрена?

- Data size limited by available contiguous virtual memory

Зачем ты пишешь в том, в чём нихрена не понимаешь? Ну давай я задам вопрос: Что это значит и что из этого следует?

А его кто-то реально использует? По-моему, все пакеты как пользовались, так и пользуются dub.json (который, правда, как известно, даже не совсем json, а невалидный-json-с-поддержкой-висячих-запятых). Это что, кто-то собрался депрекейтить? Или можно не обращать внимания?

Планируется поддерживать оба формата неопределённо долгое время (но не вечно), в новых версиях dub.sdl генерируется в шаблоне проекта по умолчанию. ЕМНИП в одном из ближайших релизов запланирована команда для автоматической конвертации dub.sdl <-> dub.json

Мало того, что новость ерунда, так автор ещё и не понимает, о чём пишет. «Fast» — это общее название набора библиотек, каким боком оно к парсеру — знает только он.

это скорее к вложенности относится

[first][second]
key=value

или

[first\second]
key=value

или

[first]
second\key=value

как раз варианты вложенности в ini. А вот ключ, как список - там такого нет, нужно делать какой то workaround типа, как я предложил или строку и потом парсить. QSettings делает, насколько я помню, именно так при преобразовании строки:

a = QSettings('file', QSettings.IniFormat)
a.beginGroup('first')
a.setValue('key', ['val1', 'val2', 'val3'])
a.endGroup()
a.sync()

даст в итоге:

[first]
key=val1, val2, val3

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

передавать сразу структуры, без ручного разбора

Ты про рефлексию что ли?

Зачем нужен JSON, когда есть INI?

Зачем нужна девушка, когда есть бабушка?

Я привел достоверную информацию из надежных источников и считаю что будет полезно указать ее в тексте новости. Если тебя интересует мое личное мое мнение по данным вопросам то вот:
1) бигнум не обязателен, но простой double должен быть.
2) люди должны знать что этот проект x86-only. на embedded платформах тоже есть необходимость парсить json.
3) no-write: если нужна возможность и читать и писать то придется тащить сразу две библиотеки. при том что та что умеет писать наверняка умеет и читать. получится два парсера в проекте.
4) На 32 битных системах виртуальная память не резиновая. хоть это и наименьшая из проблем, но тоже заслуживает внимание.
P.S. Что ты так нервничаешь? Сходи валерьяночки выпей что ли, побереги здоровье.

Сходу можно подумать что это С.

Но это не С, сюрприз. Поэтому аналогия с питоном неуместна.

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

сделал парсер JSON на D самым быстрым парсером в мире, обгоняя парсер на Python в более чем 6 раз по памяти и в 14 раз по скорости.

обгоняя парсер на Python

А он что, эталон?

Мнение аналитика

Сомнительный бенч от некоего Костяна. Зачем-то указывается потребление ОЗУ, когда и без него очевидно, что будет в случае загона миллиона строк в оперативку. А уж про то, что в некоторых тестах данная строка проходит через копирование при передаче как аргумента в функцию (дабл потребление озу by mistake), а не ссылки на эту строку я промолчу.

А вот значение, как список

очевидный фикс

«жава есть хоть под тостер, у всех всё зашибись»

Так это правда. Я сам тут недавно очень удивился, что JavaME очень активно используется во всяких IoT и прочем таком, а я думал, что она умерла. Скоро Java One будет так там штук 15-20 докладов именно про это, причем не только от оракла, а всякие арм и интел есть. Так что, как говорится, век живи - век учись. Если мы этого не видим, то не значит, что это нет.

Ну и вдогонку. Не так давно пришла рассылка. Так что через пяток лет джава вернется и на мобилки :D

Т.е. хотите сказать, что если писать быстрый код на D, он будет подозрительно похож на C, и поэтому D не нужен, так как ничего нового не дает? С таким можно согласиться.
Особенно после того, как выяснилось, что в GNU C аналогичный simd (причем более грамотно реализованный) присутствует.

почему решительно все они (популярные) безбожно тормозят?

google://Синтакстический+анализ+кода. Не тупое индексирование всех токенов, которое быстрым сделать можно, а именно анализ AST.

качеством работы

От ЯП не зависит вообще. Зависит от среды выполнения и программиста. Ты те-же кресты тоже для JVM скомпилировать сможешь, если компилятор напишешь.

Не путай язык и среду выполнения.

Ты надеюсь понимаешь, что твоё сообщение было обработано приложением на Java?

Ты еще симкарты забыл, где тоже Java есть. :) Хоть и сильно кастрированная, и тоже только в роле языка, но таки Java.

Вообще-то логически в чем проблема юзать бинарные строки в json - непонятно, экранируй себе " и все, чо надо-то еще?

Это в javascript`ах и питонах всяких наркоманство, когда Unicode строка и бинарная строка два разных класса...

А какой формат конфигов одновременно человекочитаем и поддерживает бинарники?

JSON, на мой вкус, человекочитаем довольно условно. Его суперсет — YAML — много лучше читается (и пишется!) человеками. При этом ровно столь же пригоден для машинной обработки. Впрочем, вопрос удобного всем хранения конфигов и других несложных структурированных данных скорее открыт, чем закрыт.

обгоняя парсер на Python

А почему сравнение идет с аутсайдером? Haskell и Lisp не завезли => говно, а не сравнение.

Вообще бенчмарки дело неблагодарное, но я свято верю, что всю эту братию в н-цать раз обошел бы jsmn.

Его суперсет — YAML — много лучше читается (и пишется!) человеками

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

это достоинство Ди в том, что он может лавировать как между байто*бством так и ООП, контрактами и прочими необходимыми в 21 веке вещами.

Починил тебя

Зачем нужна девушка, когда есть бабушка?

Зачем нужна девочка, когда есть бабушка?

xml

Сделай одолжение, сделай как Томми. За XML надо гнать из профессии.

зачет отказываться?

Отсыпь, братишка.

Не отсыплю. Занадто опасная. С полкосого вырвет крышу и будешь часа четыре хихикать как глупая школьница.

Пробелы не всегда добавляют читаемости, и YAML как раз тот самый случай

Согласен. Но у меня практический опыт есть. Люди, слегка далёкие от айтишных профдеформаций, намного меньше фейлят с YAML, чем с JSON. Меньше, чем с YAML — только с INI, но боженька был к нам немилосерден и послал техническую необходимость в упорядоченных массивах.

level_0_sublevel_0_key_0 = value

Чем это хуже иерархии json?

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

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

напиши парсер на js и выложи результаты теста, а мы посмеёмся :)

Люди, слегка далёкие от айтишных профдеформаций намного меньше фейлят с YAML, чем с JSON.

Такие люди в электронных таблицах данные забивают. а не в каких то непонятных форматах

ну допустим

https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Global_Objects...

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays

js и производительность как тут соотносятся?

Я правильно понимаю, что навык внимательного чтения не в почёте? Слово «слегка» там не для красоты повествования.

js и производительность как тут соотносятся?

без понятия. Это вопрос к Manhunt

Бенчи cJSON и pbnjson(часть проекта WebOS) в студию!

Жаба же

Вот тее и джсон. Филл фрии то провайд э патч, блеать.

https://issues.apache.org/jira/browse/THRIFT-2336

Правильность

Только писю полируют на предмет скорости. А что насчет полноты и правильности? https://youtrack.jetbrains.com/issue/PY-16319 Это чтоли?

Писькомеры хреновы.

А какой формат конфигов одновременно человекочитаем и поддерживает бинарники?

s-exp

Много на PowerPC, а судя по коду там с ним все почти так-же плохо как и с ARM.

Что и откуда установить для сборки json теста для D?
Строка «gdc (crosstool-NG crosstool-ng-1.20.0-232-gc746732 - 20150830-2.066.1-dadb5a3784) 5.2.0» как бы намекает что надо собирать из исходников и готового пакета нет?
Так-же как я понял D Gdc это компиляции D с помощью GCC? То-есть теоретически можно сделать такой код на С++ или С который после компиляции будет бинарно идентичен D Gdc Fast? Тогда, мне интересно за счет чего реализация на D превосходит rapidjson в котором вроде как выжали чуть-ли не все что можно.

Crystal Pull 2.70 1.2
C++ LibJson 5.49 2796.3

Что это за Crystal Pull, и почему он потребляет 1.2 мегабайта, а C++ LibJson 2796?

Вот черт! Я отстал походу ) Спасибо!

Посмотрел по диагонали.

Сложилось впечатление, что:

1) парсер оптимизирован для x86_64. Как он себя будет вести на других архитектурах, бабушка надвое сказала. 2) Не используются библиотеки. И механизмы работы с объектами и памятью и преобразованиями типов самого Д. Особенно подозрительна работа со строками. Все захардкодено самым примитивным образом. Просто не верю, глядя на все эти поиски и подстановки префиксов в строках, что поддержка utf-8 там полная.

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