но сколько они проживут если поддержка гугла пропадёт?

но сколько они проживут если поддержка гугла пропадёт?

Сколько весь мир проживает без гугл?))

https://github.com/mleise/fast/blob/master/source/fast/json.d

А как оно с потоками данных работает?

но сколько они проживут если поддержка гугла пропадёт?

Я вот думаю что норм проживут, база уже готова серьезная

А как оно с потоками данных работает?

Я не пользовался, просто знаю что есть такое

Сколько весь мир проживает без гугл?))

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

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

Согласен

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

Я не пользовался, просто знаю что есть такое

Ну вот, уже 3 кандидатуры. А ещё через год напишут ещё 2. И каждая будет в чём-то лучше. Потому не надо в стд тащить ничего из этого. Через 10 лет JSON может умрёт, а поддерживать его в стандартной библиотеке всё ещё придётся.

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

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

Прям вот полностью согласен

> Но за счет того, что интерфейсы зафиксированы 1, не факт что это возможно 2. если возможно то легко пишется враппер для всех этих 5 реализаций Json

https://forum.dlang.org/thread/kbcdzgrhzavurusicwcv@forum.dlang.org вот аналогичнейше обсуждение насчет баз данных

народ хочет стандартный интерфейс не понимая что это нереально сделать

Про 10 лет это такое себе

Про 10 лет это такое себе

ну умереть для софта не значит быть удалённым, Кобол тоже жив где-то, но понятно о чём я

Вот если пользоваться D будет не удобно то уже вопрос о том выживет ли сам язык

Я вообще не понимаю почему json появился, ведь уже был аналогичный xml

Я вообще не понимаю почему json появился, ведь уже был аналогичный xml

Оу

Нет

Это вещи разного уровня сложности

> Но за счет того, что интерфейсы зафиксированы 1, не факт что это возможно 2. если возможно то легко пишется враппер для всех этих 5 реализаций Json

Ну json это такие базовые вещи, о которых я хочу думать просто в последний момент. Интересно же высокими абстракциями заниматься, а когда нужен json - просто не думая одними методом катать - туда, сюда. Только когда приложение готово и оказалось что именно в jsonе и проблема - тогда может и потратить время на врапперы и сторонние решения. Но только в 90% случаев, если у тебя не расхайлоудистый хайлоуд - это и не понадобится.

то и другое текстовый способ передать данные

sdl по тому же сделали

Ну json это такие базовые вещи, о которых я хочу думать просто в последний момент. Интересно же высокими абстракциями заниматься, а когда нужен json - просто не думая одними методом катать - туда, сюда. Только когда приложение готово и оказалось что именно в jsonе и проблема - тогда может и потратить время на врапперы и сторонние решения. Но только в 90% случаев, если у тебя не расхайлоудистый хайлоуд - это и не понадобится.

Отлично - напиши враппер для всех известных тебе 5 реализаций библиотек Json

Вот прямо сейчас начни, через неделю закончишь. И проблема отвалится сама собой.

Вот прямо сейчас начни, через неделю закончишь. И проблема отвалится сама собой.

Вот поэтому на D никогда не будет большой коммерческой разработки.

Почему поэтому?

Вот прямо сейчас начни, через неделю закончишь. И проблема отвалится сама собой.

Вообще эту кашу Людвиг заварил. Если бы он просто сделал (де)сериализацию поверх std.json все были бы довольны, как мне кажется

Он такой дурак, взял и переписал уже существующее потому что не знал о нём?

А так ему приходится новый qt для D поддерживать

я пользвоался обеими json - Людвигов тупо лучше оказался, и синтаксически и по скорсоти и по глюкам.

Когда выбирал я ещё не знал про то что некоторые части фобоса заброшены

так что выбирал чисто по функциональности

Когда выбирал я ещё не знал про то что некоторые части фобоса заброшены

Проблема в заброшенности (частность), а не в том что json не должен быть в std

МЫ не гугл, мы не можем за зарплату посадить стд библиотеку писать

Забрашивается то что ненужно или сложно поддерживать

Думаю, Людвигу чем воевать с модерастией оказалось проще запилить свою реализацию (которая, кстати, не сразу и получилась)

и теперь мы имеем его (условно лучшую) реализацию и стандартную, которую выкинуть пора да не получается.

а когда-нибудь получится с таким же подходом?

МЫ не гугл, мы не можем за зарплату посадить стд библиотеку писать

А разница? Энтузиасты пишут и делают реальную работу. У языка все-таки есть создатели, у них должна быть ясная стратегия развития и они не должны стесняться командно-административно принимать решения, которые кому-то в коммьюнити могут и не нравиться. Это лучше, чем просто пилить новые фичи по принципу - куда дышло туда и вышло.

получится - она постепенно совсем сгниёт и её выпилят из-за того что никто совсем не будет против (в т.ч. её юзеры)

дык надо уже пометить как deprecated

и народ уже начнёт по тихой переделывать свои проекты

пока ещё консенсуса нет. Людвигов вариант нестабилен (меняются модификаторы иногда). он просто устраивает.

а где обсуждение идет?)

я вот чет на вики покопался - там всё древнее какое то

> А разница? Поясняю > Энтузиасты пишут и делают реальную работу. Да > У языка все-таки есть создатели, у них должна быть ясная стратегия развития и они не должны стесняться командно-административно принимать решения, которые кому-то в коммьюнити могут и не нравиться. Коммьюнити может и послать

еще бы какой-нибудь bson не помешал бы в std

накой BSON-то в стд?

Ну тогда такое комьюнити будет жить в забвении всю жизнь) и завидовать гошечке

Вообще у меня мнение, что проектов на D сейчас не так уж много. Ну всм если мы считаем, что текущие проекты настолько важны - то D мелкий язык. Если мы хотим сделать D большим и распространненым языком, то нужно и считать, что большинство кода на нем еще только будет написано, поэтому я за то, чтобы трясти стандартную библиотеку - только в путь. Вырвите свой джсон и вставьте людвигов, забейте на обратную совместимость - вот поштормить так какое-то время, а потом зафиксировать язык и больше почти не трогать. Идеально. А так то мы бережем обратную совместимость и текущие проекты, то выкатываем версию компилятора, которая все ломает, тут чего-то не хватает, сям, в итоге куда и как будет развиваться язык - лично мне вообще не ясно.

вы-то думали там асм голый, небось? или остаток от деления на 2 берётся? а вот хер

Нет, лично я так не думал. Нахуа там нужен асм или остаток от деления на 2?

Вообще у меня мнение, что проектов на D сейчас не так уж много. Ну всм если мы считаем, что текущие проекты настолько важны - то D мелкий язык. Если мы хотим сделать D большим и распространненым языком, то нужно и считать, что большинство кода на нем еще только будет написано, поэтому я за то, чтобы трясти стандартную библиотеку - только в путь. Вырвите свой джсон и вставьте людвигов, забейте на обратную совместимость - вот поштормить так какое-то время, а потом зафиксировать язык и больше почти не трогать. Идеально. А так то мы бережем обратную совместимость и текущие проекты, то выкатываем версию компилятора, которая все ломает, тут чего-то не хватает, сям, в итоге куда и как будет развиваться язык - лично мне вообще не ясно.

+ в принципе результаты d survey похожие

в этой функции все прекрасно, абсолютно, асм в ней не нужен. Как и ручные говноптимизации, вроде остатков от деления на 2 https://github.com/dlang/druntime/blob/master/src/core/bitop.d#L270

What is your tolerance for stability vs. breaking changes that fix "warts", inconsistencies, and/or historical baggage in the language. 489 out of 540 people answered this question 1 Go ahead and break code, even for the "little things", but do so through a gradual, managed process. 226 / 46% 2 Most D code has yet to be written. Go ahead and break code, but do it now and get it finished quickly. 155 / 32% 3 Only introduce breaking changes that fix major problems and can demonstrate a high benefit/cost ratio, and do so through a gradual, managed process. 94 / 19% 4 Please don't ever break code. 10 / 2% 5 Go ahead and break code, even for the 4 / 1%

5 пункт похоже ошибка

Нет, лично я так не думал. Нахуа там нужен асм или остаток от деления на 2?

На асм это считается как бы не за 1-2 такта

остаток от деления это тактов 4-8, что тоже скорее всего быстрее

и понятнее, без этой вот магии

Вообще у меня мнение, что проектов на D сейчас не так уж много. Ну всм если мы считаем, что текущие проекты настолько важны - то D мелкий язык. Если мы хотим сделать D большим и распространненым языком, то нужно и считать, что большинство кода на нем еще только будет написано, поэтому я за то, чтобы трясти стандартную библиотеку - только в путь. Вырвите свой джсон и вставьте людвигов, забейте на обратную совместимость - вот поштормить так какое-то время, а потом зафиксировать язык и больше почти не трогать. Идеально. А так то мы бережем обратную совместимость и текущие проекты, то выкатываем версию компилятора, которая все ломает, тут чего-то не хватает, сям, в итоге куда и как будет развиваться язык - лично мне вообще не ясно.

В языке самом тоже нахуевертили. Почему вот ubute + ubute == long?

нафига так? можно ведь было ushort сделать

Corporate Platinum $100,000 per year Support us with an annual donation and receive: 8 priority bug fixes per month (no accrual), your company's logo on the dlang.org sponsors page, 5 DConf registrations, 10 hours of phone support per month (no accrual), your company's logo in the README of 2 DLang projects (dmd, Phobos, DRuntime, etc.), 2 days of on-site training (travel and accommodation paid by sponsor), and your companies logo on either the dlang.org front page or the front page of the official D blog. фига условий напридумывали ))

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

не, всё круто. если контора ведёт основную разработку на ди - даже хорошее предложение

там в принципе за $60k предложение неплохое - а за бугром это годовая зп одного программиста.

На асм это считается как бы не за 1-2 такта

ты походу застрял в прошлом тысячелетии, когда i++ компилировалось в более быстрый код, чем i = i + 1

ERROR: S client not available

такое было только на pdp11

остаток от деления это тактов 4-8, что тоже скорее всего быстрее

отстаток от деления никак не может быть быстрее простых битовых операций, да и как он тебе поможет в этой функции?

может

ну конкретно в x86 есть проверка бита, почему не заюзали - хз

BT команда так и называется, да

в x86 разве не очень долгое деление? по тактам

щас быстрое

ну конкретно в x86 есть проверка бита, почему не заюзали - хз

Я говорю, ты застрял в прошлом тысячелетии. Накой непортируемый асм, если компилятор сам такие вещи оптимизирует лучше тебя? На вот полюбуйся :) https://godbolt.org/g/Qj5cx4

Там даже упомянутая тобой BT есть, :lol:

магия

зачем 3 и 4 строки?

зачем 3 и 4 строки?

видимо, чтобы достать нужный qword из битового массива

магия

какая магия?

там же проверка бита не в просто целом числе, а в массиве произвольной длины

поэтому не понятно как тут задействовать остаток от деления.

массив байтовый же а не битовый, значит интегеры делим

а xor зачем в 5 строке?

обнуление?

массив байтовый же а не битовый, значит интегеры делим

но сначала надо достать это интегер, а потом тестим его с помощью bt, по-моему быстрее не придумаешь.

угу. интересно как оно одно из другого создаёт?

угу. интересно как оно одно из другого создаёт?

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

может высокоуровневый код под него написали хитро со знанием способа его работы?

лично я давно отказался от триков вроде x / 2 —---> x << 1, компилятор сам прошарит.

может высокоуровневый код под него написали хитро со знанием способа его работы?

код чего?

лично я давно отказался от триков вроде x / 2 —---> x << 1, компилятор сам прошарит.

ну я про другой трик

код чего?

core

никто не будет точить код пот ldc, кроме того код этой функции на самом деле прост и понятен, я бы также написал.

как он в asm bt превращается?

типа как в шахматы - варианты перебирает компилятор?

А разве что-то мешает сгенерить этот код во время кодогпнерации?

типа как в шахматы - варианты перебирает компилятор?

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