Для вката в Go читай:
- Донован, Керниган "Язык программирования Go"
- https://www.golang-book.com/
- книги из списка https://github.com/dariubs/GoBooks
- а также смотрим видео https://www.youtube.com/channel/UC_BzFbxG2za3bp5NRRRXJSw
Пэкеджи можно искать тут https://github.com/avelino/awesome-go
Сремся за отсутствие дженериков и ООП, смеемся с реализации дженериков в go2, спорим о том, какими скобочки должны быть на самом деле, пробрасываем ошибки, пытаемся понять почему код с каналами и многопоточностью работает медленнее, чем однопоточный код, находим по каждому крупному багу и косяку в языке пост в блоге го, который объясняет, что это фича, ищем обоснование, зачем дженерики не нужны, смеемся над оопэшниками, которые не могут жить без ексепшенов и DDD, дженериков и размазанной бизнес-логики, ждем, когда нам подвезут аналоги эксепшенов и дженериков
Прошлый тред >>1743955 (OP)
А в чем профит писать такое на перле? Только из-за того, что там регулярки более продвинутые чем в Го? Я думаю это незначительный плюс, с учетом того, что в го я могу импортнуть компоненты компилятора на самом деле не совсем, но для некоторых internal пакетов есть паблик аналоги и работать с уже с готовым ast и прочими абстракциями.
В туре только совсем базовые вещи. По хорошему нужно еще знать что в стандартной библиотеке находиться, ну и по диагонали пролистать golang.org/x/* , это практически тоже stdlib, только без гарантий 1.x совместимости.
Но как я понимаю - ты проходишь на Степике курс по го?
Тогда пройди сначала курс, там в общем-то дается вся информация, чтобы пройти их задачи.
Задал тот же вопрос в Котлин треде. Пытаюсь выбрать между Котоином и Го для серверной разработки. Есть опыт с нодой но не нравится.
Короч думаю попробовать запилить небольшой проект в учебных целях. Веб сокеты, полсотни юзеров, база данных и круд уровня списка товарных позиций. В моём случае проблема ещё в том, что хотелось бы чтобы это всё крутилось на недорогом VPS в докере. Собственно вопрос хватит ли Гошечке 2Gb оперативки под обозначенную выше задачу (вклад базу/докер/фронтенд и мониторинг)?
Или лучше не лезь оно тебя сожрет оставаться на ноде?
Для твоей задачи более чем хватит ноды, на самом деле. Рекомендую использовать typescript и nest, базарю еще захочешь.
На го аналогичный проект выйдет у тебя в 3 раза больше строк кода, и дело тут не в ручной обработке ошибок. Нужно оно тебе? Какие профиты ты с этого получишь?
Приколы какие-то у тебя
Гошечке-то для рестика с вебсокетом + скл пул на такое количество юзверов и 128мб за глаза должно хватить. И вообще в го и гц максимальная латенси ориентация, а не бендвизная. Твои боязни скорее можно применить к котлину, нежели пщ
Подводных практически никаких, кроме стандартного месяца тупижа, свойственного при перекате на любой новый язык
в каких? https://www.golang-book.com/books/intro/13#section7
люди читают текст программы сверху вниз, и логично функции, которые исполняются первыми, разместить выше.
Язык охуенен, на самом деле.
Надеюсь, дженериками его не сильно испортят.
И я понял, зачем они сделали постфиксные типы без разделителей, квадратные скобки перед типом массива и т.п.
Чтобы люди не писали на го по правилам других языков, к которым они привыкли. Чтобы на уровне подсознания было разделение.
А люди всё равно пытаются писать на го, как на питоне, джаве, си, а потом ещё и сюда пишут, лол.
Можно как-нибудь заапендить несколько байт слайсов подряд?
Можно использовать рефлексию, и ебашить слайсы в любые функции вообще:
https://stackoverflow.com/questions/17555857/go-unpacking-array-as-arguments/17556146
Можно сделать так, как сказал >>1877808
Прямо в скобках при вызове функции. Только в конце добавить …
Мне кажется (точно не нашёл ответа), что это по затратам памяти будет то же самое, как если бы можно было сделать unpack нескольких слайсов.
А если не байты, то можно и append использовать.
Наоборот же.
Я (>>1877844 →) вот, например, хочу убежать в го.
Заебало реально.
Хочется чётких и дерзких микросервисов и прочих модных вещей.
Принчу и ос (*file) врайчу, ничего не оверлапится, пишется как будто синхронно
Мутекс и вейтгруппа дёргаются только на входе и выходе из функции, к и\о отношения не имеют
Это какой-то волшебный рантайм или где-то обосрался?
Гринтреды вроде спавнятся и крутятся нормально
И вправду я тормоз и за счёт мутексения буффера у меня там ничего не может при конкуренте зафейлиться, лол
Но попробовал прогнать без него и всё равно os.*file write вроде не отличается
И вообще почему те же принты не оверлапятся в stdout?
По годокам вроде не тред-сейфовые
https://play.golang.org/p/_LCu_cHahGf
Залез сейчас во внутренности работы с файлами и да, Write действительно защищен мьютексом. https://golang.org/src/internal/poll/ , смори файл fd.go с суффиксом твоей ОС
Ожидал что может быть "HuuHoooo"
Я не очень во всякие буферы с флашеми, что-то вот вспомнил свои выстрелы по ногам раньше, вроде в С
Правда сейчас нагуглил, что даже в С форк копирует дискрипторы и еще что-то там системное, не знаю, что я там раньше делал, лол
Ты думал у тебя буквы в словах перемешаются при параллельной печати из горутин?
Это было бы слишком, я думаю.
Хочешь чего-то такого - сделай свой "принт", который будет печатать в заранее созданный длинный массив байтов. Потом - выведи заполненный массив в текстовый файл. Всё сразу увидишь.
expected 'STRING', found '{'
тут:
import {
"golang.org/x/tour/tree"
"fmt"
}
select - https://play.golang.org/p/7Uzle2jTsIS
ctx - https://play.golang.org/p/5PXIDpUBuIT
wg - https://play.golang.org/p/CjYO5H87gMe - в случаях, когда количество горутин-воркеров заранее известно - лучше не вызывать в цикле wg.Add(1), а сразу перед циклом сделать wg.Add(100). Важный момент - wg.Add должен быть вызван до wg.Wait, по этому лучше всего его вызывать в той же горутине где и wg.Wait, а не в той, где wg.Done
Золотые слова.
Не так уж давно, Manning собрался издать книжку Grokking Reactive Programming - про RxJava.
Они даже начали продавать её по MEAP, ещё до завершения.
И я даже её купил, сдуру.
Но, в процессе написания, книжка превратилась в RxJava for Android Developers.
Т.е., помимо андроида про Rx на джаве и написать-то нечего оказалось.
Такие дела.
Также, я, в своё время, прочёл маннинговскую же Functional Reactive Programming.
Там не про Rx, а вообще, на примере самодельного фреймворка.
Было охуенно познавательно, но, практического применения, помимо UI и подобных вещей, я не увидел.
В общем, всё это весьма нишевая хуйня, реально нужная весьма немногим.
Т.е. в коде совершенно непонятно, какой именно интерфейс реализует та или иная функция.
Очень неудобно читать код, приходится рыться в документации и исходниках буквально по каждой мелочи.
Даже не представляю, что за хуйня творится в больших проектах.
Это же совершенно перекрывает все полезные штуки этого языка.
И есть ли какой-то стандартный комментарий, чтобы отмечать это в своём коде? По типу тегов javadoc?
> Почему в го нет конструкции типа implements InterfaceName в джаве?
Это осознанное решение разработчиков языка, в целом имеет больше плюсов, чем минусов, на мой вкус.
> И есть ли какой-то стандартный комментарий, чтобы отмечать это в своём коде? По типу тегов javadoc?
В стандартной либе практически над каждым методом, который реализует интерфейс это обозначено, но вроде никто вне стандартной либы так не делает.
Если сильно хочется - пиши конструкции вида var _ IfaceName = new(TypeName), голанд даже может указать на недостающие методы и предложит их создать.
Чувак, про иде я в курсе. Я джаваёб со стажем, если что.
Вопрос был не об этом.
А о том, почему такой красивый простой язык, с великолепно читаемым кодом, имеет такой неожиданный изъян.
Полагаю, что дело в том, что, фактически, в го нет имплементации интерфейсов, как таковой. Т.е. если есть 2 интерфейса с методом Zalupa(), то 1 тип может их оба сразу имплементировать, просто реализовав этот метод.
Но, я бы писал это в комментариях к фукнциям всё равно.
Типа //@implements ZalupaProvider
И мне странно, почему такую простую вещь никто не делает.
Хотя, может и делают. Я пока книжки и туториалы читаю, в основном, реальных исходников видел немного.
>>1879822
Да, такое ощущение, Rx только в JS и прижился.
И, в основном, на фронте, хотя бывают и исключения, как видим.
Ну, может, ещё в дотнете, т.к. это изначально мелкомягкое поделие, но, я туда не хожу, и хз что там вообще.
А то видел только, что всё руками надо go get, но это хз для кого сделано.
Нет.
Ты, видимо, ваннаби-вкатыш, и не писал ничего сложнее хелловорлда в своей жизни.
Это затрудняет понимание кода.
Выше пишут, что в стандартной библиотеке комментируют имплементации. Потому, что профессионалы, и понимают такие вещи.
Если функция соответствует нескольким интерфейсам, то надо писать либо их все, если они известны в данный момент, или тот, который подразумевается разработчиком в момент написания этой функции.
Потому что уподобились утиной типизации из динамикодрисни. Мол, не важно, что тип формально реализует какой-то интерфейс, важно только наличие в нём указанных методов.
Вот только на практике неприятно выяснять, что нет нужного метода, только в тот момент, когда уже пытаешься вызвать, потому что до этого нет возможности проверить соблюдение контакта. Спасибо ещё, что это ошибка компиляции, а не "не найден нужный метод!!1" в рантайме.
интересует именно валидация структур после анмаршалинга из жсона. смотрел на gin, но обратил внимание на то, что тамошний валидатор рефлексию использует. может ли это быть узким местом?
искал решения на основе кодогенерации, но таковым смог похвастаться только swagger, а это в моем случае оверхэд - тащить ради одной валидации инструмент, предназначенный для другой цели вообще
Hands-On Software Engineering with Golang.
Anagnostopoulos Achilleas
Прямо, читать — не перечитать! Есть на трекере, но можно и за 50 бачей взять, не так уж и много за такую годноту.
потому что интерфейсы либо настолько общеизвестные вроде райтера/хттпхендлера, что по методам понятно. либо потому что они настолько специализированные, уникальные для проекта, что юзеры и так список методов в голове будут держать, если собираются ими пользоваться. ты лучше пример дай, а то похоже на "никаквжаве!!"
У них фича это нахуярить поскорее тайтлов на хайповые темы и срубить бабла, пока не подтянулись большие издатели (если вообще). Зачастую берут в работу каких-то индусов-чучмеков без крепкого знания инглиша, и потом так и выпускают без особого QC.
Бывают иногда и хорошие книги, но это пиздец лотерея. Короче, эдакий удеми от книжек.
>что поверхностная хуита для ньюфагов
Ну кому как, я так-то нюфаг в го, но после прочтения главы, если она была достаточно интересной, стараюсь копать глубже, разбираюсь, пробую тд. На одних контейнерах застрял на 3 месяца в другой книге, столько всякой хуйни написал что пздц. Даже не представляю какая книга должна быть, чтобы описать все сценарии использования и нюансы отдельно взятой темы. Может быть такая есть, что посоветуете ?
Да нет таких всеобъемлющих книг, наоборот надо искать по конкретным темам.
Только что перелистал эту книжку.
Производит весьма приличное впечатление.
Автор, опять же, грек, а не индус, как у пакта заведено.
Отзывы хорошие, на самом деле, там один плохой, и совершенно невнятный.
Я и по книге Кернигана там видел плохие отзывы, лол.
Короче - спасибо за подгон.
Вот книжка, если кому надо:
https://scanlibs.com/hands-software-engineering-golang-programming/
Вот отзывы на amazon:
https://www.amazon.com/dp/1838554491/#customerReviews
Исходные:
Микросервис, который принимает по ~100 сообщений в секунду из mqtt, далее сообщение обрабатывается каштомный бинарный протокол, ебать его в сраку и по мере обработки в отдельный канал пуляется структура с задачей на запись. Так уж получилось, что нет возможности укладывать 1 сообщение = 1 запись в БД. Так вот, далее в горутине крутится цикл, который разбирает этот канал и пишет уже задачу в БД. БД Postgres, либа pgx. Пулл в ограничен в 10 подключений. Прикол в том, что заняты не более 3-5 подключений и запросы тормозятся. Со временем их накапливается в очереди много. Для запуска запросов использую "изкоробочную" pgxpool.Pool.Exec(). Вроде бы не такой уж маняхайлоад, чтобы тормозило. Кто поопытнее поясните пожалуйста, где я проебался. В своей конторе и спросить некого, го больше никто не знает.
>Что это значит?
Пока обрабатывается сообщение улетает несколько запросов в БД (запись).
>В смысле - чем давать нагрузку? Есть какие-то специальные инструменты, или своё колхозить?
Тулы наверняка есть, но я не интересовался, у меня тут и без того хватает нагрузки. Своё наколхозить за пару минут можно. Цикл, который будет создавать N горутин, в которых будет какой-то запрос в БД, вот тебе и хайлоад на БД, если ты об этом.
> 100 сообщений в секунду
Для постгреса это вообще ничто для insert'a. Какой запрос в бд летит? EXPLAIN ANALYSE что выдает?
У тебя где сообщения стопорятся? Мб твой йоба бинарный обработчик тупо захлебывается? Ты хоть какие-то дебаг данные дай, или нам тебе на кофейной гуще нагадать твой боттлнек?
Эксплейн в пикрелейтед.
> Мб твой йоба бинарный обработчик тупо захлебывается?
Сам первым делом на него грешил, но тут прикол в том, что нужно отвечать сразу же после обработки, я замерил время ответа и нет, с обработчиком всё ок, отрабатывает как положено. Посмотрел каналы, там никаких очередей не образовывается.
В общем, на каждый клиент на связи открывается канал, который ждёт структуры с данными из обработчика, как только приходит, дёргает одну из функций "модели", которая запускает запрос на апдейт/инсерт (пик 2), в функциях sql и аргументы из входящих данных, которые уходят в пик 3. И на этом месте начинается тупняк.
>>1881842
>Ты, кстати, отдельно именно работу пула БД проверял?
Ну как "проверял". Вот статы смотрел, в либе самой (pgx) не ковырялся.
10 соединений забиваются если дёргать pgxpool.Pool.Query() а не Exec(), но на этом дедлокаются.
Запросы простецкие, базовые апдейты/инсерты.
>>1881844
Да вот думаю как раз, что стоит попробовать. Раньше не сделал, потому что лень было транзакцию тягать, флаги слать когда создавать, когда коммитить.
Попробуй индексы захуярить, чтобы шустрее функция бд читала. Тебе нужно запрос оптимизировать, либо мощностей добавлять (т.н. потоков и подключений к бд). У тебя считай 3 запроса и уже на секунду зависло все действо. А их у тебя под сотню в секунду, вот и гг.
> Структура пакета
Достаточно "Здесь версия хттп, дальше хедеры с новой строки, дальше тело запроса/ответа".
> Методы и коды ответа
Знать основные.
> Стратегии кеширования
Похуй.
> Знание части заголовков
Да, знать десяток самых основных.
> Понимание как работают сертификаты
На уровне знания, что это такое и как их скормить http-фреймворку.
Мимонеписалнаэтойпарашеужедвагода
Hands-On GUI Application Development in Go
Есть у кого такая херь или подбное? Интересует fyne.
>fyne
Может кто разбирается в этой шляпе
Как ловить инпут входящий по всему шиднову?
Ковырял когда-то, костыльнул проблему добавлением таппабл инпута на весь размер окна, лол
И может есть какое-то решение для неподдерживающих unresizable и похожие окно-опционные штуки wm?
мимокрок
Там Tappable интерфейс есть, его реализуешь и в методы будет прилетать объект, где можешь координаты пиздить.
Подробнее в одном из их примеров можешь глянуть: https://github.com/fyne-io/life/
Мне кажется, это не очень правильный вопрос.
Тут надо смотреть - что само по себе стабильнее?
Я думаю, что Qt.
https://www.linux.org.ru/forum/general/14754708
По поводу Го - правильный вопрос - что удобнее использовать в Го?
Я ответа не знаю, но, можно посмотреть примеры кода.
Чем брать фанатские биндинги, лучше используй Gp по назначению или не используй.
Пытался тыкать их где-то год назад. Инструкции на гитхабе выглядят просто, но у меня не заработало, оба валились с ошибками, которые не гуглились. Проще на крестах писать, чем ебаться с этим говном.
if err != nil { return nil, err }
вместо
if err != nil {
return nil, err
}
В компании, более-менее известной под брендом "мой офис" требуются разработчики бекенда. Пишем микросервисную распределённую отказоустойчивую корпоративную систему общения и документооборота, а если проще то убийцу ms exchange, ms active directory.
Почитать подробнее можно в блоге на хабре: https://habr.com/ru/company/ncloudtech/blog/
Стек: го, rethink DB, arangodb, grpc, docker. Кодогенерацию любим. Офис в центре ДС, сейчас удалёнка, после ковида обещают частичную удалёнку в каком-то виде.
Вилку мне публиковать запретили, но могу сказать, что в опросах на Хабре вы сможете быть в высших процентилях.
Требования: иметь опыт программирования на чем-нибудь, ориентироваться в го на уровне "мочь внятно рассуждать на темы многопоточности, сетевого взаимодействия и эффективности". Я вкатился прочитав Кернигана Донована и написав пет-проект.
Из неформального могу сказать, что рабочий процесс в конторе поставлен хорошо, то есть нет управленческого хаоса, мнение рядового разраба слышат - то есть если ты аргументированно предлагаешь технологию или подход, то её вредят. Работы много, на годы вперёд.
Пишите в телегу @toorneps, после испытательного срока попилим бонус за найм. Если не хотите пилить - откликайтесь на вакансию на хх.
Отвечу на ваши вопросы.
Какие компетенции нужно иметь в Go(с примерами), чтобы претендовать на работу пикрил и не облажаться в ней?
дайте дорожную карту, рукава я уже засучил
Да, безвозмездный, потому что я делюсь не своими деньгами. При этом в моем отделе, как впрочем и в других, нужны люди. Если ты отсобеседуешься на рядового программиста и пройдёшь испытательный срок, то получишь что-то типа 15к. Не такие деньги, чтобы я не мог с тобой поделиться.
Да, рублей. Чего вы к этому бонусу прицепились, это вообще третьесепенное обстоятельство.
Это не госкомпания. Половиной доли владеет лаборатория Касперского, остальными - другие частные лица.
От джуна и выше, нужны все. Я описал минимальный уровень, если ты продвинулся дальше - тоже возьмём.
https://hh.ru/vacancy/28417466
Вот вакансия.
Когда я нанимался, у меня был опыт серверной разработки в несколько месяцев на одном проекте, где я был единственным сотрудником.
Я был удивлён, но найти гошников, которые отличают односвязный список от хеш-мапы оказалось непросто, поэтому отклонение твоего опыта от описанного в вакансии допускается в значительных пределах.
Скажите, как на вашей хуйне писать что-то не имея, ладно ООП, это соглы. хуйня, но как без шаблонов обойтись?
Как человек с сишным бжкграундом, не чувствую никакого дискомфорта.
Насколько уверенно нужно шарить в Докере и Кубернетесе, чтобы вкатиться на норм позицыю гофера? Если мой верх - это написать докер-компоуз/докерфайл и в общих чертах поднять это всё с каким-то traefik, а кубер я вообще боюсь как огня - я тварь дрожащая или право имею?
Этот долбаеб тебя наебал, в си ошибки еще более примитивны (а точнее это тупо цифры), чем в Go, не говоря уже о их обработке. Также в голэнге ты можешь нагрузить ошибки как хочешь, даже стектрейсы строить, если необходимо. Но да, это не эксепшены и чудес от этой системы не жди, зато работает шустро. Не баг а фича, блять.
>>1891930
Не путай адекватную систему ошибок с поддержкой достаточно всрато реализованных функций в либах (причем даже в стдлиб считай только числами себя в рот ебешь). В го есть интерфейс, с помощью которого ты можешь реализовать любой сложности объект ошибки, хоть уссысь, тот же контекст - это стдлиб в голэнге. Не сравнивай говно с мочой, что в сях, что в го - обработка ошибок это примитивная хуйня, выдуманная в угоду производительности.
Да, я профессионал.
А ты - нет. И не стесняешься это демонстрировать.
Отличная иллюстрация эффекта Даннинга-Крюгера.
>>1889949
>Половиной доли владеет лаборатория Касперского, остальными - другие частные лица.
Не удивительно, что у вас проблемы с поиском специалистов.
>>1891913
Язык охуенен.
А первоапрельским троллингом было твоё зачатие.
> Чем обработка ифами отличается от try-catch в плане громоздкости синтаксической конструкции?
Ты можешь весь main завернуть в try catch и тогда у тебя получится один единый обработчик ошибок. В таком случае, если ты забыл где-то или поленился ошибку ифануть - у тебя улетит все приложение в панику, а эксепшен отловится на самом верхнем уровне по цепи.
Я, если что, не за применение эксепшенов в гоу, просто это самый очевидный из аргументов, которые можно привести. Да и его оспорить можно.
скажите, пожалуйста, го как первый язык - до сих пор плохая идея?
во всех этих ваших статься он топ-1 in demand
>>1879136
Соревнование на самый вонючий пук?
Засрать даже готред. Сосака воистину лягушатник дегенератов с даунами
> Почему? Жесткий кодстайл, хороший тулинг, очень прост в освоении
Если ты предлагаешь тупо для начала обучения - то плохой вариант. Процендурный язык это вообще плохой план. Речь не о том, что го плох, а о том, что после него будет сложно с другими не процедурными языками работать. Наилучший вариант - это вкатиться в С++, не сильно глубоко, а просто ООП изучить и к типам привыкнуть. После плюсов уже любой язык будет проще изучить
>>1892343
>>1892346
Спасибо за ответы
Я, собственно, не очень хочу разводить флуд и прочую срань не по теме
Как-то пытался вкатиться в ГО по курсере от mail.ru, но охуел на первых темах с командной строкой и прочим, так как последние несколько лет сижу на маке по рабочим причинам
Но вдруг захотелось сменить свою работу бизнес-аналитика на ч-тото серьезное и полезное, а возвращаться в РФ не очень хочется блядь
но для вакатыша выглядит гиперамбициозно
> Как-то пытался вкатиться в ГО по курсере от mail.ru, но охуел на первых темах с командной строкой и прочим
Как человек, который перекатился в фултайм го с другого языка - я в первые дни изучения вообще чуть ли не ПТСД словил от GOPATH и подобной дичи. Забей, после этапа фрустрации придет понимание, что это говно и правда говно, но жить с ним можно. Вообще, советую настроиться на то, что мириться придется с очень большим кол-вом вещей в языке, это часть go-way, так сказать. Потом возможно даже будешь с пеной у рта доказывать, что дженерики и правда не нужны, ведь есть генераторы и руки.
На маке с командной строкой всё очень хорошо.
>>1892357
>это говно и правда говно, но жить с ним можно
Это не говно.
Говно - это когда "особенные" решения не мотивированы.
А здесь, кроме как к отступам в 8 пробелов, всерьёз и доебаться не к чему. Ну, после ознакомительного периода, когда говном кажется вообще всё.
Эксепшны - серьёзный мину по производительности, например.
Поэтому их нет. Но, при этом есть средства без них обходиться.
Но, если ты, кроме кроме джавы или питона, ничего не видел, то всё это будет непонятно, да.
И именно поэтому Go совершенно не годится на роль первого языка.
А что годится? Питон, Си, Джава.
>>1892334
Это не ты пару дней назад засрал хуйнёй про Vue весь жс тред?
Твоя жизнь настолько ничтожна, что ты вынужден симулировать самоутверждение на бордах? Так иди в /b - там все твои друзья.
> Говно - это когда "особенные" решения не мотивированы.
Анон, не буду отвечать на твои предъявы, иначе начнем бесполезный срач о том, что конкретно говно, а что не говно и терпимо. Благодарю за понимание. Сколько срачей не веди о голэнге - все заканчивается вкусовщиной и киданием говн друг в друга.
> А что годится? Питон, Си, Джава.
Опять не согласен. Давай по порядку.
Питон - сам язык по нестрогости находится на уровне PHP. Я ни в коем случае не говорю, что питон говно - нет. Питон это отличный скриптовый язык. Но для нового программиста в нем просто не хватает строгости и функционала, нет полноценного ООП (я знаю что есть всякие хаки, но они только введут в заблуждение новичков), нет типизации строгой или хоть сколь нибудь жесткой, очень легко застрять на этапе "пишу процедурщину в методах".
Си - ну он банально слишком примитивный, я все же настаиваю на наличии ООП в первом языке, причем адекватной модели.
А вот насчет Джавы - да, если не сломаешь себе ноги пока дойдешь до первого фреймворка - отличный и очень жирный язык, который научит страданиям строгости, ООП, и выйдешь после него блаженным просветленным умом (номер палаты может красивый выдадут. Шутка).
Питон более вменяем, все же. Чего там в питоне нет, приватных методов? А нахуй они нужны? Единственное предназначение - жестко контролировать корпоративных макак.
Начинать можно и с динамической типизации, и со статической. Главное взять вторым язык с другой типизацией, чтобы потом не начинать унылый вой про скриптопараши или безумную избыточность и связывание рук программиста в какой-нибудь джавохуйне.
Адепты ООП заебали читать свои мантры.
Нахуй оно не всралось, из всего ООП по-настоящему нужен только полиморфизм, который можно получить и другими способами(интерфейсы, трейты, тайпклассы)
>Эксепшны - серьёзный мину по производительности, например.
Не такая серьёзная. А если учесть затраты на то, чтобы обойти отсутствие эксепшенов, то вся производительность улетучивается.
Эксепшены в конкурентных задачах штука сложная, конечно, но современный прикладной язык без эксепшенов это какой-то нонсенс. Вот и остаётся, что узкая область low level задач.
Можно писать, в Си тоже нет исключений. Но только у Go есть явный акцент на системные вещи, на сети, файлы и т.п., где ошибки штатная вещь и актуальность их обработки очень велика.
> Вот и остаётся, что узкая область low level задач
> чтобы обойти отсутствие эксепшенов, то вся производительность улетучивается
> современный прикладной язык без эксепшенов это какой-то нонсенс
> у Go есть явный акцент на системные вещи, на сети, файлы
Что за чушь я прочитал?
> проще
Легко:
a_result, err = a();
if err != nil { return nil, err }
b_result, err = b(a_result);
if err != nil { return nil, err }
c_result, err = c(b_result);
if err != nil { return nil, err }
d_result, err = d(c_result);
if err != nil { return nil, err }
e_result, err = e(d_result);
if err != nil { return nil, err }
Ыыы слажн:
try {
return e(d(c(f(a()));
} catch (err: error) {
throw err;
}
f(
Да вон >>1893656 сам погляди, это же типичная монада Either/Error ( https://hackage.haskell.org/package/base-4.14.1.0/docs/src/Data.Either.html#line-155 ), просто без пидорских абстракций
>>1892659
>>1876438 (OP)
Создали микроконфу двачеров старая мертва, вкатуны, перекатуны, и им сочувствующие - добро пожаловать, снова: https://t.me/golang2chgayparty
func main() {
runtime.GOMAXPROCS(1)
done := false
go func() {
done = true
}()
for !done {
}
fmt.Println("finished")
}
Добавлю, что если вместо цикла с !done проставлю time.Sleep - работает всё как я и ожидаю, ибо слип блокирует выполнение главной горутины. Какого хуя цикл не блокирует то блять маму ебал того роба пайка в анус (вроде же цикл без условия как раз блочит, нет?).
Моя догадка: таки цикл с условием нихуя не блокирует. Но даже если так, какого хуя горутина КОНКУРЕНТНО на одном ядре не выполняется, они же должны хоть тыщами штук летать в однопоточном режиме, грубо говоря.
>>1893988
Планировщик, который переключает рутины, делает это не абы когда, а в ключевых точках. Одной из таких точек является вызов функции и возврат из нее, как в случае с тацм.слип
Цикл - не такая точка. Поэтому планировщик просто никогда не проснется чтобы переключить рутины.
Одним из ответов на вопрос является добавление в цикл вызова планировщика принудительно
Вот, например если так написать, то обе горутины выполняются одновременно: https://play.golang.org/p/k4ApVZeZ9UJ
Так почему тогда код выше вытворяет такую хуйню? Помогите аноны, уже мозг болит.
> начни новый день с разбора работы планировщика.
Так ты объясни лучше, я в общих чертах знаю как он работает и про точки тоже знаю. Но я бы все понял, если бы код работал одинаково с GOMAXPROCS(1) и GOMAXPROCS(>1), но при одном ядре горутина тупо никогда не вызывается, хотя по идее должна. Объясни этот момент.
Вопрос устарел с выходом 1.14 https://golang.org/doc/go1.14#runtime
>>1894028
>По логике результат кода не должен отличаться от GOMAXPROCS(2)
Должен по крайней мере отсутствием возможности перекинуть горутины между M тредами, например
Задачи идут в обычное queue, у тебя на нулевом индексе уже выполняется мейн, горутина пошла на первый индекс и ждёт своей очереди. Поскольку у тебя бесконечный цикол, M никогда не освободится от уже начатых вычислений, пока ты сам не скажешь ей свичнуться на следующую горутину Gosched'om (или не обновишься до 1.14+, где компилютор научился распозновать это дерьмо)
>>1894061
Это вообще никак не относится к твоей проблеме
С первой ссылки нашёл одну из тех более-менее содержательных презинтаций, случайно тыкнув - попал ровно на такой же пример со старой версии. это судьба
https://youtu.be/4U3EaVufuW4?t=792 ~13:14
> Должен по крайней мере отсутствием возможности перекинуть горутины между M тредами
Т.е. в голэнге переключение горутин с одним ядром - работает иначе, чем с несколькими? Т.е. если одно ядро - то переключается только на точках, а если два ядра - то можно и не только на точках переключиться, а и с циклом? В чем логика?
> или не обновишься до 1.14+, где компилютор научился распозновать это дерьмо)
Я тестирую это на 1.14, в плейграунде как раз она, и ничего не распознается само с одним ядром
>>1894103
Долбаебина, вопрос не в том почему не вызывается вообще, вопрос в том, почему не вызывается с ОДНИМ ЯДРОМ. Какого хуя вообще в голэнге в таком случае планировщик тупо бездействует?
>>1894105
> Но в случае с одним ядром он решает, что основная рутина важнее
Это ведь пиздец, нет?
Во первый они выполнятся не одновременно, а последовательно, если что. Вторая горутина отрабатывает следом за первой, если бы они выполнялись одновременно, то могли бы быть ситуации когда "second done" выведется раньше чем "first done".
Во вторых >>1894022 этот не прав, при вызове функции горутина не переключается, иначе вот это https://play.golang.org/p/4ICORpcOEK5 выводило бы "finished". Переключение контекста происходит во время системных вызовов, time.Sleep как раз системный вызов.
В третьих это работает так, на го 1.13 и раньше, в 1.14 сделали вытесняющую многопоточность, и если ты запустить не в go playground, а на своем локальном компе с go 1.14+ все отработает даже с runtime.GOMAXPROCS(1)
> Во первый они выполнятся не одновременно
Да я знаю, конкурентно они выполняются, нет задержки в 2 секунды между первым и вторым сообщением, т.к. отсчет начинается примерно в одно время.
> В третьих это работает так, на го 1.13 и раньше, в 1.14 сделали вытесняющую многопоточность
Я это знаю, там и с for {} можно было переключение триггерить, если не ошибаюсь.
> если ты запустить не в go playground, а на своем локальном компе с go 1.14+ все отработает даже с runtime.GOMAXPROCS(1)
Так в плейграунде ведь go1.14.13
>Т.е. в голэнге переключение горутин с одним ядром - работает иначе, чем с несколькими? Т.е. если одно ядро - то переключается только на точках, а если два ядра - то можно и не только на точках переключиться, а и с циклом? В чем логика?
Ты ни одного артикуля не прочитал?
Рантайм раздупляет по процессу на каждое ядро P, кажое из которых условно пакуется в более абстрактный тред M. Между М могут перекидываться горутины
Если у тебя один "процесс-ядро" - будет один М, которому распределять горутины некуда
>Я тестирую это на 1.14
Ну хуй знает я посмотрел гоплейграунд и вправду дедлочится хотя рантайм версия пишет 15.6
На моей машине 15.3 всё работает, может онлайн штуки запускают в режиме интерпритатора - хз
Тайм слип это другое, как минимум потому что нижний слип у тебя ожидающий канал
Короче переключился на линь, ибо впизду, тоже версия младше плейграундовской корректно и ожидаемо выполнила. Короче понятно. Плейграунд как всегда всех обыграл, ебаный роб пайк и команда, сука.
>>1894134
Чмошник, блять, и где твой бог теперь?
>>1894141
Да я знаю как должно работать, я знаю и читал как шелдуер назначает горутины и т.д. (мб не досконально, но достаточно, чтобы ахуеть с того, что происходило в плейграунде). То, что выдает на локальной машине - для меня ожидаемо и понятно. Какого хуя это все ведет себя так в плейграунде - для меня теперь большой вопрос.
сука, как они могут выполняться конкурентно, если контекст не переключается?
> In computer science, concurrency is the ability of different parts or units of a program, algorithm, or problem to be executed out-of-order or in partial order, without affecting the final outcome
Тут же все выполняется по порядку
>try {
return e(d(c(f(a()));
} catch (err: error) {
throw err;
}
try {
return e(d(c(f(a()));
} catch (err: error1) {
throw err;
}
catch (err: error2) {
throw err;
}
catch (err: error3) {
throw err;
}
catch (err: error4) {
throw err;
}
catch (err: error5) {
throw err;
}
Пофиксил, не благодари
> с появлением кора Go больше не нужен.
Но у шарпистов даже зеленых тредов нет, о чем вообще речь? Сейчас бы сидеть руками хуярить многопоточность и следить, чтобы твоя зависшая хуйня не крашнулась из-за утечек памяти, пытаться менеджить л кэши проца и просто анально ебать себе анус, когда мог бы просто написать ключевое слово 'go' и жить не тужить
> Вкатывайся в C#
Когда из него все потихоньку выкатываются? Даже по достаточно демократическому tiobe - шарп сосет с проглотом и теряет в популярности
Шарп - это пережиток целой эпохи. Его участь - это участь Java, вот только в случае Java там JVM обеспечила ей непоколебимое закрепление на рыночке, а в случае шарпа - кор это как последнее издыхание, в попытке выползти из могилы. Мелкософты очень поздно одумались.
А гошка вообще другие задачи решает
Узнал, что ерроры оказывается можно враппать, лол
Не вижу каких-то проблем с интерпретацией еррора как идиом монады пока писоешь на го, но кому это нужно не знаю
https://dpaste.com/88YBCXS6Z
Объясните, зачем нужны всякие green threads, goroutines и т.п, если есть обычные ядерные треды? Экономия на спичках переходах в kernel mode?
И сука, в каждом уголке интернета, где всплывает подобный вопрос, звучит дибильный аргумент про размер стека. Какая вообще, блять, разница, сколько у тебя выделено под стек, если везде on-demand paging, а 2^64 байт адресного пространства - это, мягко говоря, неисчерпаемое количество.
Горутины это абстракция над ядерными тредами.
Горутин можно дохуя наспавнить и не потерять в производительности - за количеством ядерных тредов по которым распределяются горутины следит рантайм. Ядерные треды кушают немного больше памяти и значительно тяжелее переключаются
Но он память может эффективно шарить, тредам c этим сложнее. Алсо, вроде стэки тредов не могут потом обратно выделенную память отдать.
Жаль что я устройство линукса понимаю очень смутно.
Неплохой вопрос чтобы унижать вкатывальщиков на собесах, если подумать.
>>1895943
>>1895924
пиздец, че за шарписты и сишники тупые пришли, пиздуйте хоть матчасть изучите
Прфоиты в минимизации реальных context свичах на ядрах, минимизация тача эл кэшей проца, возможность создать в десятки тысяч раз больше виртуальных потоков, огромная скорость создания и уничтожения горутины, жирный оптимизированный планировщик, который следит за всеми деталями и производительностью и т.д. и т.п.
Дохуя профитов, на самом деле. Но качественно написанный мультипоточный код на других языках может работать и быстрее, но он будет несоизмеримо более сложен в реализации и читабельности.
Суть скорее в том, что цена/скорость/производительность в сумме дают профиты. Если не нужно обрабатывать гигатонны трафика а-ля главную страницу поиска гугла - то большинство задач решает.
В конечном остатке плюсы и си будут в любом случае быстрее, если отбросить кривые руки разрабов и дать время на хорошую реализацию.
>жирный оптимизированный планировщик, который следит за всеми деталями и производительностью
Маркетинговый буллшит
>возможность создать в десятки тысяч раз больше виртуальных потоков
Вот я и интересуюсь, если это правда, то откуда это берётся.
>огромная скорость создания и уничтожения горутины
Маркетинговый буллшит Так ли долго создаются системные треды? И опять же, если это всё так, то за счёт чего это достигается? Почему глупые разрабы ядра не смогли это всё сделать в ядре?
> Маркетинговый буллшит
Нет. Шелдуер опен сорсный, как и весь гоу - пиздуй читай, просвящайся.
> Вот я и интересуюсь, если это правда, то откуда это берётся.
Из-за того, что в голэнге не кооперативный preemptive планировщик - виртуальные потоки, которые пинают хуй, но не явно (если явно - то в натив треде будет свитч, но чаще бывает не явный стейт Waiting, а обычно все висит в Executable). Плюс есть дохуя оптимизация типа work stealing, и лоад балансер, шелдуер следит, чтобы горутины как можно реже перегонялись между реальными тредами, чтобы не тачить кэши в проце, и много чего еще. Почему это не реализовано на уровне ОС? ОС не может полностью предугадать какой машинный код будет выполняться, грин треды - очень специфичная хуйня, по сути ты делаешь фейковую многопоточность на одном реальном ядре. Если сам голэнг знает когда ему лучше переключить контексты (например когда знает, что идет вызов функции и есть достаточно времени), то ОС придется все это дополнительно чекать, предугадывать и т.д. Правильная реализация грин тредов зависит от исполняемого окружения, грубо говоря.
> Так ли долго создаются системные треды?
Проблема не в создании, проблема в том, что памяти они отжирают дохуя при создании. Я даже хз понимаешь ли ты хоть половину от того, что я пишу, но попробую пояснить. Есть по сути 2 вида операций - CPU-bound (т.е. вычисление, io и в таком роде), а есть нетворк баунд (ну и не только). Если ты сделаешь 5 параллельных запросов в сеть на реальных потоках в сеть - то скорее всего будет оверхед на контекст свитчи, выделение памяти (но тут есть исключения, например в некоторых процессорах есть отдельный network для таких операций, голэнг кстати умеет горутины туда кидать тоже) и т.д., а ведь это простейшие операции. Если ты их КОНКУРЕНТНО на грин тредах распределишь - то ты выпустишь эти 5 грин тредов, и сможешь забить на них хуй и занять процессор более полезной работой, пока ждешь пересылки битиков по проводу и ответа с той стороны.
>Есть по сути 2 вида операций - CPU-bound (т.е. вычисление, io и в таком роде), а есть нетворк баунд (ну и не только)
Network - это и есть IO.
Всё, что ты пишешь, на уровне ядра работает так же. Ядро не оставляет на процессоре поток, который заблокировался в IO syscall'е.
>хоть они и дешевле
В этом то и вся соль. Они блять на много дешевле, ебаный свич между потоками ОС стоит 12 тысяч инструкций, в то время как планировщик Го, переключает горутины за 2 тысячи инструкций используя один поток, который всегда занят и не простаивает на свитчах.
Эх, ленивые нынче люди пошли, или просто не очень сообразительные?
1) https://habr.com/ru/post/478168/
2) https://habr.com/ru/post/489862/
3) https://habr.com/ru/post/502506/
Читать именно в таком порядке. Перевод - говно полное, но для общего понимания сойдет, можешь поискать на eng. Плюс гугли понятия в вики.
> Network - это и есть IO.
Да, промазал тут немного
> Всё, что ты пишешь, на уровне ядра работает так же
Нет. На уровне ОС - происходит конкурентная работа различных процессов, но это не гарантирует конкурентную работу твоего кода, ты либо распределяешь выполнение по потокам реальным, либо сосешь хуй. Грин треды для того и созданы, чтобы минимизировать оверхед реальных на простые задачи. С тем же нетворком - быстрее и невероятно эффективнее (что по памяти, что по операциям по свитчу стеков с хипами) будет наспавнить тыщу горутин, ибо смена контекста в таком случае просто ничтожна, тогда как на уровне процессов с потоками - потеряешь много памяти и переключения займут существенно больше процессорного времени.
Гринтреды - это по сути просто слой абстракции над натив тредами и их оптимизация конкретно под язык.
> Эх, ленивые нынче люди пошли
Если что - те 3 статьи немного устарели. Одно из главных изменений после 14й гошки - планировщик больше не кооперативный, если раньше шелдуер "влезал" в процесс на определенных сейф поинтах - ключевое слово go, блокировки всякие, цикл гц, сисколлы, то в новой версии он уже влезает с определенной переодичностью и шустрее. Раньше были проблемы с узкими циклами (долгие или даже бесконечные циклы, в которых не было возможности встроиться шелдуеру), то теперь это все работает адекватно и думать о такой хуйне больше не нужно.
Вот тут подробнее про новую реализацию:
- https://medium.com/a-journey-with-go/go-asynchronous-preemption-b5194227371c
- А тут оригинальный док по предложению с изменением: https://github.com/golang/proposal/blob/master/design/24543-non-cooperative-preemption.md
В том то и дело, что я указал в каком порядке читать. Сначала ОС, потом го<1.14 и в конце объяснят, как именно поменялся планировщик в го 1.14. По поводу планировщика, сам вроде разобрался, но не тестил. Как по мне, програмст сам должен решать, нужно планировщику переключать свитч, или не нужно.
> Как по мне, програмст сам должен решать, нужно планировщику переключать свитч, или не нужно.
В голэнге решили эту абстракцию полностью закрыть. Там даже в доках всегда пишут, что нужно разрабатывать так, будто нет никакой гарантии какая из горутин запустится первой, кроме main и в таком роде. Имхо этим как раз горутины в го и удобны - очень простой интерфейс без большого кол-ва эдж правил. Тут скорее не о производительности, а о скорости разработки мультипотоковых сервисов.
Дедлок NN постов назад происходит из-за фейковремени
Покажи хоть одно онлайн сдк, где можно крутануть сервер\фс импортнув проект по ссылке на гитхаб
>>1897775
>Syntax highlighting is juvenile. When I was a child, I was taught arithmetic using colored rods
>(http://en.wikipedia.org/wiki/Cuisenaire_rods). I grew up and today I use monochromatic numerals.
Ну и мочебекграунд отдающий дань уважения к олдовым проектам
Ничто не мешает прикрутить какую-нибудь хрому для локального плейграунда. Кода выйдет от силы на строчек 50 включая фронт
В vscode гошка как-то хуево подсвечивается, слишком монотонный текст.
Я не мог понять, что с ней не так, почему тяжело бегло читать, а потом понял, что слишком мало конструкций акцентируется и/или акцентируется неудачно. Начал перебирать темы, где-то акценты правильные, но цвета вырвиглазные, где-то наоборот. Остановился на Monokai Dimmed. Но все равно, хрень какая-то. Раньше в редакторах с темами ситуация как-будто получше была.
Я хз, это проблема вс-кода (до этого на саблайме сидел) или проблема схем для го. Короче, может я не один такой и че посоветуете?
Что скажете насчёт этого сайта? https://go101.org/article/101.html
Норм?
Бля, вот лол https://groups.google.com/g/golang-nuts/c/hJHCAaiL0so/m/kG3BHV6QFfIJ
Это типа официальная позиция динозавра из 80-х (https://en.wikipedia.org/wiki/Sam_(text_editor)), который считает, что подсветка не нужна.
И тут же находятся сектанты, которые уже как свое мнение выдают, что да, так удобнее, ничего не отвлекает от кода.
Пиздец. Это просто показательный факт, который иллюстрирует всю суть Go - вот он такой во всем. От него веет пет-проджектом и 90-ми. Сырой, своеобразный, странный, то тут то чего-то не хватает. Потому что это не язык для индустрии, а язык-инструмент конкретного человека. Как вот это поделие https://www.parser.ru/, только зафоршеное корпорацией.
Нет, просто голэнг в основном используется на жирных проектах с кучей технологий и микросервисами, где джуну будет по сути невозможно ничего сделать, если он не будет иметь хотя-бы базовое представление о всем этом. Поэтому в гошку проще из других более общенаправленных языков перекатиться, когда ты уже знаешь много всего помимо самого языка.
>>1898806
Да дохуя их, на том же хх вакансий гопетухов всего в два раза меньше питхона, а это дохуя для низкоуровнего языка, который по факту и юзается только под определенные задачи.
Кстати, оголтелые фанаты ГОвна - точно такое же деграднутое быдло как и вы, возводят в культ язык, пытаясь оправдать очевидные минусы и с трудом поддающиеся критике. Ждем дженериков и не пищим, пидорасы.
>>1898990
Так речь о читаемости или просто как выглядит? Я пробовал гошку немного и на нем я в разы быстрее напишу тот же код, что и на расте ток на расте, если не проебусь - будет сильно быстрее в большинстве случаев, раст очень вербозный, сахара я там не заметил чтобы прям много, я бы назвал срвнение раста с го и сравнение джавы с питоном - примерно одного разряда по контрасту языков. Но я не спец в го, ток пару сервисов на коленке писал, но вроде на нем большие проекты и не пишут я бы себе мозги вынес, если бы пришлось на расте писать то, что пишут на питхонах
Под всратостью я подразумеваю решения на уровне синтаксиса, я сам не эксперт в го, думаю выбрать его как альтернативу для написания бэкендов. Просто сейчас смотрю что в го нет таких простых вещей как объявление обычного энума или функциональных выражений для тех же коллекций. Мне это кажется очень странным для современного языка.
> Мне это кажется очень странным для современного языка.
Согласен. Уверен придет со временем, после предстоящей революции дженериков. Я вообще не понимаю фанбоев голэнга, которые везде орут НИНУЖНА. Я бы еще понял, если бы это отсутствие сахара консистентно бы было и ровным слоем размазано, так ведь нет - в одних местах какой-то лютый сахар, в других ты как долбаеб чуть ли не на уровне битов оперируешь. Я думаю со временем этот нищий майндсет уйдет, ибо го популярность набирает и им уж хочешь не хочешь - придется и опциональных параметров ввести, и что только еще.
Мимо 2 года пилю микросервисы с миллиардами рпс в микро секунду на голэнге и иногда вляпываюсь в немножечко питона
Считается ли в Го нормальным использовать горутины с каналами в однопоточном коде - в качестве генераторов?
> в качестве генераторов?
Например? Ты про аналог yield? Чисто алгоритмически - да, будет работать. Главное не забудь сделать механизм высвобождения горутины, закрыв канал/nil, иначе память утечет. Но лучше реализуй через замыкания и анонимку, ибо плодить горутину и обеспечить её уничтожение - лишняя забота и код.
someFunc() (SomeStruct, error)
или
someFunc() (*SomeStruct, error)
> когда стоит передавать/возвращать из функции указатель, а когда просто структуру.
Очевидно, когда хочешь, чтобы вернулся указатель или копия. Для экономии памяти стоит вернуть ссылкой.
> Например что лучше
Если кратко - когда ты пишешь pizda := &Somestruct{} внутри метода, ты создаешь переменную пизда, которая хранит в себе адрес структуры. Вернешь ты из функцию не структуру, а адрес на неё. В языках типа плюсов - ты соснешь хуйца, в голэнге за тебя дядя Роб Пайк и команда позаботились, что ты адрес не потеряешь после окончания этой функции. Соответственно если отдаешь адрес - компилятор тебя обезопасит отпроебов, плюс ты передашь совсем немного информации, скопируется только пизда с адресом, а не вся структура, структур как раз улетит в хип на хранение, так сказать. Если же ты напишешь pizda := Somestruct{} и вернешь значение - то у тебя получится 2 копии структуры (заметь, если у структуры есть поля типа ссылок - они не скопируются, т.к. ссылка будет вести на область в памяти, грубо говоря), ты немножко потеряешь на памяти и сборщик мусора потом выебет тебя в жопу сам удалит копию, которая осталась в контексте функции.
Короче если проще - зависит от твоей цели, если нужно именно скопировать - передаешь так, если нужно оставить одну "копию" и просто вернуть из функции ссылку на неё - возвращаешь ссылку. Тут нет "правильного", зависит от того че ты хочешь.
Вот код, если произойдет ошибка, то defer сработает и разлочит мьютекс. Но сам вызов анлока мютекса в defer меня напрягает, как будто что-то неправильно и следует просто сделать через return err.
https://play.golang.org/p/urb25xa5UE1
Спасибо за подробный ответ, но я немного про другое скорее спрашивал. Я про то, что если возвращать ссылку, то переменная гарантировано будет в хипе, что не очень то и быстро, а вот если возвращать саму структуру, то может и на стеке выделяться. Так вот есть например функция маппер, которая принимает одну структуру, а вовзращает другую, то есть если вернуть не ссылку, то у тебя будет две этих новый структуры. Кажется, в чем проблема, возвращай всегда ссылку да и все, НО вот что меня смущает:
- хз, что быстрее, два раза выделить память внутри стека горутины, или один раз в хипе
- гонял бенч, и вроде как получилось что возврщать ссылку быстрее, уже не помню результаты, но время работы gc тоже замерял
- один голанг-архитектор, говорил что лучше возвращать структуру по значению, если она не сильно вложена и нет каких то тяжелых ресурсов, которые нельзя копировать
Вот поэтому мне интересно, не долбоеб ли я, что всегда по ссылке возвращаю. Ну и да, пассую я тоже часто по ссылке, проблема в том что значение может мутироваться?
>>1899925
Я тут немного побайтоебю, defer имеет задержу перед вызовом, совершенно мизерную конечно, но лучше вызывать явно, если есть возможность. В данной функции ничего плохого не произойдет, но копипаста такого мьютекса может привести к тому, что сам мьютекс используется не эффективно, разлочивается не сразу когда появилась такая возможность. Желательно чтобы блокировка мьюткса была максимально короткой
>>1899935
В целом согласен, сделал через panic так как решил поэкспериментировать с recover. Вроде бы это даже удобнее чем возвращать ошибку.
https://play.golang.org/p/tnD9Hki3IBR
Как угодно можно назвать, еще есть context, тоже ознакомься, в стандартном серваке го и большинстве библиотек он находится в реквесте, соответственно можно его учитывать и обрывать долгие и затратные операции, если на том конце юзер оборвал соединение и в таком роде. В мелких проектах на это все похуй, и даже похуй на горутины, которые в воздухе навечно заблочились, но когда твой сервис обрабатывает большое кол-во запросов (не только сетевых, это может быть и твоя библиотека тупо) - то через неделю ахуеть от полуживого ПО будет очень неприятно. GC их не во всех вариантах сможет определить и уничтожить самостоятельно.
> Аноны, насколько быстро можно вкатиться в Go после Python?
Месяца за 2, если задротить. Синтаксис простой, но много мелочей с типами, конкуренси, обособленными патернами, стдлибом. Но зависит от тебя, если ты на питоне crud для веб сайтиков писал - будет сложнее, а если что-то дельное делал с различными технологиями - другой вопрос.
>type Service interface {
>func AddSomething(request Request) (Response, error)
> ...
> }
Все, что я видел, насколько я понимаю, парсит только тело запроса и аргументы в лучшем случае, а вот с ответом - пошел на хуй, как говорится, какой-то generic response со строкой вместо нормальной структуры ответа.
В айти вошёл давненько, но есть желание пересесть поближе к разработке. В связи с этим вопросы: стоит ли влезать в го, чтобы потом претендовать на джуна?
Так ли велИк запрос на гошников сейчас?
Во многих вакансиях обязательное требование от года разработки на Java/Python/PHP/C#. Это реально нужно?
Скиньте оригинал второго комикса из оп поста.
>Что такое реально нужно?
Можно ли вкатиться в го-джуны без опыта вебни на других языках?
>Открой hh и посмотри сколько там вообще джун вакансий
Это понятно. Картина на хэхэ не всегда репрезентативна, последнее время там один мусор публикуют. Интересует реальное положение дел.
Ну смотри, мне все таки кажется, что по хх можно делать какие то выводы. Я вот нашел там 0 ваканский для джуна
Там где требуется опыт коммерческой разработки это вакансии на мидла, и кабан рассчитывает что ты уже что то умеешь и тебя не надо учить, сам то синтаксис не сложный. Мне кажется нужно отталкиваться от твоего опыта, если он довольно близко к разработке, то думаю вкатиться можно будет
От года разработки это скорее чек на адекватность, если покажешь что ты не зеленый джун, а знаешь все инструменты и вообще как все устроено, то возьмут легко или нет
имхо на жабу вкатиться легче
шел 2021 год, долбаебы все еще пытались вкатиться через вакансии "junior". Для вас специально повторю - джун != трейни. Без знаний и опыта (т.е. пет проект небольшой) вы не вкатитесь никуда. А в голэнге прям джуны не нужны, ибо нужен релевантный опыт по всяким очередям, мониторингу, докеру и всему вот этому.
Двачую. 100% рабочий план для вката в программирование за деньги на любом языке (не благодарите): изучаешь язык на минимально рабочем уровне, изучаешь некий минимальный набор востребованных сейчас технологий, делаешь от одного до бесконечности бесполезных проектов возрастающей сложности с использованием того, что выучил. Готово, вы погромист.
Так все и есть. Хватит парочки пет проектов. Главное на актуальном в языке говне. Проблема в том, что вкатуны и этого не понимают.
>>1902851
При чем здесь это? Кидать отклики нужно везде, где четко не прописано прямо в тексте требование коммерческого опыта и не ищут спецом middle+. Вот и весь секрет. А то, что долбаебы находят с трудом 3 вакансии идеальных с "без опыта", думая, что это все, куда они могут отозваться - это путь долбаеба. Рынок гораздо проще устроен. Просто некоторые дурачки типа тебя привыкли, что подготовился к зачету - сдал на 5 и заебись, в реальном мире так не работает, все работает куда проще, по релевантному опыту и пользе, которую принесешь.
Эй, дайте нормальных книжек для вката, то что там есть это 2012 год. И не надо мне 10 книжек, одну самую нормальную дайте, что за мода накидать говна, мол смотри какой выбор.
Серьезно, блять, посоветуйте актуальную книжку для вката.
Да, меня. Чем тебе не нравится ответ? Книжки в основном устаревшее говно, если ты будешь читать в РУ варианте - то еще более устаревшее. Книга намного хуже офф документации, плейграунда и блога го (в нем почти все концепты с примерами разобраны). Книги можно советовать только по конкретным темам, в которых ты хочешь углубиться лучше, например по Concurency. Читать книги именно по вкату в язык - пустое и глупое занятие.
так понятнее или ты дурак?
Наверное каждый хоть раз обжигался о
for k, v := range foo {
go func() { run(k,v) }()
}
>или что-то похожее, где "захватывается" значение в кложуре. >Есть даже пропозал, что давайте от этого уйдём (в го2, когдатотам) https://github.com/golang/go/issues/20733
>Там забавный комент добавили, может слышали, Let's Encrypt недавно откатили 3М+ сертификатов. Угадайте из-за чего)))
https://github.com/letsencrypt/boulder/pull/4690/files#diff-d02067a9f9a2bed1110fd4e98641c2effcf5d1d5f18461e35d6ac1535f6e2c21L1411-R1414
https://t.me/oleg_log/3984
> вот отвечаете по существу вроде бы, но столько этого вашего блядь раздувшегося самомнения, блевать хочется. самим от себя не противно?
Это я один отвечал. Просто я заранее в атакующую позу встаю, т.к. общее мнение среди двачеров которые естественно нигде кроме веб студии не работали, что в айти вкатиться неимоверно сложно. А на деле же на личном опыте и опыте собеседований и общения с другими людьми - все в разы проще, просто многие совершают банальные ошибки типа отсечения вакансий, где стоит метка "1-3 года опыта" или везде, где не написано "готовы взять за еду", ну и еще многие просто тупые. Скорее всего щас опять набежит какой-нибудь очередной пояснятель про айтипузырь и в таком роде, это рак программача, эти шизики даже бе засирают этими тредами.
Чувак, это твое мнение. Я лично не считаю официальные гайды хорошими, они сумбурные, размазаные, сухие и неполные. Брошюра в виде последовательного гайда была бы гораздо более эффективной.
Что касается блога, то это вообще не в тему, читать эти статьи на этапе вката бессмысленно.
И да, го не первый мой язык, я примерно понимаю что такое хорошая документация и какова стоимость входа.
Если шо, я из плюсов прикатился, у нас там есть std::variant который с этим отлично справляется:
https://onlinegdb.com/rJBKmxVAv
Я в примере для простоты тип указываю явно, но есть возможность через визитора это делать обобщенно и не думать, какой у меня тип в конкретном объекте. Вот хотелось бы что-то подобное и чтобы оно не очень костыльно было (костыльно я и сам могу)
Никакого вредоносного кода нету же.
https://github.com/emersion/go-autostart
> А че в голенге по сокрытию типов? Если мне нужно гетерогенное хранилище для какого-то ограниченного (небольшого) набора типов, можно это как-то без торчащего наружу interface{} запилить? Вроде рефлексия есть, должно быть как-то не сложно информацию о типе сохранить и восстановить ее, но шото сходу не нашел способа. То я хочу иметь какую-то структуру, которая инкапсулировала бы данные и информацию о типе переданного ей в конструктор объекта и по необходимости типобезопасно собирала бы мне назад переданный объект, при том, желательно, с минимальным оверхедом.
А теперь всю эту хуйню напиши в двух словах.
> То я хочу иметь какую-то структуру, которая инкапсулировала бы данные и информацию о типе переданного ей в конструктор объекта и по необходимости типобезопасно собирала бы мне назад переданный объект, при том, желательно, с минимальным оверхедом.
Т.е. ты хочешь дженерики с union типами. Боже, столько расписал, пыжился, а в итоге ничерта не понятно что ты хочешь.
Зачем ты столько конкретики и специфичной терминологии из своих плюсов приплел? Variant - общеизвестная хуйня. В го нет такого, unions появятся в дженериках, которые скоро подвезут
> Я в примере для простоты тип указываю явно, но есть возможность через визитора это делать обобщенно и не думать, какой у меня тип в конкретном объекте. Вот хотелось бы что-то подобное и чтобы оно не очень костыльно было (костыльно я и сам могу)
От этого не зря отказались в шарпе, джаве(хотя тут даже юнион дженериков нет) и других нормальных языках. Этот функционал (именно variant, а не юнион) это лютый трудночитаемый костыль, который добавляет в код сложности на ровном месте, при этом используется только в крайне редких случаях, в которых скорее всего есть логическая ошибка программиста, который решил такое применять.
Отучайся от такого говна, плюсы за это и не любят, что все подряд понапихали, даже вот такие узкие вещи, и теперь язык - монстр какой-то получился.
Ну да, по своему опыту. А есть вопросы? Веб студия нацелена на то, чтобы побыстрее сделать да забыть, лол. Вместо монги какой-нибудь въебешь по быстрому sql, вместо редиса - вьебешь кеш через БД, если вообще не лень будет, на scalability вообще забьешь хуй, ведь не надо да и запарно, о докере вообще можно забыть - по ssh за пять минут чтобы просто работало и можно было поскорее сдать проект. В нормальной фирме, даже ПХП формошлеп будет выкладывать свой код через настроенный пайплайн, писать тесты, будет обязательный код ревью и АГИЛзапрещенная в РФ организация, дадут пощупать новые технологии, какой-нибудь эластик подрубят, rabbitmq, еще и мониторинг с графаной да прометеусом и логсташем. А это уже пиздец какой буст, тебе и код писать придется нормальный, иначе на код ревью засмеют. Веб студия - это стагнация тебя, как специалиста.
> кидает ссылку на пакет в гитхабе, с которым ошибка
> Где ещё можно спросить кроме этого треда?
Очевидно - создать issue и спросить у создателя пакета, мы то откуда знаем? На проде никто в автозапуски винды не кладет гошные сервисы, лол, это либо systemd на линухе, либо кубер/докер с авторетраями. Я не думаю, что здесь кто-то вообще на винде с голэнгом работает.
Да лан, ничего забавного. Гошка полнофункциональна на винде, просто мало кто пишет именно под неё, ибо нинужно, но я писал достаточно сложные штуки с opengl на гошке и на винде все прекрасно заводилось, главное заранее определить, что будешь поддерживать винду, т.к. сторонние либы могут без поддержки быть и ток с линуксовыми и макосевыми сисколлами работать.
> Бесполезная хуйня для умственно отсталых, ты хотел сказать.
Абсолютно похуй. Линукс стоит на серверах и большинство ПО, соответственно, для разработки и удобства - заточено именно под линукс, это рабочий инструмент. Для игр и виндоПО (хотя я в них не играю) у меня есть дуалбут винда. Зацикливаться как ты на одной ОСи как школьник - это глупо, и ты сейчас на весь тред показал свою некомпетентность и тупость.
variant - это конкретная реализация вариантного типа, а юнион - способ группировки в дженериках
>>1903949
> это даже не пропозалы, и никаких гарантий нет
Пайк раньше вообще еретиков сжигал одним взглядом за это слово. Обещают в 1.18 уже завезти:
>Generics
> The next feature on everyone’s minds is of course generics. As we mentioned above, we published the latest design draft for generics back in June. Since then, we’ve continued to refine rough edges and have turned our attention to the details of implementing a production-ready version. We will be working on that throughout 2021, with a goal of having something for people to try out by the end of the year, perhaps a part of the Go 1.18 betas.
Пруф пост ноябрьский: https://blog.golang.org/11years
> тьюринг-полный
В голэнге стакать ошибки можно, так что полный. Эксепшены это просто сахар к возврату ошибок. Да, удобнее захуярить сверху трай кетч и забыть, в гошке же придется ошибку отдавать и стакать наверх, но работает по сути как эксепшены, только не в "портал" улетает, а в явном виде передается вверх по стеку вызовов.
Да я сам не против эксепшенов, но то, в каком виде есть сейчас - ТЕРПИМО, так что похуй.
Здесь есть большая разница. Да, в го обработка ошибок многословнее. Зато в го ты можешь добавить в контекст ошибки любую херню, какая тебе нужна и это будет менее многословно, чем отлавливать на каждый чих исключения. Смотри за руками:
(предположим, что findUserByName и findLastUserPost это rpc запросы и ты не сможешь сразу вытащить join'ом что тебе надо)
```go
func foo(name string) error {
user, err := findUserByName(name)
if err != nil {
return fmt.Errorf("can't find user by name %q: %w", name, err)
}
post, err := findLastUserPost(user.ID)
if err != nil {
return fmt.Errorf("can't find last user %q post: %w", user.ID, err)
}
// do something with post
return nil
}
```
```java-like
public class MyClass {
public static void foo(String name) {
User user;
try {
user = Users.FindByName(name)
} catch (e Exception) {
throw new Exception("Can't find user by name " + name, e)
}
Post post;
try {
post = Posts.FindLatestByUser(user.id)
} catch (e Exception) {
throw new Exception("Can't find latest post for user " + user.id, e)
}
// do something with post
}
}
```
Понимаешь, да? Представим, что у тебя какие-то проблемы конкретно с базой юзеров. С исключениями ты или получишь наверху ебаный "Http call exception: 500 Internal sever error for <IP>", или тебе придётся try-catch'ить каждую строку отдельно (ну или тело каждой функции, лол), что тот ещё пиздец.
А в го ты с меньшими затратами получишь полный контекст и няшную ошибку вида:
`Can't save post: can't check blacklist "banned_users": can't find user "pidor": called <IP>: 500 Internal server error`
Самым идеальным было бы, если бы в го был какой-то аналог checked exceptions через скажем объединения типов с выводом результирующих типов для лямбд и при этом с возможностью аннотировать любую переменную, как добавляемую в контекст текущей ошибки.
Чтобы было что-то вроде:
```go
func foo(@name string) error | CustomError {
user, err := findUserByName(name)
try(err)
@user.id
post, err := findLastUserPost(user.ID)
try(err)
// do something with post
return nil
}
```
Здесь try возвращает ошибку если она не nil, а @ перед переменной доклеивает её в строковом виде к текущей ошибке.
Такая функция вернула бы `foo ("pidor"): findUserByName ("<IP>", "500"): httpcall: ......`
Хз, ты хуйню написал. В джабе можно эксепшены оборачивать в стэк, и точно также сделать вывод ошибки. Ты к чему? Ну и эксепшены свои тоже можно создавать и логику на них накладывать дополнительную. Я не вижу именно преимуществ err от эксепшенов. Это просто более вербозный и более явный вид обработки. Хорошо это или плохо - мне сказать не хватает экспертизы, хоть я и мидл, это просто немного другое и более заебное. В джаве трай кетчем сверху пукнул и у тебя ультра стабильный код, так сказать.
если что я тот же, кому ты отвечаешь
Единственное что отличает ошибки го от эксепшенов - способ их "выбрасывания", и все. Эксепшены это синтаксический сахар над ручной обработкой. Тащемта и все. Робу Пайку, как я понял, они не нравятся тем, что инкапсулируют много всего и добавляют в код неявную логику. Хотя я с ним бы поспорил, но поебать.
Я хочу сокрытие типа, именно это я и написал. Если гетерогенное хранилище -- это специфика и сложная терминология, то сорян, я думал, есть голенгеры, которые шото кроме готутора видели.
> varian это трудночитаемы костыль
Это не так, лул. Не, ну разработчики буста, а вслед за ними весь комитет, конечно, глупее среднего анона с двача, но мне кажется, что ты тут не прав. Типа я не сомневаюсь, что у голенгеров не возникает обычно задач, где вариант нужен, потому я и привел конкретный пример, проблема в том, что мне он нужен, я спрашиваю не твое охуенное мнение о шарпе, яве и плюсах и не о том, как мне решать задачу, которою я тут не описывал, а о том, как мне сокрытие типов нормальное сделать, я работаю в той области, где такая задача актуальна
Да, чувствуется немного, терминами бросаешься, мне пришлось даже зависнуть, чтобы вспомнить гетерогенные контейнеры что такое (есть бэк в плюсах), ибо такие понятия не используют часто, про костыли говоришь и очень специфичный функционал плюсов хочешь реализовать. По поводу твоего вопроса - нет, такого из коробки в го нет и, надеюсь, не будет, ибо это очень специфические штуки. Голэнг повыше уровнем абстракции гораздо.
У меня переодически всплывают подобные задачи, приведу самую классическую: есть много типов структур с данными, которые тащатся хуй пойми как и откуда, при том в большом количестве. Их нужно обрабатывать на лету, по возможности экономя ресурсы. Есть много потребителей, которые хотят получать определенные типы структур, вытягивать из них данные. Потребители могут подключаться, могут отключаться рандомно. Переодически также приходится решать, какие объекты выкинуть из памяти, какие оставить, какие сохранить до лучших времен в бд или шото еще. То есть мне нужно максимально абстрагироваться от типа структуры, просто понимать, что это какое-то говно с данными, которое кому-то когда-то может понадобиться.
Ну что ты дергаешься, во первых твоя методичка устарела - типы можно аннотировать в питоне, причем в качестве преимуществ указывается чистота архитектуры и уменьшение ошибок - прикинь. Во вторых я спросил - что это за мантра, ты можешь её расшифровать без истерики?
Он хочет коллекцию, в которой можно хранить структуры разных типов, так чтобы это было типобезапасно, без interface{}.
В Го так не выйдет. Клодёшь в interface{}, потом кастуешь на тайп свитчах структуру обратно когда достаёшь.
Ебать он косноязычный, конечно, можно мыслить только в терминах плюсов и надо чтобы было как в плюсах. С++ - убийца разума.
> А зачем типы проверять в рантайме?
А зачем тогда внедрять аннотации, которые выглядят как типизация? Можно было просто тогда в комменты это все вывести и не называть аннотациями, ибо аннотации подразумевают функционал языка, а не просто нефункциональные обозначения. В том же пыхапэ есть комменты для типов и одновременно типизация, которая чекается в рантайме. Пхп канеш плохой пример, но даже там это сделано лучше, чем в Путхоне. Просто тут аргумент "а зачем лишний раз проверять" не подходит, ибо Питон не целит в ультра быстрый рантайм, могли бы уж сделать полноценный функционал.
Если что я сам на Питоне пишу, так что твои аргументы про ррряяяя бамбит - мимо. Естественно это все обложено анализаторами и линтерами, но таки хочется и рантайм чеков.
Для чего? Питон язык со строгой типизацией, строку и число один хуй не сложить.
>Сильная и строгая типизация синонимы
> язык со строгой типизацией, строку и число один хуй не сложить
Зато переменной со строкой можно присвоить данные любого типа, вернуть из функции можешь любого типа ответ, и передать в качестве параметров точно также любой тип.
> Для чего?
Чтобы улучшить общую культуру кода и его стабильности.
> Питон язык со строгой типизацией
Не строгой, а сильной, как выше анон поправил, в языке со строгой типизацией запрещены изменения типа переменной в течение времени ее жизни.
И собственно вопрос, что мне с этим делать ? И что я делаю не так ? Профайлить пробовал через "net/http/pprof" и "runtime/pprof", результат не меняется.
Да я пошутил. Естессно с либой. Можешь еще прям в лайв режиме через "net/http/pprof" профайлить, будет по роуту "/debug/pprof/" тебе в лайв режиме всю инфу высирать, и часть для pprof скачать даст. Сервер дебажить самое оно, но можно и не сервер, главное мух поднять самому тогда.
>>1904119
Нихуя. Ещё раз:
В джаве по дефолту вы на верхнем уровне получите только ошибку с нижнего + стектрейс.
В случае иерархии
- foo("hello")
-- bar("motherfucker")
--- baz("!!!)
---- httpcall("111")
ты и получишь что-то вроде:
```
java.lang.RuntimeException: "500 error"
at func httpcall
at func baz
at func bar
at func foo
```
А в то же время в го в контексте ошибок у тебя будут ещё и промежуточные значения:
`can't foo ("hello"): can't bar ("motherfucker"): can't baz ("!!!"): can't httpcall ("111"): 500 error`
(то есть, в тексте ошибки будут аргументы промежуточных функций: "hello", "motherfucker", "!!!", "111"
В джаве же по дефолту будут только значения с низкого уровня + стектрейс.
Не по дефолту (то есть добавлять значение в контекст на каждом уровне) можно, но тогда во первых у тебя будет мерзкий код (множесто try-catch'ей), а во-вторых у тебя будет создаваться новый объект исключения со стектрейсом на каждом уровне, что больно. В данном случае я правда говорю больше про первую проблему.
> Нихуя. Ещё раз:
> В джаве по дефолту вы на верхнем уровне получите только ошибку
Так я и написал, что можешь кастомные эксепшены сделать и даже общий абстрактный класс захуярить со своим анврапом и будет точная копия голенговского преобразования в строку, которое ты дальше приводишь.
> А в то же время в го в контексте ошибок у тебя будут ещё и промежуточные значения
Они будут если ты позаботишься о том, чтобы они были. Если тупо возвращать ошибки простые - то нихуя и не будет. Врапать то тебя не заставляет никто, ты можешь на каждом уровне хоть пустую ошибку создать.
> можно, но тогда во первых у тебя будет мерзкий код
Так в го тебе и так придется врапать на каждом логическом уровне ошибку. Все твои can't huy - нужно врапать самому. Или ты о чем?
> Так чем же так хорош этот язык?
Хуй знает чиста пацаны с работы в студии посоветовали ну я и перекатился чиста пишем там мелкие проги всякие я хз особо не разбирался чиста гайд прочитал и хуярю чета там профи какие-то чето хз ваще похуй работает нармас можно сайтики писать тока типы какието сложные хз зачем добавили лучше бы как в пхп можно было без типов и с ними так сказать свобода чтобы была разработческая вот воот
Бля. В третий раз говорю, ты можешь сделать кастомные эксепшены, но чтобы залогать "motherfucker" или "!!!" из моего примера, тебе придётся оборачивать вызов baz() в try-catch.
То есть код вместо последовательных
res, err := do()
if err != nil { return fmt.Errorf("foo: %w")}
превращается в последовательные
Res res;
try {
res = do()
} catch (e Exception) {
throw NextLevelExeption("foo", e)
}
> Так в го тебе и так придется врапать на каждом логическом уровне ошибку. Все твои can't huy - нужно врапать самому. Или ты о чем?
Как раз о том же. Что в го если ты врапаешь и контекстуализируешь каждую ошибку, то это смотрится менее уродливо, чем на исключениях, если бы ты try-catch'ил каждую ошибку.
ПЕРЕКАТ: https://2ch.hk/pr/res/1905210.html
ПЕРЕКАТ: https://2ch.hk/pr/res/1905210.html
ПЕРЕКАТ: https://2ch.hk/pr/res/1905210.html
Привел шапку в божеский вид наконец, пиздец.
ПЕРЕКАТ: https://2ch.hk/pr/res/1905210.html
ПЕРЕКАТ: https://2ch.hk/pr/res/1905210.html
ПЕРЕКАТ: https://2ch.hk/pr/res/1905210.html
ПЕРЕКАТ: https://2ch.hk/pr/res/1905210.html
Чистый код читай. Если коротко - весь файл целеком ты все равно не запомнишь, неважно, там 2-3 экрана текста или 15, да и детали реализации методов не важны, пока ты не знаешь где и при каких условиях они вызываются (см любой доклад Григория Петрова, например вот https://www.youtube.com/watch?v=z5WkDQVeYU4). Тебе в любой момент времени, когда ты смотришь на код, важнее как методы между собой взаимодействуют, а на вопрос - что они сами, непосредственно, делают, тебе в значительной мере должно ответить имя метода. Если же нужно поподробнее - тогда переходишь в скоуп определения функции и уже там повторяешь эти же действия. В большинстве случаев ты , вызывая fmt.Printf думаешь о том, что он выведет тебе что-то в терминал, а не о том, что оно распарсит строку формата, для каждого аргумента чекнет, имплементит ли он один из 3-х методов, меняющих поведение преобразование их в стрингу, в случае дефолтного флага из строки темплейта, если он отличается от дефолтного, скорректировать так же приведение к стринге и на его основании, составит из этого всего слайс байт и запишет этот слайс в специальный файл операционной системы, чтобы результат вывелся на экран.