поэтому и терминология должна быть одинаковая

его уже выкидывать пора

прошлый, сейчас новый наступает json

уже протобаф

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

не поверишь, так фильтруют людей с проблемами психики

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

не начинай плес

прошлый, сейчас новый наступает json

json вообще то такой же древний и никак не замена xml

прошлый, сейчас новый наступает json

toml же

this

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

я спрашиваю потому, что мне интересно, насколько человек вообще понимает, что такое ООП и зачем оно нужно

в C нет инкапсуляции и в этом вся беда

Как нет? А указатели на функции?

я спрашиваю потому, что мне интересно, насколько человек вообще понимает, что такое ООП и зачем оно нужно

зачем это спрашивать, и так очевидно

это как не использовать?) в общем то для обмена данными почти стандарт)

для обмена каких данных? JSON стандарт веба, не XML

я спрашиваю потому, что мне интересно, насколько человек вообще понимает, что такое ООП и зачем оно нужно

ООП это круто! Берете? ?

ты по ходу меряешь его на совпадение с твоим мнением про ООП

уже протобаф

а в браузер уже подвезли поддержку?

в общем и для xml и для json и для gob в Го библиотеки есть

у меня опросник, я по нему вопросы задаю

тзис

у меня опросник, я по нему вопросы задаю

поделитесь?

а в браузер уже подвезли поддержку?

под js биндинги есть или вы про что?

вроде еще есть bson и прочие бинарные решения

под js биндинги есть или вы про что?

прям в браузер?

ты по ходу меряешь его на совпадение с твоим мнением про ООП

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

но за применение XML там, где достаточно JSON надо отрезать кончик пальца наверное нынче (:

прям в браузер?

угу

поделитесь?

так это, делился в джоб-чате

под js биндинги есть или вы про что?

браузеры поумолчанию умеют JSON, protobuf они поумолчанию не понимают. Называть protobuf стандартом довольно забавно получается))

для обмена каких данных? JSON стандарт веба, не XML

хмм, ну поискать какое нибудь корпоративное приложение выгружающее данные в json это конечно интересно, но вероятно будет xml веб это ещё не вся жизнь так сказать)

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

чем ты ее меряешь?

чем ты ее меряешь?

разосрешься или нет с интервьюером ((:

но за применение XML там, где достаточно JSON надо отрезать кончик пальца наверное нынче (:

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

собесы ваще субъективная шляпа Наверняка и не работает в плане: сработаетесь или нет даже

хмм, ну поискать какое нибудь корпоративное приложение выгружающее данные в json это конечно интересно, но вероятно будет xml веб это ещё не вся жизнь так сказать)

корпоративное должно же в csv выгружать, иначе зачем туда-сюда по форматам гонять?

не работает

собесы ваще субъективная шляпа Наверняка и не работает в плане: сработаетесь или нет даже

это правильно, человека ищут под определенную команду это немного субъективно

хмм, ну поискать какое нибудь корпоративное приложение выгружающее данные в json это конечно интересно, но вероятно будет xml веб это ещё не вся жизнь так сказать)

потому-что legacy. А так XML в плане именно передачи данных - вымирающий формат. Он human readable, extensible но для передачи данных он просто абсолютно не годится, слишком сложный, громоздкий и медленный (parsing/encoding)

корпоративное должно же в csv выгружать, иначе зачем туда-сюда по форматам гонять?

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

потому-что legacy. А так XML в плане именно передачи данных - вымирающий формат. Он human readable, extensible но для передачи данных он просто абсолютно не годится, слишком сложный, громоздкий и медленный (parsing/encoding)

ну тогда всё через gob он и удобный и только машинно читаемый

Комментарии в данных? Зачем?

Это или данные, тогда сериализует явно, или информация о структуре (юзайте схему) или мусор

XML это скорее human-computer interface, нежели формат "передачи данных"

XML это скорее human-computer interface, нежели формат "передачи данных"

обмена и не передачи, ключевой момент

все звенья цепи могут работать с данными в том числе человек

ну тогда всё через gob он и удобный и только машинно читаемый

в этом то и проблема, non-human readable. JSON это компромис между human & machine readable, поэтому собственно и превратился в стандарт

корпоративное должно же в csv выгружать, иначе зачем туда-сюда по форматам гонять?

Сразу в эксель

Сразу в эксель

так я ж об этом

да и даже с точки зрения человека, думаю легче написать простой JSON нежели городить сложный XML

Вот бы хоть один из этих форматов можно было читать не целиком, а стримами, по сети или из больших файлов.

в отдельных, очень редких случаях может XML и удобный, но в большинстве случаев он нереальный overkill

Вот бы хоть один из этих форматов можно было читать не целиком, а стримами, по сети или из больших файлов.

это называется machine redable))

в отдельных, очень редких случаях может XML и удобный, но в большинстве случаев он нереальный overkill

вопрос в задачах опять же потом машинное время очень дёшево, а вот люди иногда дороже

поэтому получается что xml может быть более эффективным в целом

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

хотел скачать liteide, а последний релиз 8 минут назад и видимо надо ждать автосборки бинарников

поэтому получается что xml может быть более эффективным в целом

эффективным в целом?)) для редачи данных?))

Вот бы хоть один из этих форматов можно было читать не целиком, а стримами, по сети или из больших файлов.

Ну json обычно кладут просто в виде маленьких кусочков сплошным стоимом. А для xml обычно во всех языках есть потоковые парсеры

для конфигов / моделирования чего-либо может быть, но это скорее human-computer interface а вот для передачи machine-to-machine он ужасен

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

Prometheus, графана

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

https://github.com/gonum/plot

для конфигов / моделирования чего-либо может быть, но это скорее human-computer interface а вот для передачи machine-to-machine он ужасен

опять же чем, ну чуть больше данных и что?

для конфигов / моделирования чего-либо может быть, но это скорее human-computer interface а вот для передачи machine-to-machine он ужасен

можно кейс, когда жсон не тянет?

для себя интересуюсь, не для срача

его трудно писать руками

а хмл просто? оО

его трудно писать руками

ну я бы не сказал что XML писать легче

немного легче

ini писать просто

немного легче

ну это субьективно

реальный кейс

можно кейс, когда жсон не тянет?

ну где проще запутаться если нужно какое-то сложное "дерево данных в json или в xml?

можно кейс, когда жсон не тянет?

конфиги например, их лучше писать на каком нибудь TOML

мне json легче

даже порой в curl -d '{...}' пишу пост запросы

ну где проще запутаться если нужно какое-то сложное "дерево данных в json или в xml?

ну это бред, жсон чудно структуризуется

у хмл вроде есть еще способы разночтения при парсинге

типа где делать массив, а где хеш

но точно не помню

это скорее на уровне парсера разруливается

чем в формате

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

ini писать просто

Иерархию особенно в нем удобно делать

иначе на кой писюн

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

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

так тут дело не в формате транспортнре, а в спеке между сервисами и людьми

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

Это явно проблемы либы. Должно было во флоат превращаться по всем стандартам js

Жсон и хмл гавно, но если надо что то передать во фронт, то только жсон. Иначе - пишем dsl, потому что yaml - сложное гавно

Это явно проблемы либы. Должно было во флоат превращаться по всем стандартам js

хм, так жс дальше 32 бита все во флоат вгонит?

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

Жсон

Ну или иное решение типа bson какой

Сам то я использую его да по дефолту.

хм, так жс дальше 32 бита все во флоат вгонит?

> This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision

хм, так жс дальше 32 бита все во флоат вгонит?

В общем, в js похоже 64 бит в числах

В общем, в js похоже 64 бит в числах

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

В общем, так себе в json с числами

потому-что legacy. А так XML в плане именно передачи данных - вымирающий формат. Он human readable, extensible но для передачи данных он просто абсолютно не годится, слишком сложный, громоздкий и медленный (parsing/encoding)

што

хм, так жс дальше 32 бита все во флоат вгонит?

в JS насколько мне известно нет интов, только float64 (a.k.a. "number")

firefox делает приблизительные вычисления

(1e+256) == (1e+256+1) true