значение, на которое указатель указывает не передается по ссылке. Можно сделать самому явно дереференсинг уже в теле функции. Передачи по ссылке в Go нету.
не сильно понял пример, в чем проблема там? Интерфейсная переменная содержит тип и указатель на значение. Конечно же когда пытаетесь сделать type assertion интерфейсной переменной в другой тип, а не в тот тип, который переменная содержит, получаете панику.
Не понимаю я иронии комментирующих — если вам сервис нравится, то не пользуйтесь. Где и когда реклама вылазит, когда втюхивать платные подписки, нужно-нет дайверсити — это не инженеры решают.
А вот как решить технические проблемы, когда у тебя 20к rps, 10TB база — это как раз к инженерам. Думаю их опыт будет полезен.
Тим лид не менеджер. Ему не нужно общаться с людьми, ему нужно общаться с программистами. Он не PM или PO. Он должен менторить команду, обучать ее, решать вопросы архитектуры или дизайна, ревьювить код.
Но у нас это как то все смешалось и тим уже менеджер, хотя это не правильно.
Вы берет частный случай, добавляете туда кучу всего и теперь говорите, что было неправильно. Но и как я уже писал, иногда лучше выносить в отдельный пакет.
Что если еще одного консюмера не будет, а будут только продюсеры? Что если не будет этой сложной структуры данных? Что если определить queue пакет и там иметь интерфейсы консюмеру и продюсеру и общую структуру данных?
Ну так как вы от этого избавитесь, кроме как выносом общих типов в отдельный пакет?
Определением интерфейса в пакете, в котором он используется.
с использованием типа в producer
Вы только что это сами придумали и сами придумали эту зависимость.
Я бы определил этот сложный тип в консюмере и как уже сказал — при этом пакет с реализацией зависел бы от пакета с интерфейсом.
Еще раз, вы мне пытаетесь доказать про логическую зависимость при определении интерфейса в пакете, где он используется — можете привести код с интерфейсами где есть логическая зависимость и где ее нету?
Более того, если у вас в интерфейсе присутствует хотя бы с один метод с параметром или возвратом проблемно-ориентированного интерфейса/структуры, то иного пути достичь желаемого (уменьшения зависимости) нет — нужно выделять общие сущности отдельно.
Или вы и свои типы тоже стараетесь не использовать?
Ну как это, использую. Опять же, в данном случае реализация интерфейса (интерфейс в пакете foo) будет зависеть от пакета foo (от интерфейса), но не наоборот (что вы пытаетесь тут доказать), хоть и пакет foo ее будет использовать.
значение, на которое указатель указывает не передается по ссылке. Можно сделать самому явно дереференсинг уже в теле функции. Передачи по ссылке в Go нету.
в Go нету ссылок, есть только указатели, которые передаются по значению.
не часто, но удобная когда нужно сгенерить разные последовательности.
Можно же генерить с любым шагом или, например, n^2 последовательности
в Go нету передачи по ссылке, только по значению.
если это реально узкое место, то можно и код генерить. Мне интересно сравнить всю цепочку
вы сравниваете С# реализации, а не с Go
reflect.DeepEqual. Код нужно скомпилировать, заранить тесты. Насколько существенная разница будет для Go?но достаточно, чтобы критиковать?
а вы сравнивали тайминги? Я в тестах reflect.DeepEqual, точнее уже готовой обертки типа testify.assert, чем это отличается от вашего?
London is the capital of Great Britain
не сильно понял пример, в чем проблема там? Интерфейсная переменная содержит тип и указатель на значение. Конечно же когда пытаетесь сделать type assertion интерфейсной переменной в другой тип, а не в тот тип, который переменная содержит, получаете панику.
fzf быстрое и асинхронное
А как вы храните секреты (разного рода credentials для сервисов)? Как это интегрируете с CI/CD?
Не понимаю я иронии комментирующих — если вам сервис нравится, то не пользуйтесь. Где и когда реклама вылазит, когда втюхивать платные подписки, нужно-нет дайверсити — это не инженеры решают.
А вот как решить технические проблемы, когда у тебя 20к rps, 10TB база — это как раз к инженерам. Думаю их опыт будет полезен.
Тим лид не менеджер. Ему не нужно общаться с людьми, ему нужно общаться с программистами. Он не PM или PO. Он должен менторить команду, обучать ее, решать вопросы архитектуры или дизайна, ревьювить код.
Но у нас это как то все смешалось и тим уже менеджер, хотя это не правильно.
Я к тому, что я никогда не видел перевод термина fiber, волокно прям ухо режет. Лучше уже без перевода.
Что такое "волокно"? Можете писать понятными и принятыми терминами? Та же корутина, etc
частный, потому что вы вцепились в название consumer, переименуйте его в queue, определите там интерфейс и используйте точно так же.
Вы берет частный случай, добавляете туда кучу всего и теперь говорите, что было неправильно. Но и как я уже писал, иногда лучше выносить в отдельный пакет.
Что если еще одного консюмера не будет, а будут только продюсеры? Что если не будет этой сложной структуры данных? Что если определить
queueпакет и там иметь интерфейсы консюмеру и продюсеру и общую структуру данных?Определением интерфейса в пакете, в котором он используется.
Вы только что это сами придумали и сами придумали эту зависимость.
Я бы определил этот сложный тип в консюмере и как уже сказал — при этом пакет с реализацией зависел бы от пакета с интерфейсом.
Еще раз, вы мне пытаетесь доказать про логическую зависимость при определении интерфейса в пакете, где он используется — можете привести код с интерфейсами где есть логическая зависимость и где ее нету?
Ну как это, использую. Опять же, в данном случае реализация интерфейса (интерфейс в пакете
foo) будет зависеть от пакета foo (от интерфейса), но не наоборот (что вы пытаетесь тут доказать), хоть и пакет foo ее будет использовать.