Смешно)

Я когда на го только смотреть начинал тоже смеялся. Потом распробовал и больше не хочу наследования. Могу ещё добавить смешилок: методы встроенного объекта не могут влиять лишь на свой объект, т.е. если Mutex встроен в SafeCounter то он никаким образом не может поменять/прочитать данные из SafeCounter. И это прекрасно

Родитель в наследовании тоже никак не может поменять у наследника)

Но да, все го-любители вечно орут, что то не нужно, то не нужно, а в го все идеально, это разговор не о чем)

Это я то го-любитель?)) Я вот ору что дженериков нет, система типов говно, стандартная либа местами написана плохо... ну и ещё по мелочам

это не мешает теме "нужно ли наследование" быть ни о чем)

Но наследование и правда не нужно. Встраивание, агрегация, оборачивание - вот гораздо более очевидные и прозрачные подходы

это как веганы которые везде обязаны рассказать, что без мяса отлично живется)

С веганами тут мало общего. С какого языка на го перекатываетесь?)

Да я не перекатываюсь) Просто потыкал его в паре домашних проектов, а так мне и на котлине и питоне хорошо)

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

Ну значит с колокольни этих языков на го смотрите. Это пройдёт, со временем :) И только ощущение что дженериков нехватает останется :D

Мне и с наследованием хорошо, пасибки)

А мне было плохо с наследованием в С#

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

А в го меня прям радуют эти имплисит интерфейсы, такая ня ^_^

И они отчасти решают проблему дженериков

Но наследование и правда не нужно. Встраивание, агрегация, оборачивание - вот гораздо более очевидные и прозрачные подходы

Отсутствие наследования приносит проблему переопределения Second-Call методов.

Отсутствие наследования приносит проблему переопределения Second-Call методов.

Да, приносит. Но зачем из переопределять, это же деталь реализации из другой зоны ответственности?

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

Да, приносит. Но зачем из переопределять, это же деталь реализации из другой зоны ответственности?

Немного не понял про другое зону ответсвенности.

В итоге в больших старых проектах все превращается в монстров, а потом начинаются фасады и прочие паттерны вносящие ещё уровней абстракции.

Немного не понял про другое зону ответсвенности.

Ну вот есть какой-то second-call method, он скрыт внутри метода какого-то объекта. Если воспринимать верхнеуровневый метод объекта как черный ящик то нам не нужно знать о его реализации, соответственно переопределять second-call method не нужно, потому что его наличие в верхнеуровневом методе это деталь реализации.

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

Плюсую, очень популярно в энтерпрайзной джавне, видел не раз такое своими глазами

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

Ну вот есть какой-то second-call method, он скрыт внутри метода какого-то объекта. Если воспринимать верхнеуровневый метод объекта как черный ящик то нам не нужно знать о его реализации, соответственно переопределять second-call method не нужно, потому что его наличие в верхнеуровневом методе это деталь реализации.

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

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

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

Предпочитаю так не делать, даже если очень нужно. В любом случае, я (почти)всегда могу реструктурировать/обернуть код так чтобы вынести то что было деталью реализации в публичное api

Вобщем, меньше магии - проще жизнь и меньше головняка для разработчика

вот да

а наследование мгновенно превращается в магию

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

Всем привет. Поможете новичку? Ломаю голову по поводу подключения к бд

подробнее

Выкладывай!

и первый вопрос - гуглил проблему то?

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

цэ-два-креста, да

и первый вопрос - гуглил проблему то?

Не торопи коней, может действительно интересный вопрос будет!

не будет :)

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

Гуглил, но не вдуплил. Да нет, не будет) Вопрос по поводу удержания соединения с бд. Создаю подключение к бд, вешаю его глобально, чтобы был доступ извне пакета. В бд стоит лимит 30 секунд на ожидание сброса соединения, в подключение так же ставлю 30 секунд. Вроде, по логике, всё должно быть ок, но нет. Начинаю ловить too many open files. Вроде так. После всех запросов закрываю методом close

В чем может быть беда

вероятно ты на каждый чих открываешь коннект все же?

Что за база? Что за либа, которой цепляешься?

ну и код в студию.

Гуглил, но не вдуплил. Да нет, не будет) Вопрос по поводу удержания соединения с бд. Создаю подключение к бд, вешаю его глобально, чтобы был доступ извне пакета. В бд стоит лимит 30 секунд на ожидание сброса соединения, в подключение так же ставлю 30 секунд. Вроде, по логике, всё должно быть ок, но нет. Начинаю ловить too many open files. Вроде так. После всех запросов закрываю методом close

где-то ошибка с закрытием ресурсов

Пока не могу скинуть код. Бд мускул, либа дефолт

Инстанс один при запуске приложения

ну так не бывает

Драйвер https://github.com/go-sql-driver/mysql

SetMaxOpenConns и SetMaxIdleConns пробовал покрутить в сторону уменьшения?

Я пишу в пассив из 200млн элементов знаения - программа занимает 4 гб. мне надо чтобы она быстро работала с этими значениями из памяти. Но потом высвобождается и программа занимает 150мб. Все уходит на диск?? Сборщик мусора? Как запретить собирать переменную определенную? Пытался отключать сборщик.

Нет, но думаю, что стоит всё уменьшить

Буду крутить. Там же по идее тикер ставиться на рефреш подключения?

Я пишу в пассив из 200млн элементов знаения - программа занимает 4 гб. мне надо чтобы она быстро работала с этими значениями из памяти. Но потом высвобождается и программа занимает 150мб. Все уходит на диск?? Сборщик мусора? Как запретить собирать переменную определенную? Пытался отключать сборщик.

Пассив эт чо такое?

Пассив эт чо такое?

массив

Я пишу в пассив из 200млн элементов знаения - программа занимает 4 гб. мне надо чтобы она быстро работала с этими значениями из памяти. Но потом высвобождается и программа занимает 150мб. Все уходит на диск?? Сборщик мусора? Как запретить собирать переменную определенную? Пытался отключать сборщик.

сборщик мусора собирает только мусор

а какого типа значения?

как бы сделать что она железно оставалась

uint64[200000000]

ну

Буду крутить. Там же по идее тикер ставиться на рефреш подключения?

все же глянуть бы код. как ты пишешь и как коннект интишь

точно щас не помню число

ERROR: S client not available

но больше 80млн

как бы сделать что она железно оставалась

сделай глобальную переменную

попробую

чуть позже подниму все

сделай глобальную переменную

Сомнительный совет ))

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

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

Нет, но думаю, что стоит всё уменьшить

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

это делал год-1.5 назад ) сейчас восстановился интерес к исследованию

может что обновилось )

Сомнительный совет ))

совет как совет. мужик же явно не понимает, что делает...

я не понимаю почему оно так работает

данные остаются

как написано - твак и работает

я хочу чтобы они оставались в оперативке - они же кудато деваются?

(у него фантазии нету)

я хочу чтобы они оставались в оперативке - они же кудато деваются?

ты их освободил, бро

я хочу чтобы они оставались в оперативке - они же кудато деваются?

В /dev/null?

ты их освободил, бро

у меня такой же чехол на маке аахха

ахахах )

эх понять бы

тогда и решение нашлось

буду пробовать и вас мучать дальше вопросами

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

я извиняюсь за банальщину, но pprof с отладкой памяти пробовался?

там же видно, какой вызов приводит к нарастанию

вы говорите с js разработчиком с 18 стажем и go любителем ) но я стараюсь

go поразил - буду продолжать

скорость и простота на невероятной высоте

https://blog.golang.org/profiling-go-programs

кстати сегодня поставил gogland в нем работает дебаггер? сходу не заработал( не останавливается ) в инете пишут что не пашет. должен же. изучать дальше или реально не пашет?