@gogolang

Страница 1544 из 1630
Alexander
12.10.2018
12:11:12
Режисера Данелия? Который Кин-дза-дза снял?

Александр
12.10.2018
12:12:08
да не, наш местный. В основном он режиссирует драмы

Artem
12.10.2018
12:12:08
Меньше знают — больше твоя зарплата
ооочень условная корреляция

Google
Alexander
12.10.2018
12:13:44
ооочень условная корреляция
будь тщательней в написании слов, пожалуйста

Artem
12.10.2018
12:15:48
во первых нет. Во вторых, отъебись же

Aleksandr
12.10.2018
12:17:30
я его повторно забанил. Со-админы, не надо его разбанивать

Илья
12.10.2018
12:18:35
спасибо!

anatolii
12.10.2018
12:35:35
будь тщательней в написании слов, пожалуйста
Чисто спортивный интерес, что плохого было в этих словах?

Виктория
12.10.2018
12:55:06
Привет всем!?? Админы, можно вакансию разместить? Оформлено по правилам

Виктория
12.10.2018
12:57:07
#вакансия #softwareengineer #engineer #golang ⚡️В компании GrinTeq открыта позиция Software Engineer (C / Golang). Формат: Удалённый вариант или минский офис (ст.м. Я. Коласа). Полная занятость, гибкий график. ЗП вилка: 4 000 - 5 000$ на руки. Требования: - Уверенные знания C и/или Golang; - Опыт работы с system level programming; - Хороший устный и письменный английский; - Опыт работы 4+ лет. Задачи: - работа в тесном сотрудничестве с отделом разработки, QA и Product team для создания основных функций в следующих областях: container security, container image formats, container orchestration & deployment, plugins; - разработка и поддержка инструментов для on-premise deployment. Компания: http://grinteq.com Контакты: @toria_makas; v.makas@grinteq.com (ящик/скайп).

Roman
12.10.2018
14:18:44
string от []byte отличается только иммутабельностью?

единственная разница про которую я знаю это то что у структуры строки нет поля cap

Google
Александр
12.10.2018
14:22:12
я могу ошибаться, но вроде они алиасом сделаны

Александр
12.10.2018
14:31:04
алиасом типа

Subbotin
12.10.2018
14:31:14
Foxcool
12.10.2018
14:33:31
угу, ведь в юникоде не только один байт на букву бывает

Roman
12.10.2018
14:34:39
угу, ведь в юникоде не только один байт на букву бывает
nope, UTF8 просто "динамичен" https://goplay.space/#lzYWF5ok7Cj

интересно конечно копируется ли тут сама строка (лень писать бенч) []rune(s)

Subbotin
12.10.2018
14:36:13
Очевидно да. Иначе иммутабельность сломается

Roman
12.10.2018
14:36:22
аа, ну да, иммут же, туплю

копировать всю строку только ради получения колва рун... охх..

Subbotin
12.10.2018
14:37:17
Меня больше волнует в какой момент он их считает

Roman
12.10.2018
14:38:04
s = "static string" r := immut []rune(s) по сути, если можно гарантировать иммутабельность слайса рун, тогда можно и не копировать

Лен на строку даёт количество рун
len даёт размер массива, не колво рун: https://goplay.space/#XxHpUWx3Qlk

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

many-faced
12.10.2018
14:41:19
знатоки gin-gonic, подскажите, возможно ли настроить кастомный анмаршалинг при бинде ShouldBindWithJSON ? Типа, поле в json приходит {"field": "1,2,3"} а структура такая: struct { a,b,c uint64 }

Google
Илья
12.10.2018
14:49:46
эмм, читать побайтово, раскладывать по рунам?

или как ты себе это представляешь? там underlying []byte

Илья
12.10.2018
14:51:03
зачем?
есть стринг - он же []byte, как получить []rune?

Roman
12.10.2018
14:51:07
да вот странно.. почему строку сразу иммутабельным []rune не сделали

Kirill
12.10.2018
14:51:08
там underlying []byte, но len([]rune) отдаёт что нужно

пруф: https://play.golang.org/p/1T91VxqPwP3

Roman
12.10.2018
14:52:06
пруф: https://play.golang.org/p/1T91VxqPwP3
ты уверен что он тут не копируется?

Kirill
12.10.2018
14:52:19
ты уверен что он тут не копируется?
я уверен, что он тут копируется

Roman
12.10.2018
14:52:28
Kirill
12.10.2018
14:52:51
вот и я о том-же
дык с immut []rune я согласен

Илья
12.10.2018
14:52:54
там underlying []byte, но len([]rune) отдаёт что нужно
ты о чем? []rune(s) - преобразование, даже без копирования, будет O(n)

Aleksandr
12.10.2018
14:52:58
да вот странно.. почему строку сразу иммутабельным []rune не сделали
потому что из байтов получить руны накладная операция, которая не нужна по умолчанию

Kirill
12.10.2018
14:53:30
Илья
12.10.2018
14:53:38
я о ней :)

Kirill
12.10.2018
14:54:10
тогда понял)

Roman
12.10.2018
14:54:54
короче нужон новый тип text ? щутка

Илья
12.10.2018
14:56:11
да вот странно.. почему строку сразу иммутабельным []rune не сделали
сделали так, как быстрее и удобнее, string <-> []byte слишком часто преобразовываются (особенно в бенчмарках :) ), изза этого даже оптимизации лепят, поэтому под string именно []byte

Google
Kirill
12.10.2018
14:56:14
короче нужон новый тип text ? щутка
ага. а ещё .map, .reduce, .filter и иже с ними %)

Artem
12.10.2018
14:59:31
Илья
12.10.2018
14:59:33
не спас

[]rune <-> []byte - очень дорого

Artur
12.10.2018
15:00:02
Есть функция привязанная к структуре. В ней дергается другая функция которая оперирует не данными самой структуру а лишь аргументами в нее помещенными(при этом используется лишь в моем типе). Где ее правильно объявить? привязать к структуре или просто как отдельную функцию? Если бы был класс то я бы сделал статик метод, но как корректно это должно выглядить в го?

Roman
12.10.2018
15:00:18
[]rune <-> []byte - очень дорого
да, опять туплю)) но в случае со слайсом байт спас бы

Илья
12.10.2018
15:00:44
string <-> immut []byte - по сути вспе хаки - плюют на иммутабельность ради производительности

Kirill
12.10.2018
15:01:40
%?
%) — смайл такой был когда-то

Илья
12.10.2018
15:01:44
таким образом это будет статик колл

Илья
12.10.2018
15:03:03
хм? немного не понял о чём ты
сейчас ради производительности преобразование строки к слайсу байт в ряде случаев (небольшое безопасное подмножество), компилятор просто выдирает underlying slice

Roman
12.10.2018
15:03:12
сейчас ради производительности преобразование строки к слайсу байт в ряде случаев (небольшое безопасное подмножество), компилятор просто выдирает underlying slice
ради производительности люди часто используют []byte вместо string насколько мне известно (с какой-то блокчейн презентации помню)

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

Roman
12.10.2018
15:07:15
Оптимизация ради 20 наносекунд
это 1 раз 20 наносекунд, 10 раз это уже 200 наносекунд, 100 = 2 микросекунды 1000 = 20 микросекунд 10.000 = 200 микросекунд 100.000 = 2 миллисекунды

Google
Roman
12.10.2018
15:07:17
и т.д.

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

Никита
12.10.2018
15:08:05
Такого рода оптимизации большинству не нужны, как я считаю

Daniel
12.10.2018
15:08:06
да, но их будет видно на диаграммах pprof

Никита
12.10.2018
15:08:15
Такие вещи стоит делать в последнюю очередь

Daniel
12.10.2018
15:08:20
и вот когда их будет видно - тогда и посмотрим

Roman
12.10.2018
15:08:41
Такого рода оптимизации большинству не нужны, как я считаю
так я и не о большинстве забочусь)) язык зачастую определяют worst case'ы

Daniel
12.10.2018
15:08:45
пока там виден обычно штатный json

Roman
12.10.2018
15:09:40
да, но их будет видно на диаграммах pprof
ну с такой аргументацией можно прекратить какие-либо оптимизации по 5% в runtime'е и компиляторе)) я абсолютно согласен с тем, что оптимизировать нужно первые 10 результатов pprof, но если некоторые небольшие тормоза платформы можно избежать негеморным способом то зачем намерено их оставлять?)

Мерлин
12.10.2018
15:13:16
копировать всю строку только ради получения колва рун... охх..
Если массив нигде не изменяется и не утекает наружу, то скорее всего копирования не будет

Foxcool
12.10.2018
15:13:30
потом что оптимизация не должна быть преждевременной и не должна создавать проблемы для разработки и поддержки

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

если и без нее ок работает и нет претензий

Илья
12.10.2018
15:21:35
Max
12.10.2018
16:30:01
Народ подскажите пожалуйста а на go можно написать in-memory базу данных? У меня почему есть уверенность что все языки со сборщиком мусора не подходят для этого и go как язык с gc соотвественно тоже но хотелось бы уточнить. Для in-memory базы даннных важны минимальные задержки при сборке мусора а точнее даже чтобы эти задержки не зависели от количества объектов в памяти. Сейчас серверы могут иметь до 3 терабайт оперативной памяти (и еще больше терабайт если используется свап на быстрых nvme ssd дисках) и поскольку принцип работы сборщика мусора заключается в том чтобы просканировать все достижимые объекты с корня и очистить все остальные то только для сканирования 3 терабайт объектов потребуется несколько десятков секунд. Поэтому сразу возникает вопрос - умеет ли сборщик мусора в go работать инкрементально а не по принципу "stop the world" и насколько большие расходы в целом на gc в зависимости от количества объектов?

Michael
12.10.2018
16:31:47
Народ подскажите пожалуйста а на go можно написать in-memory базу данных? У меня почему есть уверенность что все языки со сборщиком мусора не подходят для этого и go как язык с gc соотвественно тоже но хотелось бы уточнить. Для in-memory базы даннных важны минимальные задержки при сборке мусора а точнее даже чтобы эти задержки не зависели от количества объектов в памяти. Сейчас серверы могут иметь до 3 терабайт оперативной памяти (и еще больше терабайт если используется свап на быстрых nvme ssd дисках) и поскольку принцип работы сборщика мусора заключается в том чтобы просканировать все достижимые объекты с корня и очистить все остальные то только для сканирования 3 терабайт объектов потребуется несколько десятков секунд. Поэтому сразу возникает вопрос - умеет ли сборщик мусора в go работать инкрементально а не по принципу "stop the world" и насколько большие расходы в целом на gc в зависимости от количества объектов?
Бодя посмотри на таракан бд и что она использует

Andrei
12.10.2018
16:32:05
Народ подскажите пожалуйста а на go можно написать in-memory базу данных? У меня почему есть уверенность что все языки со сборщиком мусора не подходят для этого и go как язык с gc соотвественно тоже но хотелось бы уточнить. Для in-memory базы даннных важны минимальные задержки при сборке мусора а точнее даже чтобы эти задержки не зависели от количества объектов в памяти. Сейчас серверы могут иметь до 3 терабайт оперативной памяти (и еще больше терабайт если используется свап на быстрых nvme ssd дисках) и поскольку принцип работы сборщика мусора заключается в том чтобы просканировать все достижимые объекты с корня и очистить все остальные то только для сканирования 3 терабайт объектов потребуется несколько десятков секунд. Поэтому сразу возникает вопрос - умеет ли сборщик мусора в go работать инкрементально а не по принципу "stop the world" и насколько большие расходы в целом на gc в зависимости от количества объектов?
http://bfy.tw/BhvK

anatolii
12.10.2018
16:36:57
Народ подскажите пожалуйста а на go можно написать in-memory базу данных? У меня почему есть уверенность что все языки со сборщиком мусора не подходят для этого и go как язык с gc соотвественно тоже но хотелось бы уточнить. Для in-memory базы даннных важны минимальные задержки при сборке мусора а точнее даже чтобы эти задержки не зависели от количества объектов в памяти. Сейчас серверы могут иметь до 3 терабайт оперативной памяти (и еще больше терабайт если используется свап на быстрых nvme ssd дисках) и поскольку принцип работы сборщика мусора заключается в том чтобы просканировать все достижимые объекты с корня и очистить все остальные то только для сканирования 3 терабайт объектов потребуется несколько десятков секунд. Поэтому сразу возникает вопрос - умеет ли сборщик мусора в go работать инкрементально а не по принципу "stop the world" и насколько большие расходы в целом на gc в зависимости от количества объектов?
если у вас в памяти 3 терабайта данных, это не значит что надо просканировать все 3 тарабайта сборщику. Сканировать приходится обычно в разы меньше, в очень большие разы, сборщик мусора анализирует не значения.

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