Go или Golang — компилируемый многопоточный язык программирования, разработанный внутри компании Google. Go поддерживает типобезопасность, возможность динамического ввода данных, а также содержит богатую стандартную библиотеку функций и встроенные типы данных.
Обсуждаем язык, смеемся с залетных крестоносцев, обсуждаем почему нам не нужны дженерики, ООП и эксепшены, по каждому багу находим трехстраничный пост в официальном блоге Go, объясняющий почему это на самом деле фича, ждем, когда нам завезут дженерики, ООП и эксепшены.
>>1905518 > а вот писать каждый раз 6 строк, чтобы сравнить два слайса по содержимому - это невесело. Дженерики не только для всякой специфичной хуйни полезны. Например тот-же банальный пагинатор без дженериков не запилить без бойлерплейтов и с тайпсейфти. Да достаточно много небайтоебских полезностей привнесут. А по поводу эксепшенов - да, скорее всего не добавят, ибо слишком уж въелся в язык нынешний вид ошибок. Уже сподвижки начались в сторону нормального стекания ошибок, можно надеяться, что выдумают что-то более менее человеческое из всего этого.
>>1905777 Кодогенерация, макросы, препроцессоры и транспайлеры - это в целом лютые костыли, созданные из-за скудности и примитивности синтаксисов языков. "Нормальным" это быть просто не может.
Кодогенерация - это прием статического полиморфизма если что. Для Го в котором нет дженериков, это единственный способ без копипаста кода писать generic code.
Плюс один special case, синтаксический костыль к декларациям функций вместо очевидного типа Result, который возвращают функции с исключениями. Я бы не назвал это плюсом.
>>1905758 Сравнить два слайса - это не специфичная хуйня, а повседневное программирование так-то, причем вне зависимости от того, что ты программируешь.
>>1905890 > даже php выглядит php почти копия джавы, один из самых ООП фулл языков (лол), там даже сраные трейты есть. Не стоит сравнивать языки тупо по функционалу, иначе тогда тот же питон соснет хуйца даже у пхп (речь о функционале из коробке, а не либах). Язык это инструмент, а не тупо набор функционала.
>>1905890 >>1905912 Нахуя вообще сравнивать go с высокоуровневыми языками? По выразительности и плюсы хуй соснут у php, блять. В байтоебском языке по определению не может быть слишком много сахара, иначе получится C++, в который понапихали столько, что выучить его нормально и жизни не хватит теперь, а на го ты через месяц уже сможешь написать 300кк рпс в наносек без утечек памяти и с многопоточностью.
>>1905929 > Когад го перестал быть высокоуровневым языком с сахаром Ну кроме абстракции над многопоточностью там сахара нет особо, можешь руками память чистить с вырубленным gc, поинтеры это реальные поинтеры в память, а не просто сахар и т.д. и т.п. Естественно он не такой низкоуровневый как плюсы или раст, он скорее что-то среднее между шарпом/жавой и сями.
>>1905916 Да высокоуровневый го язык, вы заебали уже. Ты будешь ебаться с байтами только если сам хочешь или пишешь свою бд или там json энкодер какой-нибудь. 99% времени ты делаешь то же, что и в php и в джаве и где угодно ещё: принимаешь запрос, валидируешь аргументы, пихаешь их в функцию бизнес логики, оттуда лезешь в базу, собираешь ответ, отдаешь его обратно.
Из "страшных низкоуровневых вещей" в го есть указатели (пиздец как страшно, на фоне того, что в php бывают nullable структуры, почти то же самое), слайсы (блять, ссылочный тип, указывающий на массив и автоматически пересоздающий этот массив с удвоением длины при необходимости), всё. Ни тебе арифметики указателей, ни тебе ебли с тредами, ничего.
Пехапешникам было бы тяжело переходить на го только потому, что сама пыха - очень кастрированный язык, не в смысле "плохо", а в смысле "заточено под конкретную задачу". Поэтому пехапешникам сложнее будет влиться в многопоточное программирование, игры со стейтом, настройку сборщика мусора и прочие рантаймовые тонкости. Но это не специфика перехода php->go, это будет работать на переходе с пыхи на вообще любой другой язык.
>>1906016 Лолчто, ебли с байтами нет, если ты не затачиваешь приложение под супер ультра мега хайлоад. В реальном бою ты максимум встретишь []byte, сконвертишь его в string и забудешь о том, что видел изначально.
>>1906151 На плюсах ты точно также можешь этим заниматься. Уровень языка определяет не то, что на нем иногда делают. В го ты будешь ебаться с тюнингом того-же латенси как чорт, если ты не работаешь в говноконторе (а на го их меньше, чем нормального хайлоада) - ты как раз будешь заниматься конкретно что байтоебством, при чем с обязательным знанием как тот-же gc и шелдуер внутри работает.
>>1906177 Да нихуя. Сколько уже людей приходили на конфы и говорили: нам был нужен перформанс, мы короч взяли го и просто написали нормально, ничего специально не задрачивали - и сразу попали в SLA.
Если тебе нужен такой хайлоад, что тебе в го нужно уже байтики ебать, то во-первых, сколько ты дрочил алгоритмы перед тем, как тебя взяли в гугл пили прохладную, а во-вторых, нахуя тебе го в таком случае, если есть плюсы или раст?
В го есть ряд вещей, которые реально тюнятся: - аллокатор, так в го сравнительно "дорогие" аллокации из-за того, что сборщик мусора не перемещающий, в итоге с дефрагментацией они на аллокациях борятся, решается переиспользованием объектов в узких местах через sync.Pool; - планировщик, если у тебя прям слишком много горутин. Решается профилированием и пулами горутин; - гц иногда захлебывается из-за слишком большого количества указателей, решается в первую очередь правильным их использованием (чтобы не держать миллионные мапы структур с указателями в памяти к примеру); И только если у тебя нужно хранить в рантайме десятки гигабайт, то нужно будет скрывать эту память гц с помощью магии.
Ну и дальше базовые вещи, типа, не ждать лишний раз, не выделять ненужное, использовать правильные алгоритмы и всё такое.
Как видишь, байтоёбства я не упомянул.
Может ещё можно вспомнить уже совсем конкретные оптимизации типа использования []byte вместо string из-за иммутабельности и лишних указателей, но это совсем мелочи.
> при чем с обязательным знанием как тот-же gc и шелдуер внутри работает. Если ты не джун - то ты и так должен этого знать.
>>1906220 > Что это значит и как относится к байтоебству, если это контракт между сервисами просто? Ну грубо говоря, вы договорились, что твой сервис выдерживает 5000rps, а ты написал на php и он выдерживает только 500rps. Ты такой просто переписал его на go и даже не сильно тюнил, и он сразу вынес 10000rps, так что ты сходу выполнил договорённости, без лишнего байтоёбства.
>>1906228 Лол, ну давай, к тебе придёт клиент и скажет "я короч хочу сайт, чтобы он там миллион пользователей одновременно мог выдержать, а то опять тормозное говно мне сделаете". Если ты ему ответишь "давай я сначала накодю, а потом померяем", то он тебя нахуй пошлёт и меня наймёт и правильно сделает. Потому что я подумаю и выдаем ему реалистичное число, которое потом мы в контракт и напишем (прямо над чеком в миллион баксов лично мне). Бизнес логику напишу на чём угодно, а узкие места на том же го сделаю и нормально будет.
>>1906234 > Книжку хоть одну прочёл? Нет, я в озоне работаю уже больше года. Продемонстрировал одну из неочевидных фич и в шутку выебал Роба Пайка, а что не нравится? Могу себе позволить, т.к. знаю все такие детали языка.
>>1906239 Как я понял, тут дело в том, что массивы (и слайсы) в го хранят объекты, а не ссылки на них. Т.е. нужно знать размер объекта, чтобы делать то, что ты хочешь. Поэтому, тут никакие дженерики не помогут.
>>1906241 Но, почему то же самое не работает с указателями? У указателей тоже разный размер, или что?
>>1906286 >Как я понял, тут дело в том, что массивы (и слайсы) в го хранят объекты, а не ссылки на них. Т.е. нужно знать размер объекта, чтобы делать то, что ты хочешь. Не совсем так, в массивах и слайсах можно хранить как объекты, так и ссылки. >Поэтому, тут никакие дженерики не помогут. Это же типичная ситуация, когда дженерики как раз и помогают >>1906286 Указатели все имеют одинаковый размер, а вот интерфейсное значение и указатель - разное. Такой дизайн сделан сознательно, чтобы не прятать за магию операцию, требующую О(n) алокаций интерфейсных значений. Если тебе реально нужно преобразовать слайс объектов в слайс интерфейсных значений - сам напишешь лишние 5 строчек.
>>1905942 >поинтеры это реальные поинтеры в память, а не просто сахар
Не совсем: https://golang.org/doc/faq#stack_or_heap . TL;DR : арифметика указателей инкапсулирована в самих конструкциях языка. Переменные созданные в скоупе функции, лежат на стеке если они хранят небольшое количество байт и на них нет указателей или они есть но не выходят за пределы скоупа функций. Иначе переменная создается в куче. Вот в C/C++, Rust есть голые указатели которые дают полный контроль над памятью.
Какой же ебанутый майндсет. https://golang.org/doc/faq#assertions "Глупые программистишки не отличают ошибки, которые нужно обрабатывать, от дебажных ассертов, поэтому мы их не сделали))0"
>>1906450 >>1906447 А зачем они нужны? Не проще код просто писать так, чтобы значения не пидорасило в разные стороны? По идее ты можешь написать функцию эту сам, или я ошибаюсь и ассерт - это больше, чем тупо функция, кидающая панику при неверном кондишене в её аргументе?
Если что у меня нет бэкграунда в сях, просто рил интересно
>>1906446 Почему не совсем? То, что хипа/стек определяется автоматически - не значит, что поинтер это не поинтер. Го это язык со сборщиком мусора, поэтому логично, что тебе не нужно руками в память писать. Но ты можешь спокойно сам аллоцировать память (правда в обход GC, т.е. придется еще позаботиться о том, чтобы за собой убрать), есть целые техники в го даже с этим связанные. Но если тебя не ебет перформанс в рот - проще довериться gc, он умён не по годам, так сказать.
>>1906453 В жс не поинтеры, там референсы, как в том-же ПХП. Просто имитация на уровне интерпретатора. Го например аллоцирует все на реальной куче и стеке, а жс вообще интерпретируется, там столько абстракций, что ахуеешь.
>>1906469 в курсе его мать родная в унитах хотела смыть жаль не поместился и пришлось по старинки ебашить кирпичом по голове но он почему то выжил и даже научился копировать хелло ворлды на луа и выдавать за свой аддон
>>1906532 Никто не спорит, компилятор и инлайнинги делает и кучу разных оптимизаций, пока до машинного кода дойдет - твоя программа вообще может быть не похожа по синтаксису на то, что ты изначально в своей ide наговношлепил.
Референсы - это поинтеры, которые компилятор/интерпретатор дереференсит за тебя в контекстах их использования.
> а жс вообще интерпретируется
Это если 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 оказывается должна считать количество символов А, которыми заполняется массив
Объясните мне это блядство пожалуйста. Я уже по горло сыт этими ебучими условиями и омерзительной подачей материала
>>1907868 Да, это довольно не очевидный момент - ридер это тип, который не просто имплементит метод, но еще и соответствует 6 абзацам комментариев над интерфейсом https://golang.org/pkg/io/#Reader
>>1907700 > жс макака, ты? > за связный список и какие есть проблемы с кешами процессора
Ты сразу же обосрался, ибо если бы хоть немного шарил в теме - понял бы, что связный список и проблемы с кешами - это один общий логический блок. В итоге ты половину фразы вырвал и обосрался.
>>1907995 >>1907868 > Объясните мне это блядство пожалуйста. А что не понятно то? Тебе просто нужно высрать 'A' в переданный массив байтов, вот и все. Проблема то в чем?
>>1908018 Под блядством я подразумевал омерзительную подачу материала. Это же тур по го, верно? Обязательный для вкатывающихся, как описано в шапке, да? Кал говна ёбаный. Материал нормально подается вплоть до описания методов. Потом кучкой идет чисто теория, где тебе надо посмотреть код и прожать кнопку далее и никакого закрепления работы с указателями, методов, интерфейсов нет. А это 80% от этапа по количеству шагов. Остальные 20% - это уже новый материал, краткий пример работы с ним или вообще его отсутствие и непонятное описание того, что от тебя хотят в шаге упражнения.
>>1907995 Спасибо. Только это должно было быть описано в туре, а не на дваче, лол.
Существует нормальная замена этому туру по го? Я дошел до rot13Reader и вообще ничего не понял. Я могу гуглить примеры, но это не то, как должно проходить обучение, ящитаю.
>>1908120 > Существует нормальная замена этому туру по го? Так он ахуенный же. По всем основам языка галопом пробегаются. Это же не онлайн курс, тур предполагает как раз ТУР, т.е. ОЗНАКОМЛЕНИЕ с языком. Если что не понятно - нужно гуглить, а не надеяться, что тебе в коротком туре объяснят все до самых мелочей.
А ридеры и райтеры - это тема специфичная, ты её поймешь только после пары крупных статей и самостоятельного дрочева.
>>1908239 Спасибо, приободрил. Но вообще это выглядит как требование решать рокетсаенс после биквадратных уравнений. Чуствуешь себя, будто отвлекся на минуту и пропустил объяснение, а объяснения и не было. Зачем тогда там упражнения... Ладно, я просто попозже вернусь к этому.
>>1908244 Да я сам ахуевал с этих reader/writer. Т.е. как работают понимал, но нахуй настолько низкоуровневая абстракция нужна - не понимал. А когда код начинаешь писать и встречать их везде - понимаешь, что это ахуенный способ перенаправлять потоки байтовой/строковой информации, например os.stdout это readwriter, как и файл. Короче очень удобная хуйня, когда начнешь с stdlib разбираться подробнее.
>>1908381 Ну я не видел ничего подобного в других языках (не считая чтения с файла), в го впервые столкнулся с настолько аскетичным решением и настолько утвержденным интерфейсом на всю экосистему.
Если кратко - в результате этого процесса принимается окончательное решение принимать ли диздок к ИСПОЛНЕНИЮ, поставить на паузу, или полностью отклонить. Отклонять конкретно данное изменение не будут, по сути сейчас происходит процесс окончательного утверждения дизайндока, возможно отправится на доработку.
>>1877742 → Чистый код читай. Если коротко - весь файл целеком ты все равно не запомнишь, неважно, там 2-3 экрана текста или 15, да и детали реализации методов не важны, пока ты не знаешь где и при каких условиях они вызываются (см любой доклад Григория Петрова, например вот https://www.youtube.com/watch?v=z5WkDQVeYU4).[РАСКРЫТЬ] Тебе в любой момент времени, когда ты смотришь на код, важнее как методы между собой взаимодействуют, а на вопрос - что они сами, непосредственно, делают, тебе в значительной мере должно ответить имя метода. Если же нужно поподробнее - тогда переходишь в скоуп определения функции и уже там повторяешь эти же действия. В большинстве случаев ты , вызывая fmt.Printf думаешь о том, что он выведет тебе что-то в терминал, а не о том, что оно распарсит строку формата, для каждого аргумента чекнет, имплементит ли он один из 3-х методов, меняющих поведение преобразование их в стрингу, в случае дефолтного флага из строки темплейта, если он отличается от дефолтного, скорректировать так же приведение к стринге и на его основании, составит из этого всего слайс байт и запишет этот слайс в специальный файл операционной системы, чтобы результат вывелся на экран.
Вопрос вообще по хаскелю, но его тред мертв и в нем тоже зеленые треды и думаю, они работают одинаково. Вот у шарпах и джсах есть async await. Когда есть длинная IO операция, например скачать файл, то чтобы не лочить основной поток, ты просто передаешь лямбду которая в качестве аргумента примет тот файл. В результате в этом же потоке можно выполнять другой код, а когда файл скачается, то что-то где-то запустит твою лямбду. А что с этими зелеными потоками? Они тоже эту задачу решают? Потому что в моем понимании, если вызвать такой поток с ио операцией, то у тебя просто будет два потока, один из которых просто будет простаивать и ждать закачки файла. Или рантайм дохуя умный, поймет что поток нихуя не делает и засуспендит его? А откуда он тогда будет знать, когда файл скачается и что надо снова запустить поток?
>>1910961 Ну смотри, есть процесс, у него есть очередь с горутинами, он берет из нее горутину и выполняет её в отдельном ос-треде, если горутина переходит в режим ожидания, то планировщик перемещает её обратно в очередь, переключает контекст и берет следующую. Так работает планировщик в го, если у тебя один процесс. В случае ели процессов несколько, то происходит кража горутин и тд. Как это работает в хачкеле, хз.
>>1910961 > А что с этими зелеными потоками? Они тоже эту задачу решают? Вообще ничем не отличается, можешь также ждать окончания в каком-то месте с помощью канала, можешь забить хуй и точно также выполнить по окончанию что хочешь. Можешь мьютексами жонглировать. Вопрос то твой в чем?
> если вызвать такой поток с ио операцией, то у тебя просто будет два потока, один из которых просто будет простаивать и ждать закачки файла ГОвнарь разраб выше частично прав. Планировщик ГОвна просто перекинет её в локальную очередь на том треде и вернет её к выполнению когда сисколл интерраптнется и вернет ответ. Но тут планировщик ГОвна и планировщик самой ОС вместе работают, ибо планировщик го тоже работает под ОС и ОС спокойно его прерывает. Сисколл тот же именно ОС интеррапт делать будет и т.д. Но да, если у тебя на одном физическом потоке 30 горутин, то та, где произошел лок по сисколлу - будет разлочена только когда разлочится этот сисколл, т.е. впустую гоняться на потоке она не будет. Точно также и с нетворк коллами и всем остальным, что ты ожидаешь и от самого планировщика ОС (правда на некоторых процах типа некоторых интеллов есть целые отдельные треды только для нетворк коллов, вот там чуть другая логика будет, но можешь хуй забить).
>>1911014 То есть когда в гринпотоке запускается ио операция, он помечается "спящим", но также создается и каллбэк, при вызове которого поток перестает быть спящим, и значит рантайм его в скором времени запустит, да?
А как вообще работает ио на лоулевеле? В моем понимании, в системные вызовы можно передать каллбэк, который в шарпе, к примеру, запускает юзерский код после слова await, а в го помечает тред как "неспящий".
И какие преимущества/недостатки у потоков? Я вижу только плюс - не надо помечать каждую функцию асинхронной, рантайм сам поймет какой поток спит.
>>1911350 > не надо помечать каждую функцию асинхронной Я про то, что в шарпе для каждой io функции есть асинхронный дубликат, типа File.Read() и File.ReadAsync(). Ну и если я придумаю свою асинхронную либу для хаскеля, то мне придется писать обертки для КАЖДОЙ io функции, тогда как с гринтредами тупо пишешь forkIO <youriofunction> и оно сработает.
>>1911350 > То есть когда в гринпотоке запускается ио операция, он помечается "спящим" Ну если грубо - то да, так.
> но также создается и каллбэк, при вызове которого поток перестает быть спящим Я не знаю что ты имеешь в виду под коллбэком. Когда в горутине происходит сис колл - происходит её блокировка, сразу же происходит подруб планировщика на физическом потоке (го запускает по одному планировщику на каждый реальный поток) и планировщик перемещает эту горутину в очередь и берет из этой очереди горутину, которая не "ждет" ничего, и кидает её на выполнение в этом же физическом потоке. Когда от ОС возвращается ответ (прерывание) по сис коллу - эта заблокированная горутина переходит в "готовые продолжить пахать на барина", при последующем прогоне планировщика - он может продолжить её выполнение (а может и другую, как сам вздумает своими алгоритмами).
Планировщик самого ГОвна работает схожим образом с планировщиком процессов в самой ОперационнойСистеме, в ОС обычно есть 3 состояния у процесса на физическом потоке - runnable (т.е. можно дать ему процессорного времени, т.е. закинуть на физ. поток), waiting (процесс ждет ответа системного вызова, его игнорим) и executing (процесс прямо сейчас выполняется на потоке). В ГОвне схожим образом работают горутины, но уже не на физических потоках, а в абстракции зеленых конкурентных.
> В моем понимании, в системные вызовы можно передать каллбэк, который в шарпе, к примеру, запускает юзерский код после слова await, а в го помечает тред как "неспящий". Чушь спизданул. Ты пиздец путаешь понятия, либо в теме не разбираешься. Я тебе расписываю как сам планировщик грин тредов в го работает, а не как на уровне кода и функций ты это пишешь. На уровне кода что в шарпе что в голэнге примерно одинаково эта концепция работает, только в голэнге она сильно проще пишется, есть только одно ключевое слово 'go', и все, пишешь 'go mamuEbal()' и твоя функция улетает выполняться асинхронно (не сразу, но в детали вдаваться не буду), никаких коллбэков. А для того, чтобы ждать её выполнения, чтобы эти прцоессы могли взаимодействовать между собой - уже есть разные средства в голэнге, начиная от каналов и заканчивая атомными операциями или мьютексами те же.
> И какие преимущества/недостатки у потоков? Чего? Что с чем сравниваешь, недостатки в сравнении с чем? >Я вижу только плюс - не надо помечать каждую функцию асинхронной, рантайм сам поймет какой поток спит. Я тебя не понимаю, что помечать, какой поток спит? Что в шарпе что в ГОвне работает все примерно одинаково, просто конструкции языка разные и в ГОвне это все очень просто реализовано, в шарпе больше головной боли, когда дело доходит до взаимодействия между несколькими потоками.
>>1911352 > типа File.Read() и File.ReadAsync() Нет, в ГОвне ты можешь любую функцию в любой момент времени выпустить в отдельный тред. Естественно если ты будешь пытаться одновременно писать и читать из файла - получишь пиздов, но я думаю это и так очевидно.
>>1911352 >>1911350 Я допер что ты хочешь. Если кратко - обе модели асинхронности (грин тредов) заебись, в шарпе сильно сложнее, но гораздо больше возможностей по настройке, а в голэнге прям очень простая, но и вариантов тюнинга очень мало. По скорости шо то шо это примерно одинаковы на дженерик задачах, но в шарпе потенциально в некоторых случаях можно выиграть, если будет специфичный сценарий, а в голенге дальше горутин не залезть по сути.
>>1911366 >Я не знаю что ты имеешь в виду под коллбэком. Я так называл системные прерывания. Только что прочитал что это. Мб с терминами я и попутал, но представлял я себе это именно так, как ты описал. >>1911369 >Нет, в ГОвне ты можешь любую функцию в любой момент времени выпустить в отдельный тред. Естественно если ты будешь пытаться одновременно писать и читать из файла - получишь пиздов, но я думаю это и так очевидно. Ну я же про это и говорю! В го ты перед тем что хочешь запустить асинхронно пишешь 'go', в хаскеле 'forkIO' или async, если стороннюю либу юзать > По скорости шо то шо это примерно одинаковы на дженерик задачах, но в шарпе потенциально в некоторых случаях можно выиграть Простой пример - он быстрее когда твоя задача потенциально асинхронная. Типа есть функция 'if (hasInCache) return fromCache else await returnFromDb()'; В го при вызове такой функции ты по любому создашь гринтред, тогда как в шарпе, с ValueTask если обьект все таки есть в кеше, даже на кучу нихуя выделять не придется.
1. Зачем в го возможность объявлять получателя метода по указателю и без? Почему всегда не передавать указатель на получателя в метод? Метод, привязанный не к указателю всегда будет получать копию структуры. Но какой это имеет смысл, если из-за этого теряется вся идея ООП-моделирования объектов с изменяемым внутренним состоянием? Если мне так нужны иммутабельные объекты, то мне все равно придется руками возвращать из функции копию объекта с новым состоянием. Два способа объявления методов только запутывают, тем более это странно для языка, который позиционирует себя как максимально простой и недвусмысленный. 2. Насколько вообще оправдано использование указателей? Когда я первый раз услышал, что в го есть и гц и указатели, мне это сразу показалось странным. Любые большие объекты - строки, слайсы, мапы - все равно передаются по указателям (ну или около того, главное, что их содержимое целиком не копируется) и на них и так работает гц. В то же время, любой возвращенный по указателю объект создает нагрузку на гц и эта нагрузка порой очень значительна. По-факту получается, что, скажем, гонять структуры между горутинами через каналы выгоднее полным копированием, потому что их передача по указателям просаживает перфоманс. Или я не прав? Во всяком случае мои простые бенчмарки показывают, что между двумя горутинами в канале быстрее передаются копии структур, а не указатели. В то же время невозможность через интерфейс вызвать метод с получателем-указателем не у указателя (преобразование, которое без интерфейсов делает компилятор) заставляет все объекты, скрытые за интерфейсами возвращать по указателям. Из-за этого частично мой 1-й вопрос: почему нельзя было убрать нафиг привязку методов к разным получателям, всегда передавать указатель на объект в метод (разумеется, гц тут задействован бы не был) и убрать вообще указатели целиком в unsafe? В коде бы стало гораздо меньше бардака и больше предопределенности.
>>1911432 > Зачем в го возможность объявлять получателя метода по указателю и без? Шоб было. > Но какой это имеет смысл, если из-за этого теряется вся идея ООП-моделирования объектов с изменяемым внутренним состоянием? А голэнг и не ООП язык, в нем всё - тип. > Если мне так нужны иммутабельные объекты, то мне все равно придется руками возвращать из функции копию объекта с новым состоянием. Ну да, как и во всех других языках, лол. А ты что хочешь? > Два способа объявления методов только запутывают Чем? Ресивер без поинтера - это аналог статическим методам в других языках. Чем тебя это запутывает? Или ты про то, что человек, использующий метод - не знает четко какой ресивер, пока не посмотрит? Так ему и не нужно знать детали имплементации в большинстве случаев, а когда надо - он все равно полезет в доки, а в голэнге документирование функции происходит прямо над методом. Соответственно любой, кто не знает что метод делает - сразу же все поймет глянув поп ап в IDE.
> Насколько вообще оправдано использование указателей? Только тогда, когда нужно отдать именно указатель, а не копию. Ты верно дальше подметил, что из-за ГЦ убивается весь потенциальный смысл использовать ссылки для ускорения выполнения, это и правда недостаток модели ГЦ. В шарпе тоже есть поинтеры, но там более удачная архитектура, не создающая столько оверхеда. > Когда я первый раз услышал, что в го есть и гц и указатели, мне это сразу показалось странным Но ГЦ есть во многих языках с указателями, почему только в ГО тебе это показалось странным? Нужно не на сам факт ГЦ грешить, а на то, что он медленно подбирает с хипы аллокации такие, в шарпе тоже гц их собирает, но гораздо шустрее. > В то же время, любой возвращенный по указателю объект создает нагрузку на гц и эта нагрузка порой очень значительна. Со слайсами (и остальными ссылочными типами) точно также, создается оверхед, ибо аллоцируется все в хипе. Таков путь. Но в защиту поинтеров могу сказать, что обычно их используют в долгоиграющей перспективе, т.е. твои бенчмарки с простым возвращением поинтера - это синтетический тест, заранее направленный на провал, ибо ты создаешь тысячу объектов поинтерами, в реальном коде ГЦ не будет их подбирать в большинстве случаев, т.к. они будут жить гораздо дольше микросекунд. Но, конечно, это не полноценное оправдание, а больше заметка, что все на настолько хуево, как в синтетическом бенчмарке с кучей аллокаций. > По-факту получается, что, скажем, гонять структуры между горутинами через каналы выгоднее полным копированием, потому что их передача по указателям просаживает перфоманс. Или я не прав? Если ты планируешь этими значениями дальше пользоваться, то перформанс будет обратно пропорционален времени от аллокации до сборки мусора. Если это рядовые флаги, которые ты чекнешь и забудешь - передавать по значению, если это объекты, которыми дальше будешь пользоваться - то ссылочный оверхед уменьшается (но не уходит полностью, естественно).
> заставляет все объекты, скрытые за интерфейсами возвращать по указателям Нет, возвращается интерфейс по значению. Просто интерфейс содержит в себе ссылку на конкретный объект. Это как слайс, грубо говоря, где сам слайс - это интерфейс, а массив - это объект. Но да, от оверхеда это не спасет.
На самом деле мне вообще не нравится сахар в го, когда дереференс автоматически происходит, мне было бы гораздо удобнее самому дереференсить и интерфейсы и возвращаемые ссылки, ибо как раз из-за такого сахара и появляются недопонимания типа твоего. Интерфейс в го - это тип, конкретный такой тип, и относиться к нему нужно как и к другим типам, никакой магии особой за ним нет, кроме компилятора.
>>1905210 (OP) >лучший в мире язык Обосраться просто. "Лучший в мире язык" Полистал тут на досуге мануал по Го и охуел. Что это за уебство? Язык сам по себе мощный засчет свой многопоточной модели но сам код это что-то с чем-то. Вот что за наркоман придумал экспортировать имена по заглавной букве блять? Что это и главное - нахуя? Почему я не могу как нормальный человек писать export перед переменной? Можно делать "голый return" блять, в любом нормальном языке конструкция return без ничего возвращает null, тут же она блять вернет объявленные в теле функции переменные, ебануться, подозреваю за такие return-ы без ничего надо сразу увольнять нахуй потому что обмудку видите ли было лениво записать явно переменные var можно писать при объявлении а можно и хуй забить, заебись, TS на норм проектах уже давно не скомпилится если такое вытворишь, но в "лучшем в мире языке" это с какого-то хуя является фичей ООП парадигма не юзается, только вот и функциональщина тоже на уровне говна
>>1911891 > Язык сам по себе мощный засчет свой многопоточной модели но сам код это что-то с чем-то. Так на хаскель переходи, там тоже гринпотоки. И дженерики есть, круче чем в любом другом языке.
>>1911891 На мнение такой жалкой хуйни как ты мне абсолютно похуй, жаль твою мать что она не смыла тебя в туалет когда ты кубарем вывалился из её пизды
>>1912020 а что хуевого-то? в сигнатуре функции же объявляется название возвращаемой переменной. не говоря уже о том, что можно сделать непустой return, явно присвоим значение возвращаемой переменной. имхо, удобно
>>1913289 > сложить числа в массиве > в питоне нет массивов
Хуя познавший вселенную затирает про свой любимый питон. Шизик, ты бы хоть типы в своем языке выучил, прежде чем сраться за то, кто где лучше. Хотя сам факт, что ты пришел серить в чужой тред этой хуйней - говорит о тебе, как о человеке низкого интеллекта. Так уж и быть, на первый раз простим блаженного, но больше не пиши сюда, чмок :*
>>1913289 Зато конкурентность и паралелизм удобно имплементировать. А в питоне такая ебень с этим asyncio, так ещё и GIL, пиздец просто, постоянно приходится узкие места на С переписывать, я бы тебя понял если бы ты противопоставил Джаву какую нибудь. А про сумму ты вообще хуйню написал, в ML алгоритмах её конечно часто используют, но мы тут байтоёбим и круды шлепаем, кто-то сервисы всякие интересные пилит, пока что ни разу не приходилось использовать сумму массива, на столько часто, чтобы мне понадобилась функция sum. Покормил зелёного.
>>1913364 >это цикл for для суммы массива... Блять, пистонисты и го-дрочеры совсем там уже пизданулись и отучились прогать как белые люди? жс-бог решает такую задачу максимально нативно в 1 reduce
>>1913309 > в питоне нет массивов Это бы ты для начала подучил хоть сколько-нибудь матчасть. Охуеешь узнав что list на самом деле нихуя не linked list а динамический массив блять
>>1913623 > матчасть Хуясть. С точки зрения программиста на питоне это именно список, а implementation-specific детали - это не про синтаксис языка, а про его реализацию. Так можно дойти до того, что и массивов как отдельной сущности не существует, это просто несколько ячеек подряд в памяти.
>>1913623 > динамический массив Какой же ты тупой... Список в Питоне не является массивом, даже динамическим. В питоне это не динамический массив, а кастомная хэш мапа с хэш функцией, это даже не массив значений, это массив ссылок на значения, а из-за типизации питона сам масив уже начнет появляться чуть ли не на уровне интерпретатора d6. Да, где-то там на каком-то из нижних уровней это действительно динамический массив, но только после нескольких шагов нормализации, да и не может там не быть массива, даже под хэш массивами пхп в Си уже идут массивы с аллокациями, лол.
>>1913621 >>1913611 Как там сосется, когда даже если обложился линтерами и тестами по самые яйца - твой код может в любой момент послать тебя нахуй, да и то только в рантайме на проде? Чисто ловите кайф там наверное, когда каждый пук надо дебажить через принт, чтобы ей богу все нормально работало :3
Пиздец, стоило мне просто добавить fmt.Spritf(...) с одним параметром и я от пик1 перешёл в пик2. Это что за залупа? В самой программе просто гоняю байты по каналам, а с помощью spritf форматирую.
Я лично свичнулся из TS в Go и очень доволен. Есть, конечно, в TS вещи, которые мне реально очень нравятся - например, перегрузки методов - такого никогда не будет в Go, но это нормально, что языки не похожи между собой, в этом-то и суть создания нового языка. К слову о перегрузках в TS - они там работают не так, как в каких-нибуть крестах, где на каждый перегруз своя реализация. Нет, в TS - у тебя на уровне типов несколько сигнатур, а на уровне реализации - эта одна и та же функция. Это очень удобно, когда тебе в метод нужно передать либо один аргумент, а второй - оставить пустым, либо - наоборот. В итоге правильность вызова твоего метода проверяет компилятор и тебе не нужно отдельно внутри метода проверять, все ли правильно передали и падать, если нет.
>>1913674 Линтерами обложился а про тайпинг забыл как линтер что-то покажет связанное с типами если ты эти типы не указал? первый раз с динамической типизацией дело имеешь?
>>1914040 Какой тайпинг? В питоне его нет, есть только аннотации, игнорируемые интерпретатором и доступные через рефлексию. Даже в пхп тайпинга больше, чем в Питоне. Под линтерами и статический анализатор понимается, если ты не в курсе. Иди пердантик подтягивай да юнит тестами обкладывайся, манька.
>>1915911 Ээээ блять куда ты лезешь лол тебя сожрёт, что за нахуй? Норм же пакет был. Нужно почитать что там нахуевертили. Чую без Роба Пайка щас революцию устроят и весь язык перелопатят.
>>1915911 >>1915988 Почитал ишью. Тогда заебись, раз перенесли в более подходящий пакет методы. Сам постоянно ахуевал почему в ioutill столько хуйни разной.
>>1915993 >Сам постоянно ахуевал почему в ioutill столько хуйни разной. А по тому что это сама суть helper/utill файлов/пакетов - это всегда ебаное нагромождение никак не связанной между собой хуйни, хорошо если оно хотя бы достаточно абстрактное и универсальное но зачастую - нет. У меня на проекте тимлид если такое видит - не позволяет замержить PR, и правильно делает.