С чего начать:
- В обязательном порядке проходим Go Tour:
https://go.dev/tour/welcome/1
- Читаем документацию прямо по порядку (пункт "Learning Go"): https://go.dev/doc/
- Ознакамливаемся с общим roadmap по изучению языка и сопутствующих инструментов: https://github.com/Alikhll/golang-developer-roadmap (постоянно обновляется сообществом)
Литература:
- Донован, Керниган "Язык программирования Go"
- Также хорошие книги для начала: https://www.golang-book.com/ и https://www.practical-go-lessons.com/ (веб-версия - бесплатная и хорошо подходит для новичков в программировании)
- Книги из списка https://github.com/dariubs/GoBooks
Полезные ресурсы:
- Сборник паттернов и инфы по микросервисам: https://microservices.io/
- Обновляемый список с пакетами: https://github.com/avelino/awesome-go
Прошлый тред:
>>3052664 (OP)
просто хочу разобраться
>Почему ровно такие же программы стали жрать в десятки раз больше ОЗУ?
Во всём виноваты индусы. Нация, которая не может научиться надевать презервативы, тем более не может научиться писать хороший код. Предлагаю зафорсить понятия pajeet-driven development и kumar-written code. Хорошо же звучат.
>>3120090 →
>у тебя там хард
А чем это плохо? Надо нормально писать софт, чтобы работало даже без твердотельника.
Да вы заебали со своими паджитами. Если Кумар -- это хотя бы настоящее имя, то паджит -- это набор букв.
Индусы могут писать нормальный код, проблема в том, что в Индии все родители шлют детей быть юристами, врачами или программистами.
Чтобы называться юристом или врачом, надо лицензию, и для этого надо сдавать экзамен. Чтобы называться программистом не надо нихуя. Поэтому в программисты идут два типа индусов: те, кто к этому предрасположен, и самые тупые, даже тупее назаровских волков. И вторых просто дохуя, потому что самих индусов целый миллиард.
К счастью, подавляющее большинство этих тупых индусов недопрограммистов сидят в Индии и пишут что-то для своих индусских компаний.
>Индусы могут писать нормальный код,
Двачую. Поддержиаал код за индусом. В целом - норм.
1) Это не go way.
2) Если появится аналог спрингбута то зарплаты обвалятся как в джаве.
>Если появится аналог спрингбута то зарплаты обвалятся как в джаве
Представление об экономике у пограммистов...
Чел, зарплаты обвалятся совсем по пругим приинам - вкатунов в голенг станет слишком много. Обфуксация кода не спасет. Вкатуны не имеют представления что хорошо, а что плохо в коде. Можешь у спросить пыхарей.
А раз зарплаты обвалятся, рано или поздно, в будущем ты будешь за еду пыхтеть над тоннами уникальной для каждого проекта легаси лапши.
>паджит -- это набор букв.
Я знаю. Но у них все имена примерно так выглядят. Недавно git blame показал, что автор очередной строки говнокода в проекте — Sandeep. Да и слово pajeet хорошо употребимо, когда нельзя сказать streetshitter или curry nigger.
>индусов целый миллиард
Почему их целый миллиард? Надеть презерватив не судьба? Это элементарное действие. Если они это не могут, то писать хороший код тем более.
>>3121658
So soy.
>>паджит -- это набор букв.
>Я знаю. Но у них все имена примерно так выглядят.
Это обзывательство уровня чурок, чухонцев, хохлов, бульбашей. Впрочем, тебе, видимо, нормально:
>streetshitter или curry nigger
Потому что ты наци говно.
>>индусов целый миллиард
>Почему их целый миллиард? Надеть презерватив не судьба?
Ты тупой? Почему славян целых 300 млн? Надеть презерватив не судьба?
Это элементарное действие. Если они это не могут, то писать хороший код тем более.
Появился уже, время вылезать из манямирка. Изобрели урезанную дажву - самое время изобретать урезанный спринг бут к ней. Гоферы переизобретают шаг за шагом джаву и гордятся что это "не джава".
>наци говно
Осторожнее, так можно соевым молоком поперхнуться.
>Почему славян целых 300 млн
Русских миллионов 150, для такой территории ни о чём. И они вымирают. А индусов всё прибавляется и прибавляется, только в качество не переходит никак.
>чухонцев
С чухонью приятнее работать, они хотя бы белые.
Перекатился из джавы в го потому что прикольнее задачи, мне больше по кайфу переизобретать велосипеды чем круды клепать
Так а велосипеды-то твои в конечном счете что делают? Create Read Update Delete?
https://go.dev/tour/methods/9
>Для примера, на С и GTK такая программа весит 17 Кбайт.
А если всё статически слинковать?
Ты сам начал письками меряться. Ну так меряй в одинаковых условиях. Иначе на джава можно хеловорлд в килобайт уложить.
> паджит -- это набор букв
https://www.urbandictionary.com/define.php?term=Pajeet
>>3133054
Почему в каждый гошный тред приходят залётные и начинают жёстко троллить тупостью?
Если залетел в энтерпрайз, то го тебе нахуй не нужен.
Он для системной разработки, где ебля с памятью как в си/плюсах нинужна + нужны современные удобства: кромплатформенный билд, пакетный менеджер, не геморойное паралельное программирование.
Нуден энтерпрайз - шарпы/джава/тайпскрипт с нодой
>Он для системной разработки, где ебля с памятью как в си/плюсах нинужна
/0
Что это за системная разработка такая, где ебля с памятью не нужна и бинарники по 100 мегабайт норма? Линукс ядро может?
Более чем уверен, что ьы чуть ли не каждый день таким го софтом пользуешься.
Настолько шаришь в теме, что считаешь что без работы с памятью в системном никуда?
Полгода изучал мобилки, отпугнуло малое количество ваканмий, + 1 друг и подруга никак там работу не могут найти с гораздо большим опытом в обучении чем я. Их даже в стажёры на собесы не зовут. Вот я и решил не тратить время и с более менее знаниями Котлина пойти в бэк (правда на Котлине вакансий на джуна в бэк совсем мало)
РНР конечно же. Там и учить легче и вакансий больше, а требования ниже. В го ожидают, что ты уже знаешь какой-то стек и решил выучить его как второй язык. Потом из РНР можно будет перейти на го.
Это не одинаковые условия, а попытка нивелировать преимущества других языков по причине того, что го так не может.
Это в чем минусы?
На Go один хуй нужны минимум мидлы которые в прошлом так же хуярили либо на Java, либо на любой другой хуете
Объясняю. Если у тебя в системе работает Gnome, то значит уже установлены библиотеки GTK. Зачем тогда в каждый бинарь их зашивать и раздувать объём программ? Динамические библиотеки не просто так придумали.
Раз у тебя в системе стоит JVM, то значит уже установлены нужные библиотеки.
Поэтому Java побеждает с результатом 545 байт.
PЗачем вообше го использовтаь для десктопа? ты сначала почитай для каких целец язык создавался
А ведь и правда. Но там минус, что графические программы выглядят не нативно в системе.
Гуглу нужен был язык для синих воротничков, потому что они не могли осилить С++. Но получается, что го - это не полноценная замена С++, а только для веба и консолек, при том ещё и не эффективная, с большими накладными расходами на размер.
Для веба это лучший язык, особенно под микросервисы, + отличная многопоточка и удобное взаимодействие между горутинами
> не эффективная, с большими накладными расходами на размер.
У тебя странные понятия о эффективности
Разница в размере в 2000 раз - это странные понятия об эффективности? Видимо шутку про 128гигов про джаву пора переделывать под голанг.
Странно что в твоём понимании размер соотносится с эффективностью
Я ищу язык, на котором можно было бы писать эффективные программы под линукс. Бинари под сотню мбайт мне не подходят, так как занимают слишком много места. Я ориентируюсь на С, который генерирует бинарники в несколько кбайт для небольших утилит.
Ну так пиши на С, кто тебе не дает? Иди в тред Сишный и там жалуйся кек
А есть кросс-компилятор, который преобразует код на го в код на си?
main.go -> go-c -> main.c -> gcc -> main.exe
Ты дурак? У тебя в Го сборщик мусора, а в С ручное управление памятью. Как ты будешь кросс компилировать? А ещё легковесные треды управляемые рантаймом.
>на котором можно было бы писать эффективные программы под линукс
С/C++/Rust
В раст тоже бинари жирные от 500 Кб до 6 Мбайт на хеллоуворлд.
В линуксах сотни утилит. Представь сколько бы весила ОС, если бы их писали на голанге?
>эффективные программы под линукс
Под твой конкретный или под любой из дистрибутивов distrowatch?
Ящитаю что статическая сборка тут скорее плюч, чем минус.
Сейчас мода переписывать стандартные утилиты на голенг и раст. Я например пользуюсь fd и fzf
> Я ищу язык, на котором можно было бы писать эффективные программы под линукс
Если сетевые - go. Если низкоуровневые системные - с, с++, zig, rust в зависимости от знания языка и опыта который есть или который ты хочешь получить.
> Я ориентируюсь на С, который генерирует бинарники в несколько кбайт для небольших утилит
Размер бинарника - это самое маленькое что тебя будет беспокоить. Лучше подумай как ты будешь инструментировать свой код для поиска узких мест, например.
Писать новые проекты на C не рекомендую, получится ворох говна. Попробуй для начала разобраться в структуре и подходах какого-нибудь большого проекта, например в systemd. Но если твоя цель научиться писать на C большие проекты, ничего не имею против. Но ты должен принять, что на любую фичу ты будешь тратить существенно больше времени чем Ероха потратит на клон твоей утили на высокоуровневом языке с большими бинарниками, и пользоваться Ерохиным клоном будет проще.
мимо
Все шутки про джаву подходят по голенг, потому что это и есть урезанная джава
Зачем тебе кросс компилятор? Пиши сразу на си. Если тебе нужен кросс платформенный код - то тебе в джаву. А так очень сложно понять требования к программе.
Да.
gccgo -> exe - hexrays/ghidra.
Поможет ли тебе это хз.
Тепер нужен не кросс-компилятор, а транспилятор. Хочешь язык с таким - бери nim.
Эффективность не от языка во многом зависит, а от подхода к программированию. Можно убить С программу постоянными аллокациями в хип. Можно с умом написать так что джава летать будет.
В Pthreads можно задать размер стека (хоть 2КБ, как в горутинах).
Разве что у горутин собственный планировщик. Вроде ещё у Pthreads нет динамического изменения размера стека.
>Разве что у горутин собственный планировщик.
Так в этом то и весь смысл. Этот планировщик позволяет писать обычный последовательный код, без калбеков и прочей реактивщины. Но при этом он эффективно обрабатывает ситуацию с блокировками на IO и мьютексах.
>Этот планировщик позволяет писать обычный последовательный код, без калбеков и прочей реактивщины.
Чего? в Го вроде нет async/await, просто вызовы асихронных функций, и ты не можешь писать асинхронный код как синхронный. Или что ты имеешь в виду?
По-моему тем что pthreads - это реальные потоки, а горутины - это "зеленые" потоки, управляемые рантаймом го
>Чего? в Го вроде нет async/await, просто вызовы асихронных функций, и ты не можешь писать асинхронный код как синхронный. Или что ты имеешь в виду?
Я имею ввиду, что ты пишешь обычный, последовательный код: вызываешь, по сети другие сервисы, читаешь из базы, ждёшь пока освободится лок. А при этом планировщик Го делает так, чтобы тысячи горутин эффективно работали поверх десятка поатвюформенных тредов. Снимая с платформенного треда горутины которые сейчас заблокированы.
Всё равно не понимаю. Планировщик ОС тоже может эффективно управлять pthread'ами. И те pthread'ы, которые чего-то ждут, не будут выполняться. Даже если во время работы pthread начинает чего-то ждать, планировщик ОС немедленно его переключает на другой, не дожидаясь истечения отведённого кванта времени.
У pthread'ов можно настроить приоритет и стратегию планирования на любой вкус.
И чем горутины лучше всего этого?
Просто лучше и всё, понятно?! Сказали лучше, значит лучше, нужно за трендами следить
переключение тредов дороже, если коротко. про context switch почитай
затем что ни надо поднимать JVM, если в облаках то это кошельку бьет(если у тя кучу дев окружений)
Судя по этим статьям https://www.baeldung.com/java-virtual-thread-vs-thread
https://amansingh3110.medium.com/what-is-the-main-difference-between-native-threads-and-green-threads-66c448696cf1
основных преимуществ 2
- зеленые треды не требуют сискола (syscall) для переключения между ними и поэтому дешевле
- у зеленых тредов нет отдельной памяти под стэк, они используют память родительского настоящего треда, и соответственно ОС не надо под каждый зеленый тред аллоцировать полноценный объем памяти, что быстрее и экономнее
>Зачем нужен го, если в джаве добавили виртуальные треды?
Ну теперь уже - чтобы поддерживать легаси на Го
У нас миллиарды. Тут вопрос в том, насколько долгие у тебя запросы, Если у тебя запрос работает 10 секунд, и 1000 звпросов в секунду, то у тебя уже 10к тредов нужно при синхронной работе.
>>3139058
>Планировщик ОС тоже может эффективно управлять pthread'ами. И те pthread'ы, которые чего-то ждут, не будут выполняться. Даже если во время работы pthread начинает чего-то ждать, планировщик ОС немедленно его переключает на другой, не дожидаясь истечения отведённого кванта времени.
Планировщик может эффективно управлять только CPU time, но он не может эффективно управлять памятью стека. И на самом деле это главная проблема.
Большинство горутин имеют стек в пару килобайт, и им не нужны мегабайтные стеки. Но есть несколько горутин которым нужны большие стеки. И менеджить это все на уровне pthread, очень сложно. Плюс есть системное ограничение на количество потоков, у тебя тупо ядро начнет захлебываться, да и создание нового потока процесс дорогой.
>>3139170
>- зеленые треды не требуют сискола (syscall) для переключения между ними и поэтому дешевле
Иногда - требуют.
> Preemption at asynchronous safe-points is implemented by suspending the thread using an OS mechanism (e.g., signals) and inspecting its state to determine if the goroutine was at an asynchronous safe-point.
https://go.dev/src/runtime/preempt.go
>- у зеленых тредов нет отдельной памяти под стэк, они используют память родительского настоящего треда, и соответственно ОС не надо под каждый зеленый тред аллоцировать полноценный объем памяти, что быстрее и экономнее
То что называется - implementation specific. Проблема испольхования стека хост треда, в том, что при переключении надо копировать текущий стек. В других реализациях аллоцируют в куче.
>Если у тебя запрос работает 10 секунд
то мне кажется что-то явно пошло не так
>то мне кажется что-то явно пошло не так
с кругозором у современных разработчиков. Которые ничего кроме крудов не делали.
У нас например система в том числе и линейные уравнения решает, и там расчеты могут и десятки минут идти.
В джаве на числодробилки выделяют тредпул платформенных тредов. А для сетевых запросов юзают виртуальные треды. В голованге не так?
Вы делаете это неправильно. Долгие запросы ставятся в очередь, а пользователю возвращается токен, по которому можно проверить статус задачи через апишку. Никто не держит сокет 10 минут.
Хм, это интересно, а можешь привести пример такого линейного уравнения, решение которого вполне оправдано занимает например 30 минут на современных процессорах?
>Никто не держит сокет 10 минут.
Это просто тупые крудошлёпы не понимают ничего в программировании
Серьезные дяди с опытом солидно и прочно занимают сокет и неспеша, качественно выполняют свою работу
Еще сходят неспеша чай попьют, а сокет - он не волк, в лес не убежит
Лол, любая задача на оптимизацию. Там система уравнений с ограничениями может считаться весьма долго.
https://habr.com/ru/companies/ruvds/articles/704326/
То есть ты не смог привести пример такого линейного уравнения? Ок
Ты тупой что ли? Системы линейных уравнений решаются методом гаусса, там сложность кубическая. Большинство методов оптимизации тоже имеют кубическую сложность. Для тупых это цикл в цикле в цикле for() { for () { for() {}}}
>. Для тупых это цикл в цикле в цикле for() { for () { for() {}}}
Это мало что значит и при должной оптимизации доступа к памяти из кэша процессора будет летать, и это не учитывая параллелизм.
Потому что ру локализация устаревшая. Сделай мр с актуализацией, и будет тебе русский язык
В Го нет не виртуальных тредов, но в Го вытесняющая многозадачность для горутин, так что и вычислительные треды нет смысла куда-то выносить даже если бы было можно.
>>3139544
>>3139670
Этот поц ещё будет нас учить, как делать коммерцию!
У нас между сервисами gRPC стримы, которые шлют результат по мере готовности. Плюс сам gRPC держит соединение и по одному сокету шлет все запросы и ответы. Так что ваши рестональные бест практисиз не очень релевантны.
>>3139665
Планирование ресурсов. У тебя есть некий набор локаций, в каждой из который есть набор ресурсов, и набор потребителей этих ресурсов. Тебе надо их наиболее оптимально их распихать по этим локациям с учетом разных ограничений: доступность специфичного ресурса, необходимость чтобы какие-то потребители были в одной локации и т.п.
>У нас между сервисами gRPC стримы, которые шлют результат по мере готовности
А это как возможно? Или в gRPC не нужно каждый раз открывать/закрывать соединение?
Типо прицепился к grpc соединению и можешь хавать от потребителя данные, которыми он пукает раз в минуту?
Да gRPC устанавливает одно сокетное соединение, а дальше через него шлет все запросы и получает ответы.
https://grpc.io/docs/what-is-grpc/core-concepts/#channels
>Планирование ресурсов. У тебя есть некий набор локаций, в каждой из который есть набор ресурсов, и набор потребителей этих ресурсов. Тебе надо их наиболее оптимально их распихать по этим локациям с учетом разных ограничений: доступность специфичного ресурса, необходимость чтобы какие-то потребители были в одной локации и т.п.
И ты хочешь сказать что это занимает 30 минут? Такие задачи за секунду максимум решаются. Поэтому я и просил собственно линейное уравнение, которое никто не может дать, а не примерно-размытое описание задачи.
>реши np задачу за секунду, гы
Какие же кодомакаки без диплома дегенераты, ей богу. Раньше такое бы писать постеснялись, а сейчас анальник гордится своей необразованностью. Иди жсоны грузи и не пытайся умничать.
не понял, а причем здесь полиномиальное время? полином может быть просто маленьким
Несколько десятков ресурсов, сотня-другая локаций и сотня тысяч потребителей вполне себе могут дать 30 минут расчёта.
>Поэтому я и просил собственно линейное уравнение, которое никто не может дать, а не примерно-размытое описание задачи.
Разумеется там не одно уравнение, а система уравнений, потому что для потребителя должны быть соблюдены все требования по ресурсам которых больше одного и требования по колокации.
Ахах, не туда и только заметил.
Мой лид что-то там пол-года уже пишет хуету-апи какую-то на говне и никак допилить не может, которую я бы написал на своём языке за неделю, лол.
мб проблема в лиде?
Смотрел курс по go от авито так там уровень абстракций не хуже чем на шарпах/явах и спрашивается нахуя тогда го нужен? если пишут так же по сути, только еще свои правила вставляют а наследования нет и дженериков нет
Для крупных прил + весь инструментал из под капота, не? а ваще мне пох кто че юзает главное чтобы кабан платил
чтобы не ебаться с разными длинами int под каждую комбинацию ос + архитектуры, 5ю конструкторами, сегфолтами и даблфришками.
Мне удобнее с помощью рефлектов собрать мета информацию и подсунуть её в шаблон. Но почему-то во всех примерах кодогенерации используют аст, хотя, как по мне, им пользоваться сложнее.