Go или Golang — компилируемый многопоточный язык программирования, разработанный внутри компании Google. Go поддерживает типобезопасность, возможность динамического ввода данных, а также содержит богатую стандартную библиотеку функций и встроенные типы данных.
Обсуждаем язык, смеемся с залетных крестоносцев, обсуждаем почему нам не нужны дженерики, ООП и эксепшены, по каждому багу находим трехстраничный пост в официальном блоге Go, объясняющий почему это на самом деле фича, ждем, когда нам завезут дженерики, ООП и эксепшены.
С чего начать:
- В обязательном порядке проходим Go Tour: https://tour.golang.org/welcome/1 (есть на Русском)
- Читаем документацию прямо по порядку (пункт "Learning Go"): https://golang.org/doc/
- Ознакамливаемся с общим roadmap по изучению языка и сопутствующих инструментов: https://github.com/Alikhll/golang-developer-roadmap (постоянно обновляется сообществом)
Литература:
- Донован, Керниган "Язык программирования Go"
- Также хорошие книги для начала: https://www.golang-book.com/
- Книги из списка https://github.com/dariubs/GoBooks
- А также смотрим видео https://www.youtube.com/channel/UC_BzFbxG2za3bp5NRRRXJSw
Полезные дополнения:
- Сборник паттернов и инфы по микросервисам: https://microservices.io/
Обновляемый список с пакетами: https://github.com/avelino/awesome-go
Небольшой канал треда: t.me/golang2ch
Предыдущий тред умирает здесь: >>1876438 (OP)
Шаблон шапки: https://pastebin.com/iRaveWbC
Эксепшнов никогда не будет скорее всего, а вот писать каждый раз 6 строк, чтобы сравнить два слайса по содержимому - это невесело.
> а вот писать каждый раз 6 строк, чтобы сравнить два слайса по содержимому - это невесело.
Дженерики не только для всякой специфичной хуйни полезны. Например тот-же банальный пагинатор без дженериков не запилить без бойлерплейтов и с тайпсейфти. Да достаточно много небайтоебских полезностей привнесут. А по поводу эксепшенов - да, скорее всего не добавят, ибо слишком уж въелся в язык нынешний вид ошибок. Уже сподвижки начались в сторону нормального стекания ошибок, можно надеяться, что выдумают что-то более менее человеческое из всего этого.
> даже php выглядит
php почти копия джавы, один из самых ООП фулл языков (лол), там даже сраные трейты есть. Не стоит сравнивать языки тупо по функционалу, иначе тогда тот же питон соснет хуйца даже у пхп (речь о функционале из коробке, а не либах). Язык это инструмент, а не тупо набор функционала.
>>1905912
Нахуя вообще сравнивать go с высокоуровневыми языками? По выразительности и плюсы хуй соснут у php, блять. В байтоебском языке по определению не может быть слишком много сахара, иначе получится C++, в который понапихали столько, что выучить его нормально и жизни не хватит теперь, а на го ты через месяц уже сможешь написать 300кк рпс в наносек без утечек памяти и с многопоточностью.
> Когад го перестал быть высокоуровневым языком с сахаром
Ну кроме абстракции над многопоточностью там сахара нет особо, можешь руками память чистить с вырубленным gc, поинтеры это реальные поинтеры в память, а не просто сахар и т.д. и т.п. Естественно он не такой низкоуровневый как плюсы или раст, он скорее что-то среднее между шарпом/жавой и сями.
Да высокоуровневый го язык, вы заебали уже. Ты будешь ебаться с байтами только если сам хочешь или пишешь свою бд или там json энкодер какой-нибудь. 99% времени ты делаешь то же, что и в php и в джаве и где угодно ещё: принимаешь запрос, валидируешь аргументы, пихаешь их в функцию бизнес логики, оттуда лезешь в базу, собираешь ответ, отдаешь его обратно.
Из "страшных низкоуровневых вещей" в го есть указатели (пиздец как страшно, на фоне того, что в php бывают nullable структуры, почти то же самое), слайсы (блять, ссылочный тип, указывающий на массив и автоматически пересоздающий этот массив с удвоением длины при необходимости), всё. Ни тебе арифметики указателей, ни тебе ебли с тредами, ничего.
Пехапешникам было бы тяжело переходить на го только потому, что сама пыха - очень кастрированный язык, не в смысле "плохо", а в смысле "заточено под конкретную задачу". Поэтому пехапешникам сложнее будет влиться в многопоточное программирование, игры со стейтом, настройку сборщика мусора и прочие рантаймовые тонкости. Но это не специфика перехода php->go, это будет работать на переходе с пыхи на вообще любой другой язык.
>>1906016
Лолчто, ебли с байтами нет, если ты не затачиваешь приложение под супер ультра мега хайлоад. В реальном бою ты максимум встретишь []byte, сконвертишь его в string и забудешь о том, что видел изначально.
>>1905425 →
>>1905709 →
В двух словах - как перекатился, что пилил на джаве, что пилишь на го?
Блд, увидел ответ (>>1906157 →), хз куда смотрел до этого.
В общем, всё понятно.
Если кто-то ещё поделится подробностями переката из джавы в го - буду признателен.
На плюсах ты точно также можешь этим заниматься. Уровень языка определяет не то, что на нем иногда делают. В го ты будешь ебаться с тюнингом того-же латенси как чорт, если ты не работаешь в говноконторе (а на го их меньше, чем нормального хайлоада) - ты как раз будешь заниматься конкретно что байтоебством, при чем с обязательным знанием как тот-же gc и шелдуер внутри работает.
Да нихуя. Сколько уже людей приходили на конфы и говорили: нам был нужен перформанс, мы короч взяли го и просто написали нормально, ничего специально не задрачивали - и сразу попали в SLA.
Если тебе нужен такой хайлоад, что тебе в го нужно уже байтики ебать, то во-первых, сколько ты дрочил алгоритмы перед тем, как тебя взяли в гугл пили прохладную, а во-вторых, нахуя тебе го в таком случае, если есть плюсы или раст?
В го есть ряд вещей, которые реально тюнятся:
- аллокатор, так в го сравнительно "дорогие" аллокации из-за того, что сборщик мусора не перемещающий, в итоге с дефрагментацией они на аллокациях борятся, решается переиспользованием объектов в узких местах через sync.Pool;
- планировщик, если у тебя прям слишком много горутин. Решается профилированием и пулами горутин;
- гц иногда захлебывается из-за слишком большого количества указателей, решается в первую очередь правильным их использованием (чтобы не держать миллионные мапы структур с указателями в памяти к примеру); И только если у тебя нужно хранить в рантайме десятки гигабайт, то нужно будет скрывать эту память гц с помощью магии.
Ну и дальше базовые вещи, типа, не ждать лишний раз, не выделять ненужное, использовать правильные алгоритмы и всё такое.
Как видишь, байтоёбства я не упомянул.
Может ещё можно вспомнить уже совсем конкретные оптимизации типа использования []byte вместо string из-за иммутабельности и лишних указателей, но это совсем мелочи.
> при чем с обязательным знанием как тот-же gc и шелдуер внутри работает.
Если ты не джун - то ты и так должен этого знать.
> Что это значит и как относится к байтоебству, если это контракт между сервисами просто?
Ну грубо говоря, вы договорились, что твой сервис выдерживает 5000rps, а ты написал на php и он выдерживает только 500rps. Ты такой просто переписал его на go и даже не сильно тюнил, и он сразу вынес 10000rps, так что ты сходу выполнил договорённости, без лишнего байтоёбства.
Лол, ну давай, к тебе придёт клиент и скажет "я короч хочу сайт, чтобы он там миллион пользователей одновременно мог выдержать, а то опять тормозное говно мне сделаете". Если ты ему ответишь "давай я сначала накодю, а потом померяем", то он тебя нахуй пошлёт и меня наймёт и правильно сделает. Потому что я подумаю и выдаем ему реалистичное число, которое потом мы в контракт и напишем (прямо над чеком в миллион баксов лично мне). Бизнес логику напишу на чём угодно, а узкие места на том же го сделаю и нормально будет.
Как я понял, тут дело в том, что массивы (и слайсы) в го хранят объекты, а не ссылки на них. Т.е. нужно знать размер объекта, чтобы делать то, что ты хочешь.
Поэтому, тут никакие дженерики не помогут.
>>1906241
Но, почему то же самое не работает с указателями?
У указателей тоже разный размер, или что?
>Как я понял, тут дело в том, что массивы (и слайсы) в го хранят объекты, а не ссылки на них. Т.е. нужно знать размер объекта, чтобы делать то, что ты хочешь.
Не совсем так, в массивах и слайсах можно хранить как объекты, так и ссылки.
>Поэтому, тут никакие дженерики не помогут.
Это же типичная ситуация, когда дженерики как раз и помогают
>>1906286
Указатели все имеют одинаковый размер, а вот интерфейсное значение и указатель - разное. Такой дизайн сделан сознательно, чтобы не прятать за магию операцию, требующую О(n) алокаций интерфейсных значений. Если тебе реально нужно преобразовать слайс объектов в слайс интерфейсных значений - сам напишешь лишние 5 строчек.
после Сишки, Го кажется уебищным языком, это норма? к этому привыкаешь? Есть тут бывшие сишники, поделитесь успехом...
>поинтеры это реальные поинтеры в память, а не просто сахар
Не совсем: https://golang.org/doc/faq#stack_or_heap . TL;DR : арифметика указателей инкапсулирована в самих конструкциях языка. Переменные созданные в скоупе функции, лежат на стеке если они хранят небольшое количество байт и на них нет указателей или они есть но не выходят за пределы скоупа функций. Иначе переменная создается в куче. Вот в C/C++, Rust есть голые указатели которые дают полный контроль над памятью.
"Глупые программистишки не отличают ошибки, которые нужно обрабатывать, от дебажных ассертов, поэтому мы их не сделали))0"
>>1906447
А зачем они нужны? Не проще код просто писать так, чтобы значения не пидорасило в разные стороны? По идее ты можешь написать функцию эту сам, или я ошибаюсь и ассерт - это больше, чем тупо функция, кидающая панику при неверном кондишене в её аргументе?
Если что у меня нет бэкграунда в сях, просто рил интересно
Почему не совсем? То, что хипа/стек определяется автоматически - не значит, что поинтер это не поинтер. Го это язык со сборщиком мусора, поэтому логично, что тебе не нужно руками в память писать. Но ты можешь спокойно сам аллоцировать память (правда в обход GC, т.е. придется еще позаботиться о том, чтобы за собой убрать), есть целые техники в го даже с этим связанные. Но если тебя не ебет перформанс в рот - проще довериться gc, он умён не по годам, так сказать.
>>1906451
В го это тоже escape analysis
с ув. maxmol
тут дух старой школы живёт скрря
выне паньмаете что гоу это мазохищм нахуй???
с ув. шлакомол
ахахахахаха
похуй не важно спс
>То, что хипа/стек определяется автоматически - не значит, что поинтер это не поинтер
Правильно. Это значит что поинтер - не прямой поинтер в ОЗУ в отличие от звездочки в Си/Крестах (хотя и выглядит также).
>>1906456
Референсы - это поинтеры, которые компилятор/интерпретатор дереференсит за тебя в контекстах их использования.
> а жс вообще интерпретируется
Это если JIT компилятору не удалось угадать типы аргументов и локальных переменных функции. Интерпретируемость никак не относится к тому, как выделяется память в языке. В ЖС различаются stack allocated vs heap allocated variables, и это также достигается escape analysis-ом как и в Го-шке.
>методы и прочее, 22 из 26
>Implement a Reader type that emits an infinite stream of the ASCII character 'A'.
>Реализуйте тип Reader, который испускает бесконечный поток символа ASCII «A».
>Нихуя не понял, бился 3 часа в попытках честно написать код самостоятельно.
>2 года не курил, снова начал
>Заебало, загуглил
>реализация метода https://gist.github.com/rndD/5ba3c7c9883de396a4ea оказывается должна считать количество символов А, которыми заполняется массив
Объясните мне это блядство пожалуйста.
Я уже по горло сыт этими ебучими условиями и омерзительной подачей материала
Надо следующий тред с этой картинки начать
Да, это довольно не очевидный момент - ридер это тип, который не просто имплементит метод, но еще и соответствует 6 абзацам комментариев над интерфейсом https://golang.org/pkg/io/#Reader
> жс макака, ты?
> за связный список и какие есть проблемы с кешами процессора
Ты сразу же обосрался, ибо если бы хоть немного шарил в теме - понял бы, что связный список и проблемы с кешами - это один общий логический блок. В итоге ты половину фразы вырвал и обосрался.
Под блядством я подразумевал омерзительную подачу материала.
Это же тур по го, верно? Обязательный для вкатывающихся, как описано в шапке, да?
Кал говна ёбаный.
Материал нормально подается вплоть до описания методов. Потом кучкой идет чисто теория, где тебе надо посмотреть код и прожать кнопку далее и никакого закрепления работы с указателями, методов, интерфейсов нет. А это 80% от этапа по количеству шагов. Остальные 20% - это уже новый материал, краткий пример работы с ним или вообще его отсутствие и непонятное описание того, что от тебя хотят в шаге упражнения.
>>1907995
Спасибо. Только это должно было быть описано в туре, а не на дваче, лол.
Существует нормальная замена этому туру по го?
Я дошел до rot13Reader и вообще ничего не понял.
Я могу гуглить примеры, но это не то, как должно проходить обучение, ящитаю.
> Существует нормальная замена этому туру по го?
Так он ахуенный же. По всем основам языка галопом пробегаются. Это же не онлайн курс, тур предполагает как раз ТУР, т.е. ОЗНАКОМЛЕНИЕ с языком. Если что не понятно - нужно гуглить, а не надеяться, что тебе в коротком туре объяснят все до самых мелочей.
А ридеры и райтеры - это тема специфичная, ты её поймешь только после пары крупных статей и самостоятельного дрочева.
Спасибо, приободрил.
Но вообще это выглядит как требование решать рокетсаенс после биквадратных уравнений.
Чуствуешь себя, будто отвлекся на минуту и пропустил объяснение, а объяснения и не было. Зачем тогда там упражнения...
Ладно, я просто попозже вернусь к этому.
Да я сам ахуевал с этих reader/writer. Т.е. как работают понимал, но нахуй настолько низкоуровневая абстракция нужна - не понимал. А когда код начинаешь писать и встречать их везде - понимаешь, что это ахуенный способ перенаправлять потоки байтовой/строковой информации, например os.stdout это readwriter, как и файл. Короче очень удобная хуйня, когда начнешь с stdlib разбираться подробнее.
ДЖЕНЕРИКИ
Начался процесс апрува последнего диз документа для дженериков :https://blog.golang.org/generics-proposal
Обсуждение вынесено в соответствующий issue на гитхабе: https://github.com/golang/go/issues/43651
Если кратко - в результате этого процесса принимается окончательное решение принимать ли диздок к ИСПОЛНЕНИЮ, поставить на паузу, или полностью отклонить. Отклонять конкретно данное изменение не будут, по сути сейчас происходит процесс окончательного утверждения дизайндока, возможно отправится на доработку.
мамкин киберсекс с кризисом среднего возраста, решивший на старости лет вяло перетечь в погроммисты из говна безопасности
Чистый код читай. Если коротко - весь файл целеком ты все равно не запомнишь, неважно, там 2-3 экрана текста или 15, да и детали реализации методов не важны, пока ты не знаешь где и при каких условиях они вызываются (см любой доклад Григория Петрова, например вот https://www.youtube.com/watch?v=z5WkDQVeYU4).[РАСКРЫТЬ] Тебе в любой момент времени, когда ты смотришь на код, важнее как методы между собой взаимодействуют, а на вопрос - что они сами, непосредственно, делают, тебе в значительной мере должно ответить имя метода. Если же нужно поподробнее - тогда переходишь в скоуп определения функции и уже там повторяешь эти же действия. В большинстве случаев ты , вызывая fmt.Printf думаешь о том, что он выведет тебе что-то в терминал, а не о том, что оно распарсит строку формата, для каждого аргумента чекнет, имплементит ли он один из 3-х методов, меняющих поведение преобразование их в стрингу, в случае дефолтного флага из строки темплейта, если он отличается от дефолтного, скорректировать так же приведение к стринге и на его основании, составит из этого всего слайс байт и запишет этот слайс в специальный файл операционной системы, чтобы результат вывелся на экран.
Вот у шарпах и джсах есть async await. Когда есть длинная IO операция, например скачать файл, то чтобы не лочить основной поток, ты просто передаешь лямбду которая в качестве аргумента примет тот файл. В результате в этом же потоке можно выполнять другой код, а когда файл скачается, то что-то где-то запустит твою лямбду.
А что с этими зелеными потоками? Они тоже эту задачу решают? Потому что в моем понимании, если вызвать такой поток с ио операцией, то у тебя просто будет два потока, один из которых просто будет простаивать и ждать закачки файла. Или рантайм дохуя умный, поймет что поток нихуя не делает и засуспендит его? А откуда он тогда будет знать, когда файл скачается и что надо снова запустить поток?
Ну смотри, есть процесс, у него есть очередь с горутинами, он берет из нее горутину и выполняет её в отдельном ос-треде, если горутина переходит в режим ожидания, то планировщик перемещает её обратно в очередь, переключает контекст и берет следующую. Так работает планировщик в го, если у тебя один процесс. В случае ели процессов несколько, то происходит кража горутин и тд. Как это работает в хачкеле, хз.
> А что с этими зелеными потоками? Они тоже эту задачу решают?
Вообще ничем не отличается, можешь также ждать окончания в каком-то месте с помощью канала, можешь забить хуй и точно также выполнить по окончанию что хочешь. Можешь мьютексами жонглировать. Вопрос то твой в чем?
> если вызвать такой поток с ио операцией, то у тебя просто будет два потока, один из которых просто будет простаивать и ждать закачки файла
ГОвнарь разраб выше частично прав. Планировщик ГОвна просто перекинет её в локальную очередь на том треде и вернет её к выполнению когда сисколл интерраптнется и вернет ответ. Но тут планировщик ГОвна и планировщик самой ОС вместе работают, ибо планировщик го тоже работает под ОС и ОС спокойно его прерывает. Сисколл тот же именно ОС интеррапт делать будет и т.д. Но да, если у тебя на одном физическом потоке 30 горутин, то та, где произошел лок по сисколлу - будет разлочена только когда разлочится этот сисколл, т.е. впустую гоняться на потоке она не будет. Точно также и с нетворк коллами и всем остальным, что ты ожидаешь и от самого планировщика ОС (правда на некоторых процах типа некоторых интеллов есть целые отдельные треды только для нетворк коллов, вот там чуть другая логика будет, но можешь хуй забить).
Мимо ГОвноеб миддл разработчик
То есть когда в гринпотоке запускается ио операция, он помечается "спящим", но также создается и каллбэк, при вызове которого поток перестает быть спящим, и значит рантайм его в скором времени запустит, да?
А как вообще работает ио на лоулевеле? В моем понимании, в системные вызовы можно передать каллбэк, который в шарпе, к примеру, запускает юзерский код после слова await, а в го помечает тред как "неспящий".
И какие преимущества/недостатки у потоков? Я вижу только плюс - не надо помечать каждую функцию асинхронной, рантайм сам поймет какой поток спит.
> не надо помечать каждую функцию асинхронной
Я про то, что в шарпе для каждой io функции есть асинхронный дубликат, типа File.Read() и File.ReadAsync(). Ну и если я придумаю свою асинхронную либу для хаскеля, то мне придется писать обертки для КАЖДОЙ io функции, тогда как с гринтредами тупо пишешь forkIO <youriofunction> и оно сработает.
> То есть когда в гринпотоке запускается ио операция, он помечается "спящим"
Ну если грубо - то да, так.
> но также создается и каллбэк, при вызове которого поток перестает быть спящим
Я не знаю что ты имеешь в виду под коллбэком. Когда в горутине происходит сис колл - происходит её блокировка, сразу же происходит подруб планировщика на физическом потоке (го запускает по одному планировщику на каждый реальный поток) и планировщик перемещает эту горутину в очередь и берет из этой очереди горутину, которая не "ждет" ничего, и кидает её на выполнение в этом же физическом потоке. Когда от ОС возвращается ответ (прерывание) по сис коллу - эта заблокированная горутина переходит в "готовые продолжить пахать на барина", при последующем прогоне планировщика - он может продолжить её выполнение (а может и другую, как сам вздумает своими алгоритмами).
Планировщик самого ГОвна работает схожим образом с планировщиком процессов в самой ОперационнойСистеме, в ОС обычно есть 3 состояния у процесса на физическом потоке - runnable (т.е. можно дать ему процессорного времени, т.е. закинуть на физ. поток), waiting (процесс ждет ответа системного вызова, его игнорим) и executing (процесс прямо сейчас выполняется на потоке). В ГОвне схожим образом работают горутины, но уже не на физических потоках, а в абстракции зеленых конкурентных.
> В моем понимании, в системные вызовы можно передать каллбэк, который в шарпе, к примеру, запускает юзерский код после слова await, а в го помечает тред как "неспящий".
Чушь спизданул. Ты пиздец путаешь понятия, либо в теме не разбираешься. Я тебе расписываю как сам планировщик грин тредов в го работает, а не как на уровне кода и функций ты это пишешь. На уровне кода что в шарпе что в голэнге примерно одинаково эта концепция работает, только в голэнге она сильно проще пишется, есть только одно ключевое слово 'go', и все, пишешь 'go mamuEbal()' и твоя функция улетает выполняться асинхронно (не сразу, но в детали вдаваться не буду), никаких коллбэков. А для того, чтобы ждать её выполнения, чтобы эти прцоессы могли взаимодействовать между собой - уже есть разные средства в голэнге, начиная от каналов и заканчивая атомными операциями или мьютексами те же.
> И какие преимущества/недостатки у потоков?
Чего? Что с чем сравниваешь, недостатки в сравнении с чем?
>Я вижу только плюс - не надо помечать каждую функцию асинхронной, рантайм сам поймет какой поток спит.
Я тебя не понимаю, что помечать, какой поток спит? Что в шарпе что в ГОвне работает все примерно одинаково, просто конструкции языка разные и в ГОвне это все очень просто реализовано, в шарпе больше головной боли, когда дело доходит до взаимодействия между несколькими потоками.
>>1911350
Я допер что ты хочешь. Если кратко - обе модели асинхронности (грин тредов) заебись, в шарпе сильно сложнее, но гораздо больше возможностей по настройке, а в голэнге прям очень простая, но и вариантов тюнинга очень мало. По скорости шо то шо это примерно одинаковы на дженерик задачах, но в шарпе потенциально в некоторых случаях можно выиграть, если будет специфичный сценарий, а в голенге дальше горутин не залезть по сути.
>Я не знаю что ты имеешь в виду под коллбэком.
Я так называл системные прерывания. Только что прочитал что это. Мб с терминами я и попутал, но представлял я себе это именно так, как ты описал.
>>1911369
>Нет, в ГОвне ты можешь любую функцию в любой момент времени выпустить в отдельный тред. Естественно если ты будешь пытаться одновременно писать и читать из файла - получишь пиздов, но я думаю это и так очевидно.
Ну я же про это и говорю! В го ты перед тем что хочешь запустить асинхронно пишешь 'go', в хаскеле 'forkIO' или async, если стороннюю либу юзать
> По скорости шо то шо это примерно одинаковы на дженерик задачах, но в шарпе потенциально в некоторых случаях можно выиграть
Простой пример - он быстрее когда твоя задача потенциально асинхронная. Типа есть функция 'if (hasInCache) return fromCache else await returnFromDb()'; В го при вызове такой функции ты по любому создашь гринтред, тогда как в шарпе, с ValueTask если обьект все таки есть в кеше, даже на кучу нихуя выделять не придется.
2. Насколько вообще оправдано использование указателей? Когда я первый раз услышал, что в го есть и гц и указатели, мне это сразу показалось странным. Любые большие объекты - строки, слайсы, мапы - все равно передаются по указателям (ну или около того, главное, что их содержимое целиком не копируется) и на них и так работает гц. В то же время, любой возвращенный по указателю объект создает нагрузку на гц и эта нагрузка порой очень значительна. По-факту получается, что, скажем, гонять структуры между горутинами через каналы выгоднее полным копированием, потому что их передача по указателям просаживает перфоманс. Или я не прав? Во всяком случае мои простые бенчмарки показывают, что между двумя горутинами в канале быстрее передаются копии структур, а не указатели. В то же время невозможность через интерфейс вызвать метод с получателем-указателем не у указателя (преобразование, которое без интерфейсов делает компилятор) заставляет все объекты, скрытые за интерфейсами возвращать по указателям. Из-за этого частично мой 1-й вопрос: почему нельзя было убрать нафиг привязку методов к разным получателям, всегда передавать указатель на объект в метод (разумеется, гц тут задействован бы не был) и убрать вообще указатели целиком в unsafe? В коде бы стало гораздо меньше бардака и больше предопределенности.
> Зачем в го возможность объявлять получателя метода по указателю и без?
Шоб было.
> Но какой это имеет смысл, если из-за этого теряется вся идея ООП-моделирования объектов с изменяемым внутренним состоянием?
А голэнг и не ООП язык, в нем всё - тип.
> Если мне так нужны иммутабельные объекты, то мне все равно придется руками возвращать из функции копию объекта с новым состоянием.
Ну да, как и во всех других языках, лол. А ты что хочешь?
> Два способа объявления методов только запутывают
Чем? Ресивер без поинтера - это аналог статическим методам в других языках. Чем тебя это запутывает? Или ты про то, что человек, использующий метод - не знает четко какой ресивер, пока не посмотрит? Так ему и не нужно знать детали имплементации в большинстве случаев, а когда надо - он все равно полезет в доки, а в голэнге документирование функции происходит прямо над методом. Соответственно любой, кто не знает что метод делает - сразу же все поймет глянув поп ап в IDE.
> Насколько вообще оправдано использование указателей?
Только тогда, когда нужно отдать именно указатель, а не копию. Ты верно дальше подметил, что из-за ГЦ убивается весь потенциальный смысл использовать ссылки для ускорения выполнения, это и правда недостаток модели ГЦ. В шарпе тоже есть поинтеры, но там более удачная архитектура, не создающая столько оверхеда.
> Когда я первый раз услышал, что в го есть и гц и указатели, мне это сразу показалось странным
Но ГЦ есть во многих языках с указателями, почему только в ГО тебе это показалось странным? Нужно не на сам факт ГЦ грешить, а на то, что он медленно подбирает с хипы аллокации такие, в шарпе тоже гц их собирает, но гораздо шустрее.
> В то же время, любой возвращенный по указателю объект создает нагрузку на гц и эта нагрузка порой очень значительна.
Со слайсами (и остальными ссылочными типами) точно также, создается оверхед, ибо аллоцируется все в хипе. Таков путь.
Но в защиту поинтеров могу сказать, что обычно их используют в долгоиграющей перспективе, т.е. твои бенчмарки с простым возвращением поинтера - это синтетический тест, заранее направленный на провал, ибо ты создаешь тысячу объектов поинтерами, в реальном коде ГЦ не будет их подбирать в большинстве случаев, т.к. они будут жить гораздо дольше микросекунд. Но, конечно, это не полноценное оправдание, а больше заметка, что все на настолько хуево, как в синтетическом бенчмарке с кучей аллокаций.
> По-факту получается, что, скажем, гонять структуры между горутинами через каналы выгоднее полным копированием, потому что их передача по указателям просаживает перфоманс. Или я не прав?
Если ты планируешь этими значениями дальше пользоваться, то перформанс будет обратно пропорционален времени от аллокации до сборки мусора. Если это рядовые флаги, которые ты чекнешь и забудешь - передавать по значению, если это объекты, которыми дальше будешь пользоваться - то ссылочный оверхед уменьшается (но не уходит полностью, естественно).
> заставляет все объекты, скрытые за интерфейсами возвращать по указателям
Нет, возвращается интерфейс по значению. Просто интерфейс содержит в себе ссылку на конкретный объект. Это как слайс, грубо говоря, где сам слайс - это интерфейс, а массив - это объект. Но да, от оверхеда это не спасет.
На самом деле мне вообще не нравится сахар в го, когда дереференс автоматически происходит, мне было бы гораздо удобнее самому дереференсить и интерфейсы и возвращаемые ссылки, ибо как раз из-за такого сахара и появляются недопонимания типа твоего. Интерфейс в го - это тип, конкретный такой тип, и относиться к нему нужно как и к другим типам, никакой магии особой за ним нет, кроме компилятора.
>лучший в мире язык
Обосраться просто. "Лучший в мире язык"
Полистал тут на досуге мануал по Го и охуел. Что это за уебство? Язык сам по себе мощный засчет свой многопоточной модели но сам код это что-то с чем-то.
Вот что за наркоман придумал экспортировать имена по заглавной букве блять? Что это и главное - нахуя? Почему я не могу как нормальный человек писать export перед переменной?
Можно делать "голый return" блять, в любом нормальном языке конструкция return без ничего возвращает null, тут же она блять вернет объявленные в теле функции переменные, ебануться, подозреваю за такие return-ы без ничего надо сразу увольнять нахуй потому что обмудку видите ли было лениво записать явно переменные
var можно писать при объявлении а можно и хуй забить, заебись, TS на норм проектах уже давно не скомпилится если такое вытворишь, но в "лучшем в мире языке" это с какого-то хуя является фичей
ООП парадигма не юзается, только вот и функциональщина тоже на уровне говна
Лучше уж останусь на ноде и TS
Зачем ты отвечаешь залётному школьнику с разумом мартышки?
Очевидно же, что он только оканчивает девятый класс.
нахуй нужен го если есть пайтон
> сложить числа в массиве
> в питоне нет массивов
Хуя познавший вселенную затирает про свой любимый питон. Шизик, ты бы хоть типы в своем языке выучил, прежде чем сраться за то, кто где лучше. Хотя сам факт, что ты пришел серить в чужой тред этой хуйней - говорит о тебе, как о человеке низкого интеллекта. Так уж и быть, на первый раз простим блаженного, но больше не пиши сюда, чмок :*
Зато конкурентность и паралелизм удобно имплементировать. А в питоне такая ебень с этим asyncio, так ещё и GIL, пиздец просто, постоянно приходится узкие места на С переписывать, я бы тебя понял если бы ты противопоставил Джаву какую нибудь. А про сумму ты вообще хуйню написал, в ML алгоритмах её конечно часто используют, но мы тут байтоёбим и круды шлепаем, кто-то сервисы всякие интересные пилит, пока что ни разу не приходилось использовать сумму массива, на столько часто, чтобы мне понадобилась функция sum. Покормил зелёного.
Партия считает, что это сомнительная конструкция https://github.com/golang/go/wiki/CodeReviewComments#naked-returns
> матчасть
Хуясть. С точки зрения программиста на питоне это именно список, а implementation-specific детали - это не про синтаксис языка, а про его реализацию. Так можно дойти до того, что и массивов как отдельной сущности не существует, это просто несколько ячеек подряд в памяти.
> динамический массив
Какой же ты тупой... Список в Питоне не является массивом, даже динамическим. В питоне это не динамический массив, а кастомная хэш мапа с хэш функцией, это даже не массив значений, это массив ссылок на значения, а из-за типизации питона сам масив уже начнет появляться чуть ли не на уровне интерпретатора d6. Да, где-то там на каком-то из нижних уровней это действительно динамический массив, но только после нескольких шагов нормализации, да и не может там не быть массива, даже под хэш массивами пхп в Си уже идут массивы с аллокациями, лол.
>>1913611
Как там сосется, когда даже если обложился линтерами и тестами по самые яйца - твой код может в любой момент послать тебя нахуй, да и то только в рантайме на проде? Чисто ловите кайф там наверное, когда каждый пук надо дебажить через принт, чтобы ей богу все нормально работало :3
Ну, Jedem das Seine
Я лично свичнулся из TS в Go и очень доволен. Есть, конечно, в TS вещи, которые мне реально очень нравятся - например, перегрузки методов - такого никогда не будет в Go, но это нормально, что языки не похожи между собой, в этом-то и суть создания нового языка.
К слову о перегрузках в TS - они там работают не так, как в каких-нибуть крестах, где на каждый перегруз своя реализация. Нет, в TS - у тебя на уровне типов несколько сигнатур, а на уровне реализации - эта одна и та же функция. Это очень удобно, когда тебе в метод нужно передать либо один аргумент, а второй - оставить пустым, либо - наоборот. В итоге правильность вызова твоего метода проверяет компилятор и тебе не нужно отдельно внутри метода проверять, все ли правильно передали и падать, если нет.
Какой тайпинг? В питоне его нет, есть только аннотации, игнорируемые интерпретатором и доступные через рефлексию. Даже в пхп тайпинга больше, чем в Питоне. Под линтерами и статический анализатор понимается, если ты не в курсе. Иди пердантик подтягивай да юнит тестами обкладывайся, манька.
Мимо питонист+го боярин
Какой тонкий намёк любителям русека
>Сам постоянно ахуевал почему в ioutill столько хуйни разной.
А по тому что это сама суть helper/utill файлов/пакетов - это всегда ебаное нагромождение никак не связанной между собой хуйни, хорошо если оно хотя бы достаточно абстрактное и универсальное но зачастую - нет.
У меня на проекте тимлид если такое видит - не позволяет замержить PR, и правильно делает.