Eduard Edison

В голанге нет передаче по ссылке?

Нету, в вашем примере идет передача указателя по значению. self *TDive — это указатель. Содержит (хранит в памяти) адрес указывающий на объект. Это просто значение. Оно хранится в памяти, потому можно даже получить указатель на эту переменную (указатель на указатель).
Разберитесь, что такое ссылка и что указатель, и почитайте что в Go.

Если в go нет ссылок, то как же происходит РАЗЫМЕНОВАНИЕ??))

РАЗЫМЕНОВАНИЕ чего?

В Go нету ссылок, есть указатели.

Передаются не объекты, а переменные.

Простите, что????

Передаются они в джаве только по значению.

Я не уверен, просто возможно, что переменные в Джаве изначально содержат ссылку на объект. Вот например:

Object obj = new Object()

Тут obj хранит ссылку или сам объект (значение)?

Если в b в main напечатается k: 2 и v: 2, то нельзя. Плюс это означает передачу параметра b по ссылке.

fmt.Print(b) выведет k: 2 и v: 2. Это не ссылка, это указатель передали в другую функцию по значению. Указатель содержит адрес, это просто значение тип 0x...... Если скопировать это значение у другую переменную — тогда она тоже будет указывать на тот же объект.
Тип в функции func foo(b *bar) — *bar указатель, причем типизированный указатель. Есть еще unsafe.Pointer.

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

нет, в Java, насколько я знаю, объекты передаются по ссылке. Можно ли в Java сделать, например, вот так в Go:

package main

import (
    "fmt"
)

type bar struct {
    k string
    v int
}

func main() {
    b := bar{k: "1", v: 1}
    foo(&b)
    fmt.Print(b)
}

func foo(b *bar) {
    b2 := bar{k: "2", v: 2}
    *b = b2
}

нет, есть передача по ссылке, есть передача по значению (не важно, что передается). Некоторые языки имеют и передачу по ссылке и по значению. Ссылка это не указатель, это два разных понятия. В Go же есть только передача по значению.

значение, на которое указатель указывает не передается по ссылке. Можно сделать самому явно дереференсинг уже в теле функции. Передачи по ссылке в Go нету.

в Go нету ссылок, есть только указатели, которые передаются по значению.

И как часто она используется?

не часто, но удобная когда нужно сгенерить разные последовательности.
Можно же генерить с любым шагом или, например, n^2 последовательности

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

в Go нету передачи по ссылке, только по значению.

если это реально узкое место, то можно и код генерить. Мне интересно сравнить всю цепочку

вы сравниваете С# реализации, а не с Go reflect.DeepEqual. Код нужно скомпилировать, заранить тесты. Насколько существенная разница будет для Go?

Я Go плохо знаю.

но достаточно, чтобы критиковать?

а вы сравнивали тайминги? Я в тестах reflect.DeepEqual, точнее уже готовой обертки типа testify.assert, чем это отличается от вашего?

London is the capital of Great Britain

не сильно понял пример, в чем проблема там? Интерфейсная переменная содержит тип и указатель на значение. Конечно же когда пытаетесь сделать type assertion интерфейсной переменной в другой тип, а не в тот тип, который переменная содержит, получаете панику.

fzf быстрое и асинхронное

А как вы храните секреты (разного рода credentials для сервисов)? Как это интегрируете с CI/CD?

Не понимаю я иронии комментирующих — если вам сервис нравится, то не пользуйтесь. Где и когда реклама вылазит, когда втюхивать платные подписки, нужно-нет дайверсити — это не инженеры решают.
А вот как решить технические проблемы, когда у тебя 20к rps, 10TB база — это как раз к инженерам. Думаю их опыт будет полезен.

Я к тому, что я никогда не видел перевод термина fiber, волокно прям ухо режет. Лучше уже без перевода.

Что такое "волокно"? Можете писать понятными и принятыми терминами? Та же корутина, etc

частный, потому что вы вцепились в название consumer, переименуйте его в queue, определите там интерфейс и используйте точно так же.

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

Что если еще одного консюмера не будет, а будут только продюсеры? Что если не будет этой сложной структуры данных? Что если определить queue пакет и там иметь интерфейсы консюмеру и продюсеру и общую структуру данных?

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

Определением интерфейса в пакете, в котором он используется.

с использованием типа в producer

Вы только что это сами придумали и сами придумали эту зависимость.
Я бы определил этот сложный тип в консюмере и как уже сказал — при этом пакет с реализацией зависел бы от пакета с интерфейсом.

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

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

Или вы и свои типы тоже стараетесь не использовать?

Ну как это, использую. Опять же, в данном случае реализация интерфейса (интерфейс в пакете foo) будет зависеть от пакета foo (от интерфейса), но не наоборот (что вы пытаетесь тут доказать), хоть и пакет foo ее будет использовать.

По «классике», зависимости уменьшаются путем выделения общих сущностей (например, интерфейсов) в отдельную библиотеку.

Никто не мешает вам так сделать, если вы так привыкли. Пример с io.Reader сами привели. Иногда так даже лучше делать. Я стараюсь такого избегать.

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

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

Чем мешает явная зависимость размещению интерфейса у пользователя?

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

То есть весь упрек в том, что контракт (документация?). Так когда реальный код я буду писать, я напишу доку и интерфейсу, и структуре Сервис и методу Сенд.

Я очень часто писал либы, сервисы, где у меня был интерфейс Logger. И никакой зависимости от реализации не было.
Логическая зависимость — это демагогия. Я создаю интерфейс, я выдвигаю требования, тот кто использует мою библиотеку должен выполнить мое требование.

Так вот, с чего это интерфейс будет написан после реализации? Вы так и не ответили на вопрос, с чего этот спор начался. Конечно он может быть написан после, это совершенно не обязательно. Что я вам и показал выше на примере Логгера.

вы так и не ответили на вопрос.
С чего это интерфейс будет написан после реализации?

Как узнать, подходит какая-то структура семантически для использования в Send() или нет?

Где тут зависимость от реализации Publisher?

С чего это он будет написан после реализации?

package service

import "encoding/json"

type Publisher interface {
    Publish([]byte) error
}

type Service struct {
   pub Publisher
}

func NewService(p Publisher) *Service {
    return &Service{
        pub: p,
    }
}

func (s *Service) Send(msg Message) error {
    data, err := json.Marshal(msg)
    if err != nil [
        return err
    }
    return s.pub.Publish(data)
}

Где тут зависимость от реализации Publisher?

Интерфейс это не общее, интерфейс описывает реализацию.
Каким образом интерфейс будет зависеть от реализации в случае когда интерфейс объявлен в месте, где он используется?

Но размещение интерфейса у пользователя позволяет уменьшить зависимости пакета, ничего не нужно импортить. Тоже самое про другую сторону — когда реализация не знает про интерфейс.

Смысл интерфейса стремится к нулю, когда у вас каждый про каждого знает.

во-первых есть gogland (даже ссылку вам уже дали). Во вторых, я говорю про сам язык и комьюнити.
В стандартной библиотеке есть go/ast, go/parser, go/printer, etc которые позволяют очень просто создавать свои тулзы для работы с Go кодом (то ли генерация, то ли рефакторинг), которые потом очень просто интегрировать с vim/emacs/sublime/atom.
Потому опять же скажу — не могу вспомнить я других языков с таким большим набором тулзов для работы с кодом которые поставляются с языком, как есть у Go.

только вот IDEA это не тулза из коробки которая идет с Java. Это IDE которая разрабатывается отдельной компанией, а не комьюнити.

В Go же gorename, guru, govet, golint, gofmt, etc и все это разрабатывается Go сообществом.

ну это все субъективно — я называю одной, иногда двумя буквами и мне ок.
На счет рефакторинга — какой другой язык из коробки имеет такойбольшой набор тулзов? Я вот прям и не могу вспомнить.

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

вручную надо это делать, gorename'ом переименовывать каждый ресивер.

Я же сказал принято, не обязательно. Если ресиверы будут именоваться по-разному — то golint ворнинг выдаст.
Иногда и я пишу не первую букву, например вот в таких случая (p AsyncProducer), хотя опять же — первая важной части названия.

1. Тут идея интерфейсов другая, не "я хочу быть вот таким то", а "мне нужно вот такое то"
2. Есть принятые стандарты — ресивер как первая буква типа. Например (p *Producer), (c *Client), etc.
3. https://github.com/golang/go/issues/2016