Режисера Данелия? Который Кин-дза-дза снял?

да не, наш местный. В основном он режиссирует драмы

Меньше знают — больше твоя зарплата

ооочень условная корреляция

да не, наш местный. В основном он режиссирует драмы

*трагедии

ооочень условная корреляция

будь тщательней в написании слов, пожалуйста

будь тщательней в написании слов, пожалуйста

чо ты до меня до копался ?

во первых нет. Во вторых, отъебись же

я его повторно забанил. Со-админы, не надо его разбанивать

спасибо!

будь тщательней в написании слов, пожалуйста

Чисто спортивный интерес, что плохого было в этих словах?

Привет всем!?? Админы, можно вакансию разместить? Оформлено по правилам

Привет всем!?? Админы, можно вакансию разместить? Оформлено по правилам

привет. Давайте.

#вакансия #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 (ящик/скайп).

привет. Давайте.

Спасибо?

#вакансия #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 (ящик/скайп).

О, а мне даже нравится :)

string от []byte отличается только иммутабельностью?

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

я могу ошибаться, но вроде они алиасом сделаны

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

https://golang.org/pkg/reflect/#StringHeader

Так и есть

я могу ошибаться, но вроде они алиасом сделаны

алиасом чего?

алиасом типа

string от []byte отличается только иммутабельностью?

Итератор в строке идёт по рунам

угу, ведь в юникоде не только один байт на букву бывает

угу, ведь в юникоде не только один байт на букву бывает

nope, UTF8 просто "динамичен" https://goplay.space/#lzYWF5ok7Cj

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

Очевидно да. Иначе иммутабельность сломается

аа, ну да, иммут же, туплю

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

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

Лен на строку даёт количество рун

Меня больше волнует в какой момент он их считает

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

Лен на строку даёт количество рун

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

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

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

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

Хм.

Вообще это отстой

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

все равно O(n), тк придется пробежатьсч по массиву

все равно O(n), тк придется пробежатьсч по массиву

хм? зачем?

эмм, читать побайтово, раскладывать по рунам?

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

все равно O(n), тк придется пробежатьсч по массиву

зачем?

зачем?

есть стринг - он же []byte, как получить []rune?

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

там underlying []byte, но len([]rune) отдаёт что нужно

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

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

ты уверен что он тут не копируется?

ты уверен что он тут не копируется?

я уверен, что он тут копируется

я уверен, что он тут копируется

вот и я о том-же

вот и я о том-же

дык с immut []rune я согласен

там underlying []byte, но len([]rune) отдаёт что нужно

ты о чем? []rune(s) - преобразование, даже без копирования, будет O(n)

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

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

ты о чем? []rune(s) - преобразование, даже без копирования, будет O(n)

а, ты считаешь и подкапотную реализацию

я о ней :)

тогда понял)

короче нужон новый тип text ? щутка

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

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

короче нужон новый тип text ? щутка

ага. а ещё .map, .reduce, .filter и иже с ними %)

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

короче да, immut тут бы спас от копий ненужных immut []byte(s)

ага. а ещё .map, .reduce, .filter и иже с ними %)

прям с козырей зашел

не спас

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

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

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

да, опять туплю)) но в случае со слайсом байт спас бы

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

ага. а ещё .map, .reduce, .filter и иже с ними %)

%?

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

хм? немного не понял о чём ты

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

(MyType) MyMethod(..)

%?

%) — смайл такой был когда-то

таким образом это будет статик колл

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

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

хм? немного не понял о чём ты

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

%) — смайл такой был когда-то

smiling modulo operator

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

ради производительности люди часто используют []byte вместо string насколько мне известно (с какой-то блокчейн презентации помню)

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

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

ради производительности люди часто используют []byte вместо string насколько мне известно (с какой-то блокчейн презентации помню)

Оптимизация ради 20 наносекунд

Оптимизация ради 20 наносекунд

это 1 раз 20 наносекунд, 10 раз это уже 200 наносекунд, 100 = 2 микросекунды 1000 = 20 микросекунд 10.000 = 200 микросекунд 100.000 = 2 миллисекунды

и т.д.

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

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

да, но их будет видно на диаграммах pprof

Такие вещи стоит делать в последнюю очередь

и вот когда их будет видно - тогда и посмотрим

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

так я и не о большинстве забочусь)) язык зачастую определяют worst case'ы

пока там виден обычно штатный json

да, но их будет видно на диаграммах pprof

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

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

Если массив нигде не изменяется и не утекает наружу, то скорее всего копирования не будет

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

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

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

Если массив нигде не изменяется и не утекает наружу, то скорее всего копирования не будет

нене, там всего 3-5 кейсов, когда не будет, обычно - будет

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

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

Бодя посмотри на таракан бд и что она использует

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

http://bfy.tw/BhvK

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

если у вас в памяти 3 терабайта данных, это не значит что надо просканировать все 3 тарабайта сборщику. Сканировать приходится обычно в разы меньше, в очень большие разы, сборщик мусора анализирует не значения.

Бодя посмотри на таракан бд и что она использует

Что такое таракан бд?