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, и правильно делает.
Предложили собес на позицию го-разраба. В вакансии было "знание основ python". Ну да бог с ним, хули там знать.
Созвон с якобы техлидом команды. С самого начала были звоночки охуенные в виде "30% на го, 25% на питоне, остальное - девопс". Ну ладно, тоже схавал, хули нам развернуть кубер с нжинкс. Дальше пошли охуительные вопросы в виде "как интерфейсы го на уровне компилятора работают", "что такое рантайм после моей тирады о компайл тайме и ран тайме он сказал, что имел ввиду runtime либу...", "системные вызовы gc". И ещё куча охуительных вопросов уровня "я вчера это узнал, доебу кандидата теперь" которые никаким нахуй боком к реальной разработке не относятся. Ответ о том, что мне предпочли другого кандидата поступил не через пару дней, а неделю. Охуеть. Чекнул профиль этого тимлида. Выпустился из вуза в 16-17 году, в пет проектах на тру щщах моды к каким-то ноунейм играм, стек языков мама не горюй, там начиная от java, заканчивая Lua, R и Хаскелем. На собесе было видно, что чувак не в курсе го ни капли, слов go-way и best practices не слышал явно. Я ещё с ним успел поспорить, он там где-то явно обосрался. Слава богу не прошел.
Да похуй на grpc. Ты просто обычный проект запили. Например чат на сокетах, делай сам, либо бери смотри пример типа "simple concurent go chat" и дополняй его. Вот просто садишься и пишешь код, как конструктор собирать. Если не знаешь ООП, пилить проекты лучше не начинать.
знаю ООП, ну как знаю. Писал игрушку небольшую(кликер) на плюсах, ну и был курс в вузе и игрушка была курсовой работой. Мне кажется, что я разобрался, + когда читал по Го 2 книги, в обеих в общем-то всё про ООП было понятно. Алсо немного непонятно, как же я тогда научусь строить базу проекта, если я буду просто допиливать что-то другое. Твоему совету я конечно обязательно последую, спасибо. Такое на гитхабе можно найти, верно?
>>1923131
Правда если ты хочешь как можно быстрее на галеру попасть и ты пока что не осилил даже grpc, то лучше бы тебе начать с низов. Понять как вообще го работает, сборщик мусора, планировщик и тд. Потом берешь книжку где тебе все разжуют по части web разработки. Видио смотри, короче, эта хуйня с опытом приходит. И кстати, настоятельно рекомендую разобраться с concurrency моделью языка, научись писать так чтобы было быстрее чем обычная, при этом избегая утечек памяти и горутин все это блять в книжках есть, даже больше.
Да, все ищется в гугле. Как таковой базы, в примерах нет, ты должен будешь потом сам все раскидать по модулям, по мере роста проекта учитывая основы ООП. https: //gist.github.com/kenshinx/5796276
Вот например, можно вынести Read/Write входящего подключения в отдельный модуль, добавить мапу подключений и тд.
>>1923312
Butcher M., Farina M. - Go in Practice
Правда она 2016, и много чего изменилось в плане GC и планировщика, но на первый раз сойдет.
Не слушай шизов сверху которые несут какой то пиздец. Харкнул на ебало долбоебу, который советует разбираться с gc и планировщиков челу который не может сделать простой круд. И долбоебам с книжками тоже харкнул.
Берешь, ищешь на ютубе видосы по типу: "Делаем хуйнянейм микросервис на го". Смотришь, и повторяешь за чуваком, не думая, что он делает. Как сделал, потыкал попробовал, что работает. Закрываешь проект. Создаешь новый и делаешь тоже самое, только уже самостоятельно, пытаясь вспомнить, что надо делать, подсматривая в свой код и видос. После этого придумываешь что то похожее и делаешь уже самостоятельно. После первого, ну или второго раза у тебя появится понимание, что вообще хотя бы можно делать, а дальше уже начинаешь заниматься оптимизациями улучшениями и прочей хуйней по типу gc
Изучаешь с азов язык. Затем изучаешь стандартные либы типа http, пробуя писать хеллоуворлды, когда понял как те же хендлеры и хендлфанки между собой работают уже можешь следовать совету этого долбаеба: >>1923667
Если ты сразу же последуешь его совету - получишь огромные дырищи в знаниях и будешь знать как что работает тупо по памяти, да и на собеседовании хуйца соснешь глубоко, когда начнут спрашивать базовые вопросы. Про то как все работает под коробкой знать не обязательно, но понимать как тот же слайс внутри работает - ты обязан, ибо без этих знаний твой код будет для тебя работать непредсказуемо. С другой стороны - как работает мапа под капотом ты знать не обязан, но то, что в ней элементы хранятся не упорядоченно - знать опять же обязан.
Короче в любом случае придется дрочить сам язык и его тонкости, иначе тебя любой адекватный вкатун обоссыт и работу ты будешь искать очень долго и "на удачу", что хуево само по себе.
> все умеют просто поставить задачу и просто её решить
Ну да. Типовые проекты для начинающих гуглятся буквально за 10 секунд. Решение задач - это суть твоей работы, если ты не можешь их решать в принципе (т.е. даже говнокодом лютым не можешь решить задачу для джуна) - то есть очень большие проблемы.
>>1923377
Таки тур только говнокодить тебя научит. Нужно еще учиться гуглить и отличать говноинфу (а-ля "пишем апи за пол часа" от нормальных гайдов) и фильтровать знания.
> Берешь, ищешь на ютубе видосы по типу: "Делаем хуйнянейм микросервис на го"
ДОБРЫЙ ДЕНЬ, ПРИСАЖИВАЙТЕСЬ
@
ЗНАКОМЫ С ИНТЕРФЕЙСАМИ Reader/Writer?
@
ПУК СРЕНЬК НЕТ
@
НУ ЛАДНО, А РАССКАЖИТЕ, ПОЖАЛУЙСТА, КАК РАБОТАЕТ СЛАЙС И КАКИЕ НЕОЧЕВИДНЫЕ МОМЕНТЫ СУЩЕСТВУЮТ? ЧТО ТАКОЕ ДЛИНА И КАПАСИТИ СЛАЙСА, ЧЕМ ОТЛИЧАЮТСЯ?
@
ЭММ, НУУ, ПУК СРЕНЬК НИЗНАЮ, НУ ДЛИНА ЭТО СКОЛЬКА ЭЛЕМЕНТОВ В НЕМ ВОТ ПУК СРЕНЬК
@
ХММ, ПОНЯТНО. А С ПАКЕТОМ HTTP ЗНАКОМЫ, ПРОБОВАЛИ ПИСАТЬ ЧТО-ТО?
@
ДА, КОНЕЧНО, ПИСАЛ МИКРОСЕРВИСЫ С HTTP И ВСТРОЕННЫМ СЕРВЕРОМ, ИСПОЛЬЗОВАЛ МУКС ИЗ ДЖИНА/ГОРИЛЛЫ/АЛЛАХА!!!!!!!!!!! СТРУКТУРЫ-СЕРВИСЫ, КЛИН КОД!!!!!
@
О, ОТЛИЧНО, КАК ПОДХОДИТЕ К ВОПРОСУ ЛОГИРОВАНИЯ В СЕРВИСЕ?
@
ЭММ, НУ, МММ НУ СОЗДАЮ ЛОГГЕР ИЗ ПАКЕТА НУ И ПРЯМО ВЫЗЫВАЮ В КОДЕ ГДЕ НУЖНО, А ЧТО?
@
ХММ, НУ ДОПУСТИМ, А ЗНАКОМЫ СО СТРУКТУРИРОВАННЫМ ЛОГИРОВАНИЕМ?
@
ЭММ, ПУК СРЕНЬК, НУ ДА КОНЕЧНО В БИБЛИОТЕКАХ ПИШУТ ЧТО ИХ ЛОГИ СТРУКТУРИРОВАННЫЕ
@
ПОНЯТНО, ПРЯМО КОНКРЕТНЫЙ ЛОГГЕР ДЕРГАЕТЕ В БИЗНЕС ЛОГИКЕ?
@
ПУК, БИЗНЕС ЧТО?
@
ПОНЯТНО, МЫ ВАМ ПЕРЕЗВОНИМ
То чувство, когда даже не был на собесе ни разу, только 1 раз кринжово поболтал с hr, которому пояснял, почему не хочу работать на плюсах и как там чёрт ногу сломит и конкуренция такая, что надо всякие спорт. программирования дрочить, на что получил ответ "а что для работы на го этого не нужно?"
Начал пояснять про то, что го сделан был для упрощения разработки и реально не нужно, в итоге "мы вам перезвоним"
> ДОБРЫЙ ДЕНЬ, ПРИСАЖИВАЙТЕСЬ
Куда присаживаться долбоеб, я итак дома уже сижу
> ЗНАКОМЫ С ИНТЕРФЕЙСАМИ Reader/Writer?
Нет, и не ебет. Да и вообще не нужна
> НУ ЛАДНО, А РАССКАЖИТЕ, ПОЖАЛУЙСТА, КАК РАБОТАЕТ СЛАЙС И КАКИЕ НЕОЧЕВИДНЫЕ МОМЕНТЫ СУЩЕСТВУЮТ? ЧТО ТАКОЕ ДЛИНА И КАПАСИТИ СЛАЙСА, ЧЕМ ОТЛИЧАЮТСЯ?
Все очевидно если хуйней не страдать
> ХММ, ПОНЯТНО. А С ПАКЕТОМ HTTP ЗНАКОМЫ, ПРОБОВАЛИ ПИСАТЬ ЧТО-ТО?
Нет, а нахуя?? Беру блять корпоративный фреймворк и хуе мое, какой вообще нахуй http, когда все на grpc
> О, ОТЛИЧНО, КАК ПОДХОДИТЕ К ВОПРОСУ ЛОГИРОВАНИЯ В СЕРВИСЕ?
Берешь и логгируешь, главное без задей мысли и json'а в логах, а то sre за гаражами пиздов надают
> ХММ, НУ ДОПУСТИМ, А ЗНАКОМЫ СО СТРУКТУРИРОВАННЫМ ЛОГИРОВАНИЕМ?
Берешь блять и по разным полям раскидываешь, охуеть рокет сайнс, вопрос достойный собеса
> ПОНЯТНО, ПРЯМО КОНКРЕТНЫЙ ЛОГГЕР ДЕРГАЕТЕ В БИЗНЕС ЛОГИКЕ?
Чо блять, а ты заново интерфейсы для логера в каждом сервисе хуячишь? Часто логеры на проекте меняете? ))0)
Ну и в норм компаниях уже есть платформенные либы для этого, так что да, беру и дергаю, но повторяю, главное без задней мысли
> ПОНЯТНО, МЫ ВАМ ПЕРЕЗВОНИМ
Это я вам перезвоню после таких вопросов
Ждун вкатун, ты? Узнал тебя по твоим шизоидным вопросам
мимо сеньор-помидор 300к/нс
у тебя видимо нормально всё с логикой. Где я сказал, что для го разработчика не нужна компетентность? Я лишь обозначил, что конкуренция в плюсах слишком большая и многие вкатываются через какой-то лютый пиздец, чтобы среди кандидатов выделиться. Алсо 1 разговор с hr в жизни, почему бы и не обосраться
Какую ссылку? Ты хочешь один изи гайд по всей внутрянке го? Совсем ебнулся? Это все разбросано на разные статьи. Что интересно - то изучай. Это программирование, а не сказочный мир с понями, надо самому изучать, в рот тебе никто просто так знания не засунет.
Какой брать веб-фреймворк если я нодадебил на перекате?
Что там есть мейнстримовое, но чтоб без особых языковых наворотов?
спасиба
Так а нахуя в го веб фреймворк? Стандартный сервер пишется в несколько строк кода, он уже является веб фреймворком. Единственное чего он не предоставляет - нормального роутинга, но для роутинга как раз уже стоит взять библиотеку. Вот у тебя и сервер. Хендлеры это те же контроллеры. Никто в го не юзает веб фреймворки (да и их нет по сути толком), ибо стандартные средства + пара либ и так ультра просто позволяют писать серваки.
Дело в кучи бойлерплейта, который при этом возникает.
А именно - весь роутинг может быть сгенерен по шаблону. Как и все говно-хттп хендлеры могут быть сгенерены из обычных функций.
handler(inputType) outputType
Задача фреймворка - избавиться от необходимости писать валидацию входного мусора и сериализацию выходного мусора.
Понятно, что существующие фреймворки говно полное, но не отменяет факта, что нужно создать нормальный. А нормальный в го возможен только на основе кодогена.
Не слушай долбоеба с фреймворками, это тебе не джава какая нибудь, где ты фактически на Java-developer, а Spring-developer. Можешь ничего не брать сначала и так попробовать. Для роутинга можешь взять https://github.com/go-chi/chi
И еще вот, принес вам нормального кодогена https://github.com/utrack/clay
>нормального кодогена https://github.com/utrack/clay
Выглядит как говнокод неконсистентный.
заебал дотнет я его уже наизусть знаю и просто тошнит, хочется чего то нового
Ну по сравнению с C#, Go выглядит как очень мелкий и straightforward язык который я осилю достаточно быстро, ИМХО.
Меня заебало то что С# по размерам раздули как C++ и одну вещь можно сделать 25 разными способами. Я то не против синтаксического сахара и возможностей, но когда работаешь с кодом ебанных дегенератов это выбешивает
мимо вордпресс боярин
>вордпресс
>боярин
>хайпа
А в чём хайп?
Go один из самых критикуемых языков за дизайн и возможности.
У Go довольная узкая специализация.
Go - это не Rust, не Dart и даже не Kotlin в плане хайпа, это тупо инструмент для решения задач (оч. прикладных и оч. специфических). Популярность Go сейчас не столько основана на рекламе, сколько на том, что он уже несколько лет широко используется в продакшене.
> Ну по сравнению с C#, Go выглядит как очень мелкий и straightforward
Это только на первый взгляд. На самом же деле каждый костылит свои собственные абстракции. Если в шарпе ты можешь что-то решить 24 способами - эти способы скорее всего будут через стандартную либу. В го же ты увидишь 24 способа, но все будут сделаны через свой собственный костыль.
После 2 лет кодоебства на Го я понял одно - нихуя там не один способ решения проблемы, как любят говорить. Их миллиарды, блять.
> А этот тут причём?
Говноязык от которого все плюются, кроме группы фанатиков
> Отличный язык.
Безвыходное говно на прототипах без ООП с ебанутым приведением типов и прототипами вытекающими из жопы, на котором чтобы нормально писать - нужно изучить книгу ебанутых решений и подводных камней. Ну да, отличный язык. Поэтому доля тайпскрипта больше натива, лол.
> Для того, чтоб понять в чём у них проблема - нужно погрузиться внутрь. Проблемы Go валяются на поверхности и их не пинает только ленивый.
Не нужно погружаться. Легаси функциональщина и $_POST в пхп и один взгляд на синтаксис раста - уже ред флаги поднимает. В голэнге на поверхности только отсутствие дженериков и своеобразная обработка ошибок. Да и то, это не столько косяки, сколько СВОЙ ПУТЬ прямо как у России!!!
> Короче - нюфань плиз.
Ну я хоть писал и немного изучал вышеупомянутые языки, а не просто языком чешу, как ты.
Ну мне посоветовали на дваче учить пхп вместо питона, потому что меньше конкуренции и вообще это лучший язык для вебни. Я и выучил! Сдавал тестовые на ларавеле, а по факту вот посадили на вордпрес. И хули, оказывается почти весь рынок пыхи такой.
Я мечтаю выбраться с этого дна.
>Проблемы Go валяются на поверхности и их не пинает только ленивый.
Так в этом и проблема, что их пинают только те, кто на нем не пишет. Если ты на нем пишешь в продакшене, что тебе конретно не хватает и какая там прям реальная проблема?
Я могу только сказать, что не очень удобно ебаться с пустыми интерфейсами и ловить из за них несоотвествие типов в рантайме, а не на этапе компиляции
>Говноязык от которого все плюются
>Поэтому доля тайпскрипта больше натива
>один взгляд на синтаксис раста
>$_POST
Это и есть "чесать" языком. Каждый пункт просто высер мимокрока, особенно про $_POST в php и про тайпскрипт кринжатура.
>Да и то, это не столько косяки, сколько СВОЙ ПУТЬ
Ну да, у го "свой путь", а у других языков "ред флаги".
>Ну я хоть писал и немного изучал вышеупомянутые языки
Хеллоуворлдщик, плиз.
>>1926379
>Так в этом и проблема, что их пинают только те ...
Поэтому он и один из самых критикуемых.
Ты ни одного аргумента не привел, я же привел первые попавшие в голову. Любой человек поймет эти претензии, а не будет хуйню нести как ты. Какой нахуй свой путь? Это рофл был, деревянный ты мой. Го точно также косяки имеет. Но он не самый критикуемый, а просто критикуемый. Питон жоще критикуют, чем Го, лол, о чем речь?
> Go один из самых критикуемых
Гугл и все найденные статистики шлют тебя нахуй, Go один из менее критикуемых, получается, лол. https://appetiser.com.au/blog/the-most-loved-and-hated-programming-languages-according-to-developers/
Я имею ввиду из новых языков. К слову, Rust там вообще нет? Вау.
Я уж молчу про то, что чем популярней язык, тем он более disliked по этим статистикам.
>>1926398
Проецируйщий долбоёб, я ни слова не сказал про нравится/не нравится. Я таким образом о языках не высказываюсь. Конкретно мне, например, Go нравится, я на нём пишу. А вот тебе нужно головой думать, а не жопой.
Хватит рваться на полтреда.
> К слову, Rust там вообще нет?
Есть, лол.
> Я имею ввиду из новых языков.
ЭТА ДРУГОИ? Ты изначально просто пизданул, что он один из самых критикуемых. Тебе сказали, что наоборот один из самых любимых. А ты теперь жопой виляешь.
> Проецируйщий долбоёб
Что проецирующий? Ты сказал, что его все критикуют, я сказал, что нет и привел тебе подтверждающую статистику. Иди нахуй с треда, ты слит.
>>1926368
>Говноязык от которого все плюются, кроме группы фанатиков
Ты скозал? Это вот твои "аргументы"? В чём поинт?
Если функциональщина для тебя эта сложна, то маме с папой жалуйся на свой iq, а не нам.
>без ООП
О боже. Без ооп? Правда? Да как так можно?
Долбоёб берет язык без ооп, костылит на нём ооп и жалуется что всё работает через зад.
>ебанутым приведением типов
Это единственная годная претензия к языку со слабой (!) типизацией.
>Поэтому доля тайпскрипта больше натива, лол.
Нет, не поэтому, а из-за типов, возможности их проверки во время компиляции и удобства поддержки разношерстных модулей внутри проекта.
ООП там так же прикручен гайками сбоку. Что, конечно, людям с ооп головного мозга доставляет проблем.
>$_POST
Недостаточно просто высрать из мозга слова, они должны иметь смысл. Что $_POST? Что у тебя с ним не так? Ты знаешь зачем он там? Почему он такой?
>один взгляд на синтаксис раста
Это тоже "аргумент"?
>Не нужно погружаться
Конечно не нужно, ты ведь хеллоуворлдщик. Ты и так во всех языках разбираешься. Ты мог бы высрать любое говно, которое обсуждают часами в растотредах, про уб, про неработающих борроу-чекер, про долгий компилятор, сырое комьюнити (на крайняк), но ты высрал только то, что видел - синтаксис на картинках.
>немного изучал
По мемам?
> Есть, лол.
>
> The Most Disliked Programming Languages:
> VBA – 75.2%
> Objective-C – 68.7%
> Assembly – 64.4%
> C – 57.5%
> PHP – 54.2%
> Erlang – 52.6%
> Ruby – 49.7%
> R – 48.3%
> C++ – 48.0%
> Java – 46.6%
> Scala – 41.7%
> Bash/Shell/PowerShell – 40.5%
> F# – 38.3%
> HTML/CSS – 37.8%
> SQL – 35.9%
> Dart – 33.7%
> JavaScript – 33.2%
> C# – 33.0%
> Go – 32.1%
> Elixir – 31.8%
> Clojure – 31.7%
> Swift – 30.8%
> WebAssembly – 30.5%
> Kotlin – 27.4%
> TypeScript – 26.9%
Чукча не читатель, чукча писатель?
> ЭТА ДРУГОИ?
Да, это "другои".
>Ты изначально просто пизданул, что он один из самых критикуемых
- да, я так считаю.
>Что проецирующий?
Свою тупость. Я не рассуждаю об инструментах, как о людях или товарищах. Они у меня не вызывают эмоции. Мне похуй на твои эмоции по поводу каких-то языков, и мнение хомячков тоже мне не интересно. Язык и язык. Есть свои плюсы, есть свои минусы. А у тебя от этого рвёт. И ты это приписываешь мне гринтекстом.
>Питон жоще критикуют, чем Го, лол, о чем речь?
>>1926397
>Go один из менее критикуемых, получается, лол
это неправда
https://insights.stackoverflow.com/survey/2020
У этой статистики та же проблема, что и у той, которую кидал ебаклак выше.
> % of developers who are developing with the language or technology but have not expressed interest in continuing to do so
Она не оценивает насколько язык зрелый или насколько давно появился, какая у него доля популярности. Грубо говоря, если огромное количество народу попробует JS и большинству он не понравится, то язык будет на дне. Но если узкий круг программистов попробует Rust и он понравится большинству, то этот язык будет самым любимым вот уже 5 лет подряд.
>В го же ты увидишь 24 способа, но все будут сделаны через свой собственный костыль.
Ну не скажешь. Например есть много способов считать из одного io.ReadWriter в другой, например через буффер из bytes.Buffer, или из bufio.Buffer или просто через массив байтов, или io.Copy. И все это будет правильным. Хотя смотря как ты определяешь "через свой костыль".
Полиморфизм. Допустим тебе нужно держать в объекте открытое соединение, как сделать так, чтобы можно было только писать в подключение, но не считывать из него? Ну ебашишь поле с типом io.ReadCloser. Или ещё круче, ты можешь создать свой класс который будет имплементить методы Read и Write, сможешь пихать свой класс в любые методы из стандартной либы которые принимают на вход итерфейсы Reader/Writer. Чисто берешь пишешь io.Copy(fileReader, твой_класс_с_подключением), если Read имплементировал нормально, то все данные из подключения запишутся в файл, ахуенно как по мне.
>>1927343
Красноглазый, совсем ебнулся вкатуну сразу за сети мозги засирать? Приведу гораздо приземлённее пример - логирование. Любой логгер может писать в любые штуки, реализующие Writer. Соответственно ты можешь туда хоть файл передать, хоть os.Stdout (вывод в консоль), хоть Аллаха. Плюс ты можешь сделать io.MiltiWriter(file, os.Stdout) и получить комбинированный Writer, т.е. твои логи теперь будут и в файл и в консоль одновременно писаться. Свои реализации редко нужно писать, ибо это по сути байтовый стриминг. Хотя ты можешь свою реализацию Writer написать, который каждый лог будет тебе СМС на телефон отправлять, лол. Хотя пример хуевый, но ты понял о чём я.
Потом через switch обрабатывает часть с "/команда". Есть у кого пример, как это реализуют нормальные люди, или как такое гуглить ?
Потому что знание соискателем именно твоего стека маловероятно. Поэтому тебе придется задавать вопросы не про код, а про принципы - ну там, как в языке реализована рефлексия, как написать мидлварь авторизации, и как отказоустойчиво сделать запрос к веб апи. Если ты не джуна ищешь, гонять программиста просто по коду - это все равно что математика заставлять подставлять в уравнения циферки.
Так в том и дело, что видя требование опыта в твоем стеке, соискатель не придет, т.к. вероятность совпадения крайне невелика. Это не петон, где широкий выбор между django, flask и кустарщиной. И вопросы это уровня мидла, т.к. джун, по определению, ведомый, и архитектура не его уровень - если у тебя такими вопросами занимаются джуны, они или оверскиллнуты и уже смотрят в лес, или твой прожект скоро придется закапывать из-за завала говнокода.
Та больше ты паттернов знаешь, просто ты не знаешь что это паттерны. Ответь на такой вопрос. Вот ты хочешь создать класс(на псевдокоде) который называется EmailMessage.
У эмэйла может быть адрес откуда, адрес(а) кому, могут быть или не быть прикрепленные файлы, может быть или не быть тема(title), может быть текста. Ну ты понял. Как бы ты конструировал класс? Через конструктор посылая new(null, null, make_array(hui, pizda))?
Или как?
Так же, должен ли класс EmailMessage иметь метод send, или лучше когда отправляет сообщение какой-то другой класс?
Вопрос немного не по Го, но просто вот прям с точки зрения паттернов и ООП как бы захуячил?
я не >>1930166, но суть примерно такая да, есть абстрактный план по достаточно высокуровневым темам, иногда есть пара-тройка конкретных вопросов/задач/пунктов, которые надо обязательно спросить/покрыть, чтобы по форме обратную связь дать, а там дальше как пойдет, какое настроение будет у собеседующего
я например, когда собесы веду, мне не очень интересно упарываться в язык, конкретные технологии (базы/очереди), вот этот чувак хорошо накинул >>1930614, я так пробовал, но народ в среднем люто тупит, и нифига не вывозит, поэтому я сейчас переключился на архитектуру:
вот есть бизнесовые требования, например, надо написать сервис, который будет рассылать имейлы, и дальше - какой наружу интерфейс предложишь пользователям/для интеграции, какие технологии выберешь, как очереди организуешь, как шаблонизировать контент будешь, как это все масштабировать, какие метрики снимать, как по ним понять, что инцидент произошел, как гарантировать exactly-once доставку в реальном мире с таймаутами, фейлами и ретраями, вот например у тебя вот этот сервер умер, че делать, или внезапно все тупить@тормозить стало, как искать/что делать, сколько твое решение будет стоить, где можно съэкономить ну и все в таком духе
(рассылка имейлов, это просто наугад, можно проектировать и корзину товаров в онлайн магазине и мини-инстаграм/вк и банковский сервис по переводу платежей и вообще на что фантазии хватит)
и на таких кейсах сразу хорошо виден и опыт и кругозор и алгоритмы и паттерны
Щас прохожу собесы, был в озоне, деливери клабе, селектеле и еще нескольких менее именитых. По сути достаточно несложные вещи (сразу скажу у меня небольшой опыт другого языка и в целом не вкатун). По сути вопросы достаточно банальные - классика а-ля как слайс устроен, как горутины под капотом работают, вот тебе такой-то код, почему он не работает и как сделать рабочим, на знание каналов задачки, по сопутствующим вещам (а-ля напиши sql запрос с джоином или объясни как индексы работают), в одной компашке спросили средней сложности по system architect вопросики (но джуна про это спрашивать не будут в любом случае). В целом - достаточно просто, если ты не валенок. Алгоритмическую задачку дали пока только один раз (в озоне), да и та сводилась к вариации merge sort (а точнее только части про merge). Много из этих вопросов найдешь в гугле спокойно по запросу "вопросы на собеседовании Go", лол. Ничего прям серьезного, никаких графов тебя обходить просить не будут, если ты про это. Но да, ты должен хорошо разбираться в языке (например знать про gpm модель асинхронности), поверхностно тот же OSI знать, например.
Единственное заметил, что чем меньше и шаражнее контора - тем более абанутые процессы найма (например тестовые задания предложили ток 3 раза, причем дебильные, я нахуй послал их), а еще эти ебаные опросники - сразу дропай, красный флаг дноконтор. Что удивило - на паре собесов оказалось, что го используют как системный язык и пишут всякие сетевые хуйни, мне казалось это язык больше для смузистов микросервисников, а оно вот как.
в моей картине мира, формат, который ты описал это что-то, наверно уровня бесправного стажера-trainee, ждуны полноправные участники команды - он участвуют в груммингах и в декомпозиции задач и на постановке задач от бизнеса, и если самостоятельно делал какую-нить хуйню, то велком на демо рассказывать
но, нельзя не уточнить, у меня нет ожиданий, что джун сразу придет с рабочим решением, тем не менее, имея требования для несложной фичи, какое-нибудь решение он все таки должен предложить, а дальше уже старшие либо аппрувят это решение, либо вместе дорабатывают
А почему там Echo и Fiber обязательные, а самый популярный Gin желательный?
Потому что научись читать
>Personal must know
>Потому что научись читать
Сука, вы все тут такие ебанутые или только ты один?
>в озоне и тиньке используется chi
Ой дебил блять, ты еще и разницы между фреймворком и роутером не понимаешь.
Олсо, что там в этих парашах используется вообще не показатель, потому что все делается на собственных костылях написанных бывшими пхпшниками. Вчера ты пишешь на зенде, а сегодня ты разработчик платформы.
> разницы между фреймворком и роутером не понимаешь
Понимаю, только посмотри внимательнее на картинку по твоей говноссылке
>>1932838
> потому что все делается на собственных костылях написанных бывшими пхпшниками
ты скозал?
В чем проблема то? В файбере и эко есть роутеры внутри, т.е. ты и эту тему зацепишь вместе с ними, не все же пишут на сыром http с одним chi. Ну да, я бы еще желтым выделил chi и убрал бы выделение у файбера, но это уже собственные хотелки. Можешь мр к ним оформить, если так глаза мозолит.
Мимо составитель шапки треда
Попробовал по этому https://habr.com/ru/post/420035/ гайду сделать хеллоуворд на gtk, вроде бы безболезненно. Думал сложнее будет. Посмотрим как дальше получится.
А теперь такой вопрос. Господа, вы ебанутые? Вы так ошибки обрабатываете? Я до этого момента был свято уверен что go - самый красивый ЯП и я свяжу с ним свое будущее. Мне в нем нравилось абсолютно все, но это полнейший пиздец. Я правильно понимаю, что альтернатив сейчас нету? Если так, то планируются ли в последующих версиях какие-то try/catch или что-то около того?
Этот хуесос так и не ответил на мой вопрос про email. Хотя он достаточно простой. Но интересный. Ждуны довольно многие шарят что
https://www.tutorialspoint.com/laravel/laravel_sending_email.htm
ТАК
Или так
https://www.baeldung.com/java-email
Это пижже чем
https://www.php.net/manual/en/function.mail.php
Вот так блять.
> вот есть бизнесовые требования, например, надо написать сервис, который будет рассылать имейлы, и дальше - какой наружу интерфейс предложишь пользователям/для интеграции, какие технологии выберешь, как очереди организуешь, как шаблонизировать контент будешь, как это все масштабировать,
Хорошо что ты понимаешь что проектирование интерфейсов это самое главное в архитектуре любого большого приложения.
То что ты скинул, это самые основы. Тип имел ввиду, что нужно сделать например сервис у которого будет некое API и работать будет в гошном стиле. Типа запилить очередь из которой будут брать мейлы воркеры и отправлять, при этом я бы сделал для каждого воркера отдельное подключение к smtp серверу. С такой архитектурой выходит у нас своеобразная маштабируемость, то есть можно сколько хочешь воркеров наспавнить и хоть какая-то отказоустойчивость, если один воркер падает, спавнишь другого. Потом идет дохуя всяких нюансов в виде централизации логов с каждого воркера, так ещё чтобы оно все в файл или редис пиздячило, множество ретрай функционала который нужно будет прикрутить, ещё бы было хорошо если запилить свой API для воркеров, чтобы их можно было добавлять, удалять, останавливать под это можно уже целую либу запилить.
Какой то бессвязный поток сознания получился, но надеюсь ты поймешь.
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
if err != nil { return nil, err }
Так трай кетч и гошные ошибки - примерно однохуйственно. В голэнге ты также можешь написать общий хендлер всех паник, если нужно (например для того же сервера, чтобы залогать паники), а ошибки чекаются точно также, как чекаются и эксепшены, трай кетч/ иф, технически вообще поебать.
Хз почему так приебываются к этой теме в го.
Сосачую.
Может эта хуйня довольно многословная, но если ты не мудак она даёт 95% гарантию что все ошибки обработаны. Остальные 5 на паники приходятся и явное игнорирование подсказок ide.
Как же я охуел когда после питона запустил говно код. Один два запуска - код работает.
На питоне же пока в дебаге поймёшь че там тебе прилетает и какие методы есть...
Папаня взглянул глазком на Го и побежал обратно в уютную Ноду
гавно а не язык
https://github.com/golang/go/issues/43651#issuecomment-776944155
> Если это такие плохие языки, то зачем на них написали столько библиотек и фреймворков, которые всем нужны?
Немного не так.
У языков разные обстоятельства их юзать.
Обстоятельства для С++:
"У меня половина ОС написана на крестах и почти весь прикладной софт - естественно я на нем напишу свою вундервафлю, плюс он очень производительный и имеет ручное управление памятью."
Обстоятельства для пхп:
"Блджад, каждый второй хостинг предоставляет возможность запускать скрипты на перле через cgi, но перл индусское говно - нужно что-то такое же, но попроще для понимания и возможности без ебли накидать страницу - окей, пхп так пхп. Далее популярность пхп на хостингах дальше делала это дело."
> Почему разработчики этих всех нужных библиотек и фреймворков не выбирали хорошие языки для своих задач?
По-моему там было наоборот - типы сначала решали задачу, и в последствии, чтобы сделать решение проще - лепили свои либы и фреймворки.
Не претендую на истину в первой инстанции
>Блджад, каждый второй хостинг предоставляет возможность запускать скрипты на перле через cgi, но перл индусское говно - нужно что-то такое же, но попроще для понимания и возможности без ебли накидать страницу
Уже был питон, руби, которые так же запускались на шаред хостингах. Так что выходит, пхп лучше прочих скриптовых языков, или авторы фреймворков и библиотек идиоты и выбирали плохой язык, вместо хороших?
>По-моему там было наоборот - типы сначала решали задачу, и в последствии, чтобы сделать решение проще - лепили свои либы и фреймворки.
Все поекты которые стояртся вокруг каки-то индустриальных фреймворков на пхп пускаются на vpsках, а не шаредах, а потому опять не ясно, зачем выбирать пхп, если можно было взять что угодно.
Да и без фреймворков. Что насчет фейсбуков и контактов, например? Они так сразу пилились под собственные сервера.
>Почему разработчики этих всех нужных библиотек и фреймворков не выбирали хорошие языки для своих задач?
А не было их тогда, родной. Никаких.
В 2000ых был C++. C++ был обратно совместим с C, таким макаром любой проект мог начать писать C++ код и жить неплохо. Но это тянуло за сомой многие печали.
Разименование null это это UB, int foo(int i) может принимать double. Ты можешь написать foo(7.26) и оно автоматом переведет тип.
Это очень неудобно, сэр.
Раст намного лучше как язык. В нём нет захламлённого ООП и есть немного нежное FP-style кода как в javascript.
Типы более логичные u8 это ансайнд с 8 байтами, u32 это ансайнд с 32 байтами. Никаких char, long ing. И типы точно обозначены, а не implementation defined.
Ошибки rust очень удобные и по ошибке всегда можно догадаться что поправить. Ошибки в шаблонном коде в крестах читать невозможно.
Однако, раст это новый язык, а кресты это старый костыль который получил популярность потому что был один такой и был совместим с Си.
И никто сейчас на rust не перейдет просто потому что красивый язык.
Бизнес, дорогой мой, и на COBOL писать будет потому что кобол у них раньше был и он прекрасно совместим со стапрым коболом.И 90% кода серверов участвующих в финансовых операциях и в гос секторе США написано на коболе. От так вот.
>Так что выходит, пхп лучше прочих скриптовых языков, или авторы фреймворков и библиотек идиоты и выбирали плохой язык, вместо хороших?
Не так. Ruby это великий язык и rails это монументальный фреймворк. Но идею не запатентуешь, MVC фреймворки стали появляться как грибы после дождя.
Проще перенести свой фреймворк на PHP, чем заставить команду учить рубин
Типизация там самая пиздатая, строгая динамическая утиная.
Так же очень консистентность. Язык полностью ООП, а значит не будет помойки типа непоняток как в крестах что std::string имеет метод .length(), а например split нет. Он есть в отдельной библиотеке буст и как чистая функция с параметрами.
Никакой постоянности.
Очень простой читаемый синтаксис.
Там сотни причин. Дизайн языка очень удачный, но он не похож на остальные и поэтому переучивание требует отдельного времени.
и пойми что плохой язык это не значит, что на нём ничего хорошего не напишешь. Напишешь, просто это не так прикольно будет и всякие pitfalls будут. Фреймворки часто заглаживают, кстати. Тот же laravel заглаживает многие некрасивые части PHP.
Я имею в виду что-то типа питоновского factory boy. Или самописный какой-то прием, но короче чтобы не писать sql-фикстуры и golden-файлы.
Вот как пример есть такие либы:
https://github.com/bluele/factory-go
https://github.com/romanyx/polluter
https://github.com/nauyey/factory
Только они какие-то невнятные, заброшенные и звезд мало.
Моки это про другое (или это подъеб типа такой?)
Но ок, допустим даже моки. Вот представь мок должен вернуть большущую структуру в которой для тестов мне нужно установить один специфический параметр. Я должен описывать всю эту ебучую структуру. А мог бы написать
resp := BuildMyMockResp(OptBlahblah(false))
//On(...).Return(resp)
которые возвращает дефолтную структуру, в которой переопределено единственно важное для меня поле Blahblah.
Это просто один из примеров, для тех кто сейчас скажет, что мне мешает сделать такой хелпер.
Я прост не знаком с фабриками этими в Питоне, подумал ты прост не знаешь про моки. Тогда хз, никогда не юзал таких штук в тестах, наверн в го это руками все прописывать нужно.
> Но ок, допустим даже моки. Вот представь мок должен вернуть большущую структуру в которой для тестов мне нужно установить один специфический параметр
В го структура создается с zero value, тебе не нужно каждый параметр прокинуть при создании, только необходимые инициализировать. Но я не до конца понял что это за фактори бой, добавил в закладки, может рил полезная техника при тестах.
>>1941539
По идее можешь сам фабричную функцию запилить, и данные генерить через фейкер: https://github.com/bxcodec/faker
Канеш не тако сахар как в питоновских или пхпшных фабриках, но думаю сойдет. Хуле, привыкай к бойлерплейту гошному :3
>>1941135
Да боже, заверни какую-нибудь нейросетку на путхоне (которая котов генерит, да что угодно) и напиши все это дело в обертку с гошкой, чтобы задачки летели в кафку и обрабатывались в фоне и т.д. Вот тебе и ахуенный проект. Можешь и регистрацию сделать с отдельным микросервисом под аутентификацию, и внутр все по gRPC гонять. Написал и пошел за 300кк мидлом работать. Секретов то никаких нет.
> Ну напиши конкретнее, что а Питоне из ООП хуёво, и что в Руби пиздато, сложно что ли, блять?
Нахуя в питоне ООП, если там даже тайпхинтинг не проверяется без доп либо или статических анализаторов? О каком ООП речь, когда дженерики и абстрактные классы - это либа. Тех же интерфейсов нет, а множественное наследование - ваще ржомба.
> тайпхинтинг не проверяется без доп либо или статических анализаторов
Тайпчек и стат анализ это всегда отдельный компонент системы. Разница в том, что в одних тулчейнах для языков тебе его поставляют из коробки без права выбора, в других ты можешь выбирать. Это холивар уровня, что лучше винда или линкус.
>Тех же интерфейсов нет
Какие интерфейсы в динамическом языке?
>множественное наследование
Антипаттерн. Как и само наследование.
В php неплохое ООП, я согласен. Я бы даже сказал что сейчас PHP8 будет получше питона для веба. Лично моё мнение.
>>1942356
Пчел, там нет модификаторов доступа, private public protected
Абстрактных классов и интерфейсов тоже немного. В руби интерфейсов нет, но там другой ООП. Там есть it_behaves_like что делает то же самое. This нормального нет. Неудобо там писать ООП. Питон это язык с игрушечным ООП, руби это язык на котором кроме ООП ничего нет. Он именно ООП язык
Понимаешь, товарисч. Хороший язык отличается от плохого именно тем что в нём ты более-менее защищён от ошибок.
А тут нет.
Вот в питухоне хорошо то что там анальные пробелы и один кодстайл на всех. А вот эта хуйня неоч.
> Ну тогда и до какой-нибудь жабы доебись, там через рефлексию тоже можно.
Я ваще не фанат дзявы. Я в принципе считаю что по-хорошему должно быть как в C# с unsafe. Поставил unsafe и тут уже храни тебя бог, сам семе еблан.
В дзяве хотя бы надо рефлексию в попу ебать, а не просто так.
С таким же успехом я не понимаю чё джависты гонят на типизацию в PHP. Называй переменные $int_MyVariable и всё заебись будет. А за типизацией сам следи.
Приватные переменные в питоне, что с двух подчёркиваний, защищены, интерпретатор делает специальное переименование.
То есть функцию защиты от случайного перезаписывания или переопределения эти переменные-методы делают полноценно. Само собой, если пользователь цель поставит, он сломает. Но случайно или по недосмотру не будет.
Вот protected уже в языке нет, исключительно соглашение.
>$int_MyVariable
Венгерская нотация) В цмсках встречается, причем в самых говняных. Сейчас так никто не делает, обычно пишут докстринги с типом и иде подсказывает, а сейчас с версии 7.4 можно уже у переменных класса указывать тип.
public int $myVariable;
А функцию можно было типизировать с версии 7.1 вроде.
private function zalupa(int $lenght, string $name): array
И также как в джавашарпах можно в качестве типа указать имя класса или интерфейса.
Я тут с Си треда подвалил к вам.
По-моему инкапсуляция не нужна. Структуры в си можно вкладывать в начало и делать из этого наследование структур. И ещё на переменные можно вешать cleanup attribute, и будет работать 1 в 1 как defer.
Golang прям видно что восторгался рядом расширений из gcc.
из под винды реально?
гребец озона не палится.
Во-первых, ты в своем озоне джсон будешь гонять до конца веков, какие тебе линкедлисты?
Во-вторых, у озона слишком много обсеров. Чего только их летняя "школа" стоит, просто лол, не смогли чекер настроить и в манямирке сидели до конца, пока их на Хабре не попустили. Вспоминаем ещё пароли плейнтекстом, лмао.
Яндекс того хуже, анальный собес, который потратит неделю жизни минимум ради офера в 1.5-2 раза ниже рынка. Ну а потом бесконечные велосипеды, шизоменеджеры и принудительно-обязательные переработки по праздникам/выходным бесплатно.
И это всё я не выдумал, вы хотя бы по хабру тому же походите, там анальники уже давно все расписали.
Как-то кандидат сказал, что отказывается проходить собеседование, потому что ему привезли испорченный надувной матрас.
В озоне много серьезных разработчиков, через него прошло много специалистов. Конечно, будут и довольные, и недовольные, как и везде.
Аноним
19/02/21 Птн 19:17:24
№441