• Go: Хороший, плохой, злой
    –1
    В голанге нет передаче по ссылке?

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

  • Go: Хороший, плохой, злой
    0
    Если в go нет ссылок, то как же происходит РАЗЫМЕНОВАНИЕ??))

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


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

  • Go: Хороший, плохой, злой
    0
    Передаются не объекты, а переменные.

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


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

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


    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.

  • Go: Хороший, плохой, злой
    0
    Во многих языках где есть ссылки, ссылка является таким же типом данных что и указатель.

    нет, в 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: Хороший, плохой, злой
    0

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

  • Go: Хороший, плохой, злой
    0

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

  • Go: Хороший, плохой, злой
    +1

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

  • Go: Хороший, плохой, злой
    0
    И как часто она используется?

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

  • Go: Хороший, плохой, злой
    0
    В голанге нужно явно получать адрес переменной при передаче по ссылке.

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

  • Go: Хороший, плохой, злой
    0

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

  • Go: Хороший, плохой, злой
    0

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

  • Go: Хороший, плохой, злой
    –4
    Я Go плохо знаю.

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

  • Go: Хороший, плохой, злой
    0

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

  • habrahabr.ru → habr.com
    +3

    London is the capital of Great Britain

  • Go: Хороший, плохой, злой
    +1

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

  • Vim спустя 15 лет
    0

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

  • AMA. Avito. Backend
    0

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

  • AMA, или спроси бэкендера из Avito: анонс
    +4

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

  • Comment from a drafted post.
  • JavaScript как мыслевирус
    –1

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

  • JavaScript как мыслевирус
    0

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

  • На пути к Go 2
    +1

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

  • На пути к Go 2
    0

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


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

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

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


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

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


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

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

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

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

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

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

  • На пути к Go 2
    +1

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


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


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

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

  • На пути к Go 2
    0

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


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


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

  • На пути к Go 2
    0

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


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

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

  • На пути к Go 2
    0

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


    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?

  • На пути к Go 2
    0

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

  • На пути к Go 2
    0

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


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

  • На пути к Go 2
    0

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

  • На пути к Go 2
    +1

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


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

  • На пути к Go 2
    0

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

  • На пути к Go 2
    0

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

  • На пути к Go 2
    0

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

  • На пути к Go 2
    0

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

  • На пути к Go 2
    0
    1. Тут идея интерфейсов другая, не "я хочу быть вот таким то", а "мне нужно вот такое то"
    2. Есть принятые стандарты — ресивер как первая буква типа. Например (p *Producer), (c *Client), etc.
    3. https://github.com/golang/go/issues/2016
  • Теория современного Go
    0
    это разрабатывается той же командой, что и язык и это часть проекта Go, иногда либы с golang.org/x/ включают в релиз языка, как случилось с context, http2.
    Еще там много тулинга для Go, типа guru, golint