@gogolang

Страница 767 из 1630
 
Nikita
22.01.2018
15:09:12
прям как я)
))))

 
Ivan
22.01.2018
15:09:15
правда я в стиме рублями покупаю

 
а на работе корпоративная лицуха

 
а то в эстонии в стиме цены в евро... только зарплаты меньше чем в москве той же

Google
 
Andrei
22.01.2018
15:30:39
Годный наброс на Rust Even things that should be dirt-simple in Rust, like string concatenation, are unreasonably difficult. The language demands a huge amount of fussy, obscure ritual before you can get anything done. The contrast with Go is extreme. By four days in of exploring Go I had mastered most of the language, had a working program and tests, and was adding features to taste. Then I found out that a feature absolutely critical for writing network servers is plain missing from Rust. Contemplate this bug report: Is there some API like "select/poll/epoll_wait"? and get a load of this answer: https://blog.ntpsec.org/2017/01/18/rust-vs-go.html
ну да, у раста довольно большой порог входа, но зато потом пишешь почти как на питоне с дж**риками и без какого либо сборщика мусора

 
Vitaliy
22.01.2018
15:35:52
Раст ещё сыроват для продакшна как мне кажется. Не оброс ещё кодом и сообществом

 
Artem
22.01.2018
15:40:54
Годный наброс на Rust Even things that should be dirt-simple in Rust, like string concatenation, are unreasonably difficult. The language demands a huge amount of fussy, obscure ritual before you can get anything done. The contrast with Go is extreme. By four days in of exploring Go I had mastered most of the language, had a working program and tests, and was adding features to taste. Then I found out that a feature absolutely critical for writing network servers is plain missing from Rust. Contemplate this bug report: Is there some API like "select/poll/epoll_wait"? and get a load of this answer: https://blog.ntpsec.org/2017/01/18/rust-vs-go.html
и че сложного в конкатенации строк то? [a, b].concat() ну или джоином можно.

 
Pawel
22.01.2018
15:47:36
и че сложного в конкатенации строк то? [a, b].concat() ну или джоином можно.
да щас. там много видов строк, и складывать их - это именно fussy, obscure ritual, связанный с борьбой с borrow checking-ом

 
Artem
22.01.2018
15:49:53
да щас. там много видов строк, и складывать их - это именно fussy, obscure ritual, связанный с борьбой с borrow checking-ом
ну если так рассуждать в golang много видов интов и запаришся их складывать

 
Pawel
22.01.2018
15:51:36
Да ну, не выдумывай. Сравнил инты с borrow checking-ом,ага Чесно гря он там не совсем корректный кейс взял - IRC сервер. У меня Rust хорошо звшёл в качестве замены C/C++ на всяком хардкорном лоу-левеле без рантайма и библиотек, для микроконтроллеров например. А там где веб, многопоточность, конкаренси, ось, вот это всё - там гошечка однозначно рулит

 
Artem
22.01.2018
15:57:14
ну гоша рулит это понятно, но я бы не стал сравнивая его с растом говорить, что там все сложно -это странно, опыт у людей разный и чего только стоит после питона попытка считать массив аргументов с командлайна в гоше.

 
Marlik
22.01.2018
15:57:30
и че сложного в конкатенации строк то? [a, b].concat() ну или джоином можно.
В доке вроде так строка + строка

 
Artem
22.01.2018
15:58:16
В доке вроде так строка + строка
не так не получится, там еще придется для принта "строка".to_string() сделать ))) Но вообще на расте я не писал ничего серьезного, не на столько я еще мазохист

 
Marlik
22.01.2018
15:58:57
Принтить то зачем если только конкатенация нужна?

 
Artem
22.01.2018
16:00:49
наверно не обязательно, но в любом случае придется, поскольку для конкатенации строк выполняется приведение и разыменование

 
в любом случае через format! и concat! чаще делают

 
anthof
22.01.2018
16:23:56
Ребят, подскажите. Такая проблема. Когда я просто создаю допустим пару переменных и заношу и в БД sqlite3, все хорошо работает. Но когда я пытаюсь получить данные из формы в переменные и потом записать их в поля БД, ничего не получается, в чем могут быть проблемы? возможно с форматами что-то не то?

Google
 
anthof
22.01.2018
16:25:18
или скорей всего я не правильно получаю данные из формы, пропускаю какой-то шаг, но при этом все компилируется. Где можно детально разобранный пример посмотреть или почитать? что бы были видны все шаги

 
Aleksandr
22.01.2018
16:34:50
дебажь каждый шаг

 
anthof
22.01.2018
16:36:10
дебажь каждый шаг
попробовать переменные с полученными данными из формы в консоль вывести?

 
что бы понять, есть ли они там

 
Aleksandr
22.01.2018
16:36:53
да

 
Alexander
22.01.2018
16:51:23
Кстати, в вышеупомянутом Goland есть неплохой дебаггер, которым можно прямо по шагам программу проходить и смотреть значения переменных.

 
@b6ed7
22.01.2018
16:53:01
Кстати, в вышеупомянутом Goland есть неплохой дебаггер, которым можно прямо по шагам программу проходить и смотреть значения переменных.
Насколько я помню, так же умеет и VS Code

 
Alexander
22.01.2018
16:54:08
Да, возможно. Но я им не пользовался, поэтому только про GoLand сказал.

 
Marlik
22.01.2018
16:55:49
Кстати, в вышеупомянутом Goland есть неплохой дебаггер, которым можно прямо по шагам программу проходить и смотреть значения переменных.
Чото голэнд вебсторм напоминает.

 
Aleksandr
22.01.2018
16:56:22
Чото голэнд вебсторм напоминает.
потому что как и остальные IDE JetBrains сделаны на одном движке

 
Marlik
22.01.2018
16:57:21
Не удивлюсь, если и сервер активаций у них один на всех))

 
Aleksandr
22.01.2018
16:59:21
один

 
Alexander
22.01.2018
16:59:23
Хаха, да, они все почти одинаковые. WebStorm, PhpStorm, IntelliJ

 
Pawel
22.01.2018
17:31:39
Надо как можно сильнее запаковать трафик. Будет ли gob для этого адекватным решением, или надо мутить какой нибудь protobuff ?

 
Aleksandr
22.01.2018
17:32:25
В rar паковать

 
Винраром

 
Pawel
22.01.2018
17:33:25
это троллинг был?

 
или винрар умеет в структуры данных Го?

 
Пачка жсон с "Content-Encoding": "gzip" весит примерно 5 мб. Это много, учитывая что такие пачки идут нон стопом в клиент. Если сериализовать по отдельность каждое значение поля структуры в поток байтов, то получается примерно 300 кб. Но это говнокод.

 
Alexander
22.01.2018
17:41:51
По-моему, в данном случае загонять всё в json это и есть говнокод. Хотя бы потому что его создавать и потом декодировать - это совершенно ненужная работа

Google
 
Alexander
22.01.2018
17:44:04
В сторону BSON может посмотреть? https://github.com/pkg/bson

 
Pawel
22.01.2018
17:46:47
и чем это отличается принципиально от жсон + "Content-Encoding": "gzip"?

 
Alexander
22.01.2018
17:47:27
эффективностью и отсутствием ненужного превращения данных в строку и обратно

 
Если у данных энтропия низкая, то можно еще и BSON пожать gzip-ом. Ну это уже зависит от данных

 
Pawel
22.01.2018
17:50:18
да пофигу на эффективность. меня только размер волнует. А с чего ему быть на много меньше в bson чем зазипованного json, если наименования пропертей передаются в обоих случаях?

 
Bohdan
22.01.2018
17:50:57
Приветствую У меня слайс с одной и той же структуры. У этой структуры есть поле ID. Как мне преобразовать этот слайс структур в слайс интов от поля ID?)

 
Может какой то красивый способ есть, а не что бы писать все это руками)

 
Alexander
22.01.2018
17:52:15
да пофигу на эффективность. меня только размер волнует. А с чего ему быть на много меньше в bson чем зазипованного json, если наименования пропертей передаются в обоих случаях?
Потому что Если сериализовать по отдельность каждое значение поля структуры в поток байтов, то получается примерно 300 кб. Или json сильно больше только из-за большого количества свойств, чьи имена передаются? Что-то слабо верится, что там данных на 300кб, а названий свойств на десятки мегабайт (если 5мб - это _сжатый_ json)

 
Bohdan
22.01.2018
17:52:15
или говэй и здесь применять?)))

 
Pawel
22.01.2018
17:53:17
Потому что Если сериализовать по отдельность каждое значение поля структуры в поток байтов, то получается примерно 300 кб. Или json сильно больше только из-за большого количества свойств, чьи имена передаются? Что-то слабо верится, что там данных на 300кб, а названий свойств на десятки мегабайт (если 5мб - это _сжатый_ json)
https://betfairs.herokuapp.com/football/games4

 
это такой жсон

 
Alexander
22.01.2018
17:55:12
790 кб распакованный, 33кб в gzip

 
Pawel
22.01.2018
17:55:53
это сегодня футбола нет практически . А вчера был такой как я сказал

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

 
Alexander
22.01.2018
17:57:26
Т.е. там реально был json в 120 мегабайт размером? И сервер не подавился?

 
5мб * (790/33) = 120мб

 
Pawel
22.01.2018
17:59:06
хз скока там на сервере, я не проверял. Ну пока что мене до балды как там сервер это тянет, сейчас нужно именно с форматом сериализации определиться

 
Я так понимаю что gob как и жсон включает все имена пропертей и особо смысла его использовать нет

 
вот думаю стоит ли манаться с протобуфом или asn1

 
5мб * (790/33) = 120мб
не факт что этот множитель - констатнта

Google
 
Alexander
22.01.2018
18:02:09
не факт, конечно, но порядок примерно такой будет. Сжатие в 24 раза - вполне ожидаемо для столь регулярного текста.

 
протобуф названия свойств не передает?

 
Вообще, конечно, вот, на выбор - https://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats

 
Max
22.01.2018
18:08:32
Сейчас в основном юзают protobuf, flatbuffers и messagepack протоколы сериализации

 
Pawel
22.01.2018
18:11:08
Сейчас в основном юзают protobuf, flatbuffers и messagepack протоколы сериализации
ну это в основном фреймворки же типа grpc и ZeroMQ. хотя может оно и всем так надо, я вот пока не понял этого

 
не факт, конечно, но порядок примерно такой будет. Сжатие в 24 раза - вполне ожидаемо для столь регулярного текста.
Небольшая поправка, 5 МБ - это не сжатый объём, я вот щас это понял. Но это всё равно много

 
Max
22.01.2018
18:13:19
Это протоколы) А вот grpc это уже фреймворк использующий под капотом RPC + protobufs

 
Pawel
22.01.2018
18:22:10
Это протоколы) А вот grpc это уже фреймворк использующий под капотом RPC + protobufs
а почему например не использовать asn.1? чем он хуже чем protobuff ?

Admin
ERROR: S client not available

 
Slava
22.01.2018
18:26:31
Протобуф моднее

 
Антон
22.01.2018
18:26:42
а почему например не использовать asn.1? чем он хуже чем protobuff ?
интересный, кстати, вопрос

 
Vladislav
22.01.2018
18:27:38
Экосистема вокруг протобуфа побольше.

 
Pawel
22.01.2018
18:27:51
Протобуф моднее
зато asn.1 есть в ГОСТе !!!

 
)))

 
Vladislav
22.01.2018
18:29:17
зато asn.1 есть в ГОСТе !!!
А это точно +?

 
Pawel
22.01.2018
18:30:19
А это точно +?
http://docs.cntd.ru/document/1200031914

 
Антон
22.01.2018
18:31:55
а почему например не использовать asn.1? чем он хуже чем protobuff ?
ну с asn.1 сравнивать точно бессмысленно, т.к. это лишь спецификация, а вот der, per и тп, интересно

 
Pawel
22.01.2018
18:34:52
ну с asn.1 сравнивать точно бессмысленно, т.к. это лишь спецификация, а вот der, per и тп, интересно
не понял, в каком смысле он только лишь, а протобуф не только лишь. asn1 описывает формат представления данных, он есть в стандартной гошной либе. что не так и чем протобуф лучше?

 
Антон
22.01.2018
18:35:30
не, asn.1, на сколько я знаю, не описывает как конкретно будут сериализованы данные

 
Alexander
22.01.2018
18:35:35
Небольшая поправка, 5 МБ - это не сжатый объём, я вот щас это понял. Но это всё равно много
Тогда в гзипе он будет 200-250 кб. Не так уж и много. Меньше сырых двоичных данных

Google
 
Антон
22.01.2018
18:36:23
аля у asn.1 может быть множество сериализаторов/десериализаторов типа der

 
Alexander
22.01.2018
18:36:43
Хотя двоичные данные тоже можно сжать, конечно

 
Антон
22.01.2018
18:38:16
а protobuf включает в своё описание и способ сериализации/десериализации

 
Max
22.01.2018
18:38:40
Хотя двоичные данные тоже можно сжать, конечно
Это если есть избыточность. Попроуй сжать например png

 
Alexander
22.01.2018
18:39:16
Тут вполне определенные данные. Без картинок

 
Max
22.01.2018
18:40:29
Это был как пример. В json есть избыточноть, а еще повторяемость от сообщения к сообщению ключей

 
Alexander
22.01.2018
18:41:45
Кстати, да, интересная мысль - сжимать данные с учетом предыдущего пакета. Этакий мпег для json

 
Max
22.01.2018
18:42:18
Это и делает protobuffer, flatbuffer и ему подобные

 
Alexander
22.01.2018
18:43:15
О_о, правда что ли?

 
Pawel
22.01.2018
18:45:07
Спасибо за помощь, парни. Буду юзать protobuff

 
Max
22.01.2018
18:45:15
Ну да, а еще ZigZag кодирование и другие трюки

 
Если есть возможность лучше flatbuffer. Он быстрее

 
Alexander
22.01.2018
18:49:13
Спасибо за помощь, парни. Буду юзать protobuff
Сделай для начала тест на размер данных и скорость декодирования и сравни с json. А то обидно будет потратить время на переделку, а результат получить не лучше, чем просто json.

 
Антон
22.01.2018
18:50:33
Кстати, да, интересная мысль - сжимать данные с учетом предыдущего пакета. Этакий мпег для json
А если бакенд упал? Прошлого сообщения не помнит. Или балансировщик отправил следующее сообщение другому экземпляру бакенда? Как он его десериализует?

 
нету такого в протобуфе

 
Alexander
22.01.2018
18:51:44
Понятно, что это сопряжено с кучей проблем. Это я так, просто мыслью поделился

 
Max
22.01.2018
18:54:59
А если бакенд упал? Прошлого сообщения не помнит. Или балансировщик отправил следующее сообщение другому экземпляру бакенда? Как он его десериализует?
Клиент тоже хранит у себя протокол десериализации, так же как и сервер, все нормально будет

 
Антон
22.01.2018
18:56:34
Клиент тоже хранит у себя протокол десериализации, так же как и сервер, все нормально будет
а если не помнит? не на диске же он его хранит

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

 
Max
22.01.2018
18:57:23
Он его может хранить где угодно, например в localStorage

Страница 767 из 1630