ну вообще конечно человеку с завышенной самооценкой в IT самое место

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

по моему опыту в IT каждый первый всё знает и не видит смысла развиваться дальше

по моему опыту в IT каждый первый всё знает и не видит смысла развиваться дальше

Любой коннекшн с базой?

Потому что it это не про it. it это про решение бизнесзадач лишь бы работало, посредством дешевой раб. силы, которая приходит в it за зарплатой, и чтобы не на завод. А потом на всяких фронтенд конфах ебут друг друга в жопу, кто круче фреймворк освойл. ФРЕЙМВОРК, КАРЛ! В it ценится умение решать инфраструктурные задачи. Если ты умеешь webpack'ом файлики конкатенировать или запускать всесь свой говнокод со всеви зависимостями из говна в изолированном окружении (да-да, я на тебя смотрю, мамкин девопс инженер), то это типа збс. Вот по этому мы и живём с монолитными говнобраузерами на оверлям строк кода, с сайтиками которые ждут по 250мб и 25% цпу. По этому, у нас есть говно-конференции, где невъебенные докладчики читают о том, как блеать повысить эффективность работы сайтика. Эффективность, блеать! Сайтика, блеать!!!! Вот потому, что для разработки, тонкого клиента + ui к базе юзерского контента у нас спрашивают по СТЕК ДЛЯ ФРОНТЕНДА, БЛЕАТЬ! И на бекенде то же дерьмо творится. Привет жаве с её жвмом и шарпу. Для примитивнейшей логики заводят целые проекты на спринге.

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

мои, как минимум, другие

По каким?

По субъективным ощущщениям с конференций - у бэкендеров все прекрасно, но хочется еще лучше. Все доклады по бэкенду из серии - в этом году GC всего на 10% стал быстрее, хотелось бы хотя бы на 15%, "работаем дальше". Или там, есть две системы сборки, одна хорошо подходит для больших монолитных проектов, а другая — для маленьких стандартизированных. То есть все проблемыбэкенда: какое из двух прекрасных решений выбрать. На конфах по JS - визг, и чувство что мир катится в ад, а ты сидишь на дне колодца.

Любой коннекшн с базой?

> в этом году GC всего на 10% стал быстрее, хотелось бы хотя бы на 15%, "работаем дальше" Верный признак того, что бэкенд стагнирует

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

модель акторов изобрели в 70-х

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

Помните я говорил о том, что не хватает алгебраических типов (aka типов сумм). Нашёл хорошую статью, которая хорошо поясняет почему их не хватает. https://habr.com/post/424895/

а как то можно объявить глобальную переменную из функции?

получается пакеты это надглобальные объекты шоле)

а как то можно объявить глобальную переменную из функции?

Можно заранее объявить/создать нужный "объект", и потом юзать указатели, чтобы вносить все изменения в него уже в самой функции.

Вы имеете в виду объект как глобальная переменная в пакете main?

на самом деле просто дефолтный гофер о них не слышал, а тот что слышал боится, что слишком сложно ибо "алгебраические" же типы

Да, но можно и не в main. В маин вызывать только создание/инициирование объекта и присваивать это всё глобальной переменной, как пример. Я кодить серьезно менее месяца начал, могу коряво объяснять, извиняюсь. Как пример набросал: https://play.golang.org/p/8Rqf6S6zACf

Дефолтный гофер всю алгебру еще в 5 классе прогулял ))

Дефолтный гофер всю алгебру еще в 5 классе прогулял ))

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

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

Если взять подход Rust к ошибкам, то из проверки err на nil код превратится в постоянную распаковку с матчингом, результат работы функции пришел или ошибка

а у нас result, _ := function()

точно так же как ты её ловишь здесь, ? — это просто сахар для кода, проверяет, является ли результат ошибкой и тогда возвращает ошибку из функции или результат не является ошибкой и тогда выполнение функции продолжается

А если таких ? было много, то потом полчаса пишешь сверху обработку с матчингом, какая из ошибок все-таки поймалась. Или нет?

В go2 будет check для этих целей

Почему нельзя было сразу такой сахар сделать - большая загадка.

Чтобы читать код было проще

всем.

всем.

Потому же почему нельзя было запилить сразу генерики или алгебраические типы — авторы языка слишком узколобы.

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

Я считаю, что "всем известное обобщенное решение" - очень субъективное понятие. Чем больше в языке таких решений, тем дольше\сложнее его учить, читать, писать на нем и понимать его. Не понимаю, почему из Go хотят сделать Rust, когда можно писать на Rust? Там как раз много кода с дженериками, ёлки из аргументов-типов к ним, обработка ошибок как в Rust и прочие радости

Вот только сами создатели go уже решили сделать из go2 что-то отдаленно похожее на раст.

Вот только сами создатели go уже решили сделать из go2 что-то отдаленно похожее на раст.

Раст с HKT

эм.. А по каким критериям можно это увидеть? check в черновиках?

Я считаю, что "всем известное обобщенное решение" - очень субъективное понятие. Чем больше в языке таких решений, тем дольше\сложнее его учить, читать, писать на нем и понимать его. Не понимаю, почему из Go хотят сделать Rust, когда можно писать на Rust? Там как раз много кода с дженериками, ёлки из аргументов-типов к ним, обработка ошибок как в Rust и прочие радости

Так всем ненужные дженерики собираются сделать

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

Я считаю, что "всем известное обобщенное решение" - очень субъективное понятие. Чем больше в языке таких решений, тем дольше\сложнее его учить, читать, писать на нем и понимать его. Не понимаю, почему из Go хотят сделать Rust, когда можно писать на Rust? Там как раз много кода с дженериками, ёлки из аргументов-типов к ним, обработка ошибок как в Rust и прочие радости

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

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

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

Вот что-то тут мусолится уже 3й день, а толковых конструктивных предложений на github.com/golang/go/issues так и не появилось

Вот что-то тут мусолится уже 3й день, а толковых конструктивных предложений на github.com/golang/go/issues так и не появилось

Ага-ага Я пока на генериках видел только велосипеды

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

Вот что-то тут мусолится уже 3й день, а толковых конструктивных предложений на github.com/golang/go/issues так и не появилось

Ага-ага Я пока на генериках видел только велосипеды

То есть уже будет язык не для написания кода, а для использования библиотек? А как библиотекописцам быть?

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