после него есть ещё несколько гайдов вроде

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

Тебе основы надо поизучать. Какая ещё организация. Спрашиваешь вопросы про пакеты и уровень доступа функций из пакетов

ну ланнсс

тут полезные ссылки https://tour.golang.org/concurrency/11

как сделать из красной png в зеленый ??RGB?

как сделать из красной png в зеленый ??RGB?

что значит "красная png"? картинка состоит и пикселей, в которых сразу 3 цвета хранятся (для RGB)

ты можешь сделать маппиг из R в G

заморочился по передачи поинтерами vs значениями переменных http://goinbigdata.com/golang-pass-by-pointer-vs-pass-by-value/ понятно, что с точки зрения логики если не нужно копирование и хочется чтобы функции/методы изменяли оригинал - поинтеры, нет - значения еще думал что с точки зрения логики копирование значения переменной более ресурсоемко, нежели создание на нее нового поинтера. и тут в статье написали что порой копирование новой переменной будет быстрее о_О. Кто копался в этой области, подскажите есть смысл заморачиваться с поинтерами если мы используем ну например конструкцию типа struct { A int B string }? А если просто var A int? Можно конечно это все решить на этапе оптимизации, но хочется сразу толковый код писать (очевидно), чтобы меньше потом геммороится

я бы сказал, 1) нет, 2) нет

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

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

Vasily Romanov: https://www.coursera.org/learn/golang-webservices-1 https://www.coursera.org/learn/golang-webservices-2

еще когда я это написал, я подумал, что будет так. канал медленный по сравнению с мутексом и атомиком. потому, что в нем 3 мутекса, кажется. но! вы об этом никогда не узнаете!!!

канал медленнее мютекса гдето на треть бенчмаркали немного

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

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

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

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

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

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

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

ну, ничего более конкретного я посоветовать не могу

http://goinbigdata.com/golang-pass-by-pointer-vs-pass-by-value/

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

нельзя просто так взять и кодить на Go

нельзя просто так взять и кодить на Go

В смысле нельзя? Он же как раз для этого и создавался

Есть мнение, что пока не поймёшь как работает его ассемблер, нельзя писать

В смысле нельзя? Он же как раз для этого и создавался

да, но для кого?

Есть мнение, что пока не поймёшь как работает его ассемблер, нельзя писать

Ассемблер со сборщиком мусора? ?

Есть мнение, что пока не поймёшь как работает его ассемблер, нельзя писать

Што

Ассемблер со сборщиком мусора? ?

сборщик мусора — это первое, что тебя спросят на собеседовании на позицию сеньёра (мидлы\джуны не нужны)

Лол

найс аватарка

Лол

заморочился по передачи поинтерами vs значениями переменных http://goinbigdata.com/golang-pass-by-pointer-vs-pass-by-value/ понятно, что с точки зрения логики если не нужно копирование и хочется чтобы функции/методы изменяли оригинал - поинтеры, нет - значения еще думал что с точки зрения логики копирование значения переменной более ресурсоемко, нежели создание на нее нового поинтера. и тут в статье написали что порой копирование новой переменной будет быстрее о_О. Кто копался в этой области, подскажите есть смысл заморачиваться с поинтерами если мы используем ну например конструкцию типа struct { A int B string }? А если просто var A int? Можно конечно это все решить на этапе оптимизации, но хочется сразу толковый код писать (очевидно), чтобы меньше потом геммороится

Копирование указателя в го происходит быстрее, чем копирование структуры, т.к. указатель в го - это _структура_ которая копируется (вот так вот, да) и в которой хранится тип и адрес уже непосредственно данных в памяти. А вот обращение к данным по ссылке конечно медленее - цена за разыменовывание. В го ГЦ работает не так, как в дотнете или жаве. В дотнете, объекты ГЦ маркируются тремя генерациями, всякие локальные переменные и мелкая требуха попадает в первую генерацию и чиститься первее всех. В го же оптимизация происходит на этапе компиляция, которая называется Escape Analysis, суть в которой, что многие объекты выделяются не на куче, а на стеке и сразу уничтожаются, что обнаруживается семантическим анализом их использования компилятором. Передавать по ссылке версус Передавать по значению Преждевременная оптимизация зло, потому ориентироваться на недокументированные оптимизации компилятора и гадание выделится ли структура на стеке или в куче не имеет смысла. Я выработал концептуально такую систему: 1. Передавать структуру по значению, если мы предполагаем ее использование как иммутабельную (но тут не забывайте, что мапы и слайсы все равно будут мутабельны) 2. Передача ссылки предполагая, что объект будет изменяться функцией, в которую мы ее передаем 3. Понимать указатель как nilable (nullable) значение, чтобы проверить, мол не проинициализировано ли значение 4. Использовать указатели когда надо избежать копирования В общем, как-то так

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

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

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

в интерфейсы подходят только ссылки на объекты

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

мы точно про го говорим?

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

А какие проблемы тут можно огрести?

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

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

вот пример https://stackoverflow.com/questions/1658294/whats-the-purpose-of-the-lea-instruction

А какие проблемы тут можно огрести?

Есть интерфейс type Property interface { Get() (value sometype) Set(value sometype) } Метод Get() (value sometype) ты можешь имплементировать по значению (типа как бы подразумевая иммутабельность) А Set(value sometype) по ссылке Но в итоге если ты передаешь по ссылке, то ты все равно не сможешь его использовать как Property, т.к. Get будет определен по значению, а если по значению, то не сможешь из-за Set

Есть интерфейс type Property interface { Get() (value sometype) Set(value sometype) } Метод Get() (value sometype) ты можешь имплементировать по значению (типа как бы подразумевая иммутабельность) А Set(value sometype) по ссылке Но в итоге если ты передаешь по ссылке, то ты все равно не сможешь его использовать как Property, т.к. Get будет определен по значению, а если по значению, то не сможешь из-за Set

https://play.golang.org/p/g13GlLoMJgl

Или я неправильно понял?

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

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

Или я неправильно понял?

https://play.golang.org/p/fmXTcvohmyp

у вас уже есть эмприческое правило на глаз как передавать структуру?

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

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

1 медленная асм инструкция(доступ к хипу). Если у вас в структуре 5 полей и вам все поля нужны, то зачем указатель?

https://play.golang.org/p/fmXTcvohmyp

Ну все логично. Указатель все же интерфейсу соостветсвует.

Ну все логично. Указатель все же интерфейсу соостветсвует.

Ну как не крути, ты property ни по ссылке, ни по значению, как Property использовать не сможешь, потому универсально было определить все по ссылке

Ну как не крути, ты property ни по ссылке, ни по значению, как Property использовать не сможешь, потому универсально было определить все по ссылке

По ссылке можно.

По ссылке можно.

нельзя, Get определен по-значению, смотри внимательно мой пример

если бы я читал код одного пакета, где 50/50% передача по указателю и по значению я бы подумал, что аффтар мудак, или я не прав?

interface = struct{*itab, unsafe.Pointer}

в интерфейсе всегда ссылка (явно и неявно)

нельзя, Get определен по-значению, смотри внимательно мой пример

Ну посмотрите что компилятор говорит. Он только на 23 строчку ругается.

нельзя, Get определен по-значению, смотри внимательно мой пример

Просто оставляем ссылку и все ок. https://play.golang.org/p/dlm0EBee1DA

Ну посмотрите что компилятор говорит. Он только на 23 строчку ругается.

Ну разыменовывает автоматически. Потому и лучше методы определять по ссылке

Ну разыменовывает автоматически. Потому и лучше методы определять по ссылке

Конечно он разыменовывает при вызове данного метода также. Плохо это или хорошо зависит от конкретног участка кода.

ребят, подскажите, как в go dep зафиксировать версию на определённом коммите?

ребят, подскажите, как в go dep зафиксировать версию на определённом коммите?

https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md#dependency-rules-constraint-and-override

https://github.com/golang/dep/blob/master/docs/Gopkg.toml.md#dependency-rules-constraint-and-override

revision?

revision?

Да

да

спасибо

ребят, подскажите, как в go dep зафиксировать версию на определённом коммите?

может vgo?)

это, к сожалению, не я решаю

ERROR: S client not available

Кстати. Кто в курсе почему синтаксический сахар с вызовом метода определенного по указтелю с ресивером - структурой есть, а с передачей в интерфейс нет?

Пример: https://play.golang.org/p/TsFJD9wkeIq

Кстати. Кто в курсе почему синтаксический сахар с вызовом метода определенного по указтелю с ресивером - структурой есть, а с передачей в интерфейс нет?

потому что это не просто сахар

как ты разыменуешь интерфейс?

как ты разыменуешь интерфейс?

При чем тут разыменование то?

бл*, кто может вместо меня нормальными словами объяснить?

не знаю, как объяснять, но нет, за вас p в &p компилятор не будет делать

Я к тому, что вызвать метод, определенный по указателю если ресивер структура можно. А привести к интерфейсу нет.

не знаю, как объяснять, но нет, за вас p в &p компилятор не будет делать

Тогда что происходит на строчке 24 моего примера?

для метода компилятор сделает &p в момент вызова на истанциированом объекте

Тогда почему нельзя сделать &p на присваивании к интерфейсу?

Слишком неочевидно?

Копирование указателя в го происходит быстрее, чем копирование структуры, т.к. указатель в го - это _структура_ которая копируется (вот так вот, да) и в которой хранится тип и адрес уже непосредственно данных в памяти. А вот обращение к данным по ссылке конечно медленее - цена за разыменовывание. В го ГЦ работает не так, как в дотнете или жаве. В дотнете, объекты ГЦ маркируются тремя генерациями, всякие локальные переменные и мелкая требуха попадает в первую генерацию и чиститься первее всех. В го же оптимизация происходит на этапе компиляция, которая называется Escape Analysis, суть в которой, что многие объекты выделяются не на куче, а на стеке и сразу уничтожаются, что обнаруживается семантическим анализом их использования компилятором. Передавать по ссылке версус Передавать по значению Преждевременная оптимизация зло, потому ориентироваться на недокументированные оптимизации компилятора и гадание выделится ли структура на стеке или в куче не имеет смысла. Я выработал концептуально такую систему: 1. Передавать структуру по значению, если мы предполагаем ее использование как иммутабельную (но тут не забывайте, что мапы и слайсы все равно будут мутабельны) 2. Передача ссылки предполагая, что объект будет изменяться функцией, в которую мы ее передаем 3. Понимать указатель как nilable (nullable) значение, чтобы проверить, мол не проинициализировано ли значение 4. Использовать указатели когда надо избежать копирования В общем, как-то так

Эх, если бы только можно было явно указать, что значение иммутабельно передаётся по ссылке. Но это только мечты...

ну если добавить &property{}, то оно скомпилируется, так как операция Set не определена для func (p property), а определена только на func (p *property), что по факту является разным поведением

то, что (p property) стоит отдельно не отменяет того, что это просто еще один аргумент функции

ну если добавить &property{}, то оно скомпилируется, так как операция Set не определена для func (p property), а определена только на func (p *property), что по факту является разным поведением

Это понятно. Непонятно почему p.Set() тогда можно.

и объявив type A func(p property, v interface{}), функцию Get можно прятать за этим типом

и объявив type A func(p property, v interface{}), функцию Get можно прятать за этим типом

> interface{} REEEEEEEEEEEEE

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

так, стоп

это твой туториал .............

это видео-курс

https://www.coursera.org/learn/golang-webservices-1

читать тоже можно, там есть конспекты лекций

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

похоже на бред. Кто такое выдумал?

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

вместо этого изучи структуры данных, алгоритмы и О-сложности

День добрый, возникла проблемка. При отправки POST в теле Body получается набор символов вместо нормально ответа. Типо такого PFRLS1BHPjxSZXNwb25zZT48T3BlcmF0aW9uPkNyZWF0ZU9yZGVyPC9PcGVyYXRpb2 Если вызвать через curl -d "<TKKPG><Request>...</Request></TKKPG>" https://epaypost.xxx.com/Exec то нормальный ответ в xml приходот

tr := &http.Transport{ MaxIdleConns: 10, IdleConnTimeout: 30 * time.Second, DisableCompression: true, } client := &http.Client{Transport: tr} req, err := http.NewRequest( "POST", url, strings.NewReader(byteXml), ) req.Header.Add("Content-Type", "text/xml; charset=UTF-8") resp, err := client.Do(req) content, _ := ioutil.ReadAll(resp.Body)

Похоже на base64 encoded

Похоже на base64 encoded

Точно base64