— В плюс-минус обязательном порядке проходим "Go Tour":
https://go.dev/tour/welcome/1 (как правило чтобы успешно перейти с знакомого языка на golang для старта этого достаточно)
— Читаем документацию прямо по порядку докуда будет не лень (пункт "Getting Started"): https://go.dev/doc/
— Если собираемся трудоустраиваться в веб – ознакамливаемся с общим roadmap по изучению языка и сопутствующих инструментов: https://github.com/darius-khll/golang-developer-roadmap (постоянно обновлялось сообществом); если собираемся не в веб – просто знаем что такой roadmap существует; в противном случае – ознакомление не требуется.
Литература:
— Донован, Керниган "Язык программирования Go" (внимания заслуживают девятая глава для понимания параллельности и тринадцатая про cgo и глубинную рефлексию, прочую же информацию легче найти в интернете)
— Также книги рекомендуемые для начала: https://go.dev/wiki/Books и https://www.practical-go-lessons.com/ (веб-версия — бесплатная и хорошо подходит для новичков в программировании, так же прим. перек. не путать книгу со справочником, поскольку в данном случае любезно предоставлены скорее справочные материалы)
— Книги из списка: https://github.com/dariubs/GoBooks (не читалось, осуждается `^_`)
Полезные ресурсы:
— Сборник patterns и info по микросервисам: http://microservices.io/
— Смотрим видео https://www.youtube.com/channel/UC_BzFbxG2za3bp5NRRRXJSw
— Справочник энтузиастов: https://go101.org/
— Практические уроки: https://www.practical-go-lessons.com/
— Обновляемый список велосипедиста с пакетами: https://github.com/avelino/awesome-go
— Здесь нужны старые браузеры: https://github.com/tucnak
Прошлый тред: >>3677844 (OP)
>С появлением ноды вебмакаки и вовсе обезумели и начали создавать несты нексты реакты вьюу ангуляры тайпскрипт, 100500 говнормок и тд. Как вообще люди додумались такой язык тащить кудато вне браузера?
Нода реально удобная была тогда, вокруг 2015 года. Она асинхронная, построенная на коллбэках, очень удобно обрабатывать сетевые события, например. Иногда правда всё это превращалось в callback hell. При этом высокоуровневая, удобно обрабатывать всякие JSON, есть система исключений. Довольно надёжная.
А альтернативы тогда были довольно слабые. Потом, правда, альтернативы подросли, ими стало возможно пользоваться, го причесали чуть-чуть (но не совсем, особенно тогда совсем не совсем), в питоне завели асинхронность async/await, тут начались проблемы у ноды, их стандартные библиотеки были под callback based подход, а не async/await, короче удобство испарилось.
Короче на момент 2015 реально хороший был выбор, но сейчас уже точно нет.
>Нода реально удобная была тогда, вокруг 2015 года.
Был гораздо более удобный и производительный груви с асинхронщиной из джавы, кучей сахара и настоящей многопоточностью.
Нода хайпанула исключительно на волшебном обещании одного языка для всего. Что оказалось пиздежом конечно, ведь на чистом джс никто не пишет и фактически под фронт с реактом свой отдельный диалект.
граховац здесь? как пилить микросервисы на гоу с грэсфул шэтдаун?
Ну через стаковерфлоу типа. Или хабр на худой конец. Там все расписано. Сигнальчик регистрируешь и дописываешь завершение работы приложения по приему этого сигнальчика. А также контексты можно поотменять/заканселить но это на своё усмотрение.
>но это на своё усмотрение.
Хуясе советы. Это первое что надо сделать.
Прокидываешь контекст из main настолько глубоко, насколько ты хочешь сделать грэсфул, в мейне ждёшь в горутине сигнал и по поступлению - отменяешь контекст
>>3758552 (OP)
Здравствуй, анон-гофер, прошу советов мудрых, хуи не предлагать, я уже насосался за свою жизнь.
Я вкатун, чуть меньше чем 3 года назад меня по чистой случайности взяли на работу кодомакакой и терпели, пока я научусь чему-то. Практические навыки я приобрёл и даже вроде какую-то пользу приносил. Фирма нынче лежит в предсмертном состоянии и руководство отпустило нас всех во взрослый мир хотя не все там овощи как я, были и грамотные специалисты и даже очень хорошие. Лет мне дохуя, под сорокет. Три месяца ем смотрю как на хх либо на отказы, либо на игнор. Иногда пытаюсь адресно кидать резюме на сайтах контор. Не было ни одного сраного собеса, резюме переписывал раза 3, в последней итерации по советам чувака, который лет 20 работает программистом. Самый край был недавно, когда я скинул резюме в контору, для которой по стеку я подходил просто идеально - молчание, через 2 недели вакансия уже закрыта.
1. В резюме пока не пиздил, т.е. честные мои два с половиной года практики и реальные вещи, которыми я занимался. Стоит ли переписать под популярный стек и накинуть себе сколько-то лет? Сколько?
2. Озон моментально отказы пишет, почему так?
3. Как искать вакансии, кроме как на хх?
4. Т.к. свободного времени у меня теперь много, то получаю фундаментальные знания, которых у меня не было, - учу книжки Таненбаума, архитектуру, go 101, задачки, postgres дрочу. Во время работы было как-то лениво, да и тяжело после кода и документации ещё накатывать что-то по профессии. Стоит ли такими вещами заниматься или сосредоточиться на заучивании типичных собесовских вопросов?
5. Любые советы приветствуются
PS Не пишите, плз, хуйню, типа иди обратно откуда пришёл или про успешных работяг. Во-первых, я всем сердцем люблю ту работу, которой я занимался последние 2.5 года, ничего подобного я на предыдущей работе не испытывал. Соответственно, биться за сохранение в профессии буду до последнего. Во-вторых, я пришёл со стройки, где руководил в т.ч. этими успешными работягами и нихуя хорошего там нет. Обратно тоже не хочу, ибо там сейчас ещё хуже чем в айти и ушёл я оттуда не просто так, работа специфическая, мне она не подходит.
>2. Озон моментально отказы пишет, почему так?
Потому что они сейчас завалены собесами сотрудников из компаний, которые вот-вот обмякнут (такой вот инсайдик)
Каких-то рабочих советов тебе вряд ли даст. Ситуация скорее безвыходная. Рабочих мест в айти сейчас практически нет, найм если и идет где-то, то это вероятно бигтех или редкая госуха. Причем как ты понимаешь тот же Озон и WB сейчас тоже в печальном положении находятся, а это были места, где ранее гошников нанимали в большом количестве.
Мне вообще из российских компаний только из Яндекса рекрутеры стабильно пишут и как будто только там идет найм нонстопом. Все остальные компании очень точечный найм сейчас делают, либо не нанимают вообще.
Вот такие дела. Цепляться за айти до последнего конечно можно, но с нынешним рынком труда ты вряд ли что-то найдешь. Я вот почти год без работы просидел, в итоге сдался и сейчас вышел на склад работать. Благо там всех подряд берут пока что, нет собесов и легко оформиться.
мимо бывший гошник с профильной вышкой 5 лет опыта на го, до того 2 года на питоне
>>3759751
Спасибо за инфу, анонимусы. У меня бывшие коллеги иногда находят себе место. Пока подушка есть - буду получать профильное самообразование и сычевать. Существование, конечно, так себе, но что делать.
ого! а тебе желток дали? почему уволили? похоже айти это не для тебя
Привет. Хочу использовать JSON-файл как БД для хранение нескольких однотипных структур с разным содержимым. Как открыть файл, добавить структуру и прочитать файл мне понятно. Трудность в добавлении последующей структуры.
Пример. Было:
{
"Id": 1,
"Description": "tse",
"Status": "new",
"CreatedAt": "2026-09-15T18:08:40.827863+03:00",
"UpdateAt": "2026-09-15T18:08:40.827863+03:00"
}
Стало:
{
"Id": 1,
"Description": "tse",
"Status": "new",
"CreatedAt": "2026-09-15T18:08:40.827863+03:00",
"UpdateAt": "2026-09-15T18:08:40.827863+03:00"
},
{
"Id": 2,
"Description": "44",
"Status": "new",
"CreatedAt": "2026-09-15T18:08:40.827863+03:00",
"UpdateAt": "2026-09-15T18:08:40.827863+03:00"
}
Подскажите, как это сделать.
Хранить в файле надо JSON-массив объектов, а не просто объекты через запятую.
В коде, соответственно, читать файл целиком в слайс структур и работать с ним.
Возьми себе ментора-хуентора, сделайте с ним линкедин, и иди собеситься на валютные удаленки
Если объем данных небольшой, можешь читать всё в память, добавлять что надо, а потом всё полностью перезаписывать в файл.
Либо писать JSON объекты отдельными строками, тогда добавляя строку ты добавляешь структуру потом соответственно обратно по строкам читаешь и склеиваешь в валидный общий JSON
Пока ищу работу работаю курьером в лавке, непыльно, но так продолжается уже полгода, надежд пока не вижу на работу
Ты про весь найм или только гошный? То бишь на джаву бессмысленно переучиваться?
А в чём принципиальное отличие го от жавы? Куда там переучиваться?
>А в чём принципиальное отличие го от жавы
Нет спринга.
>Куда там переучиваться?
Надо учится писать спринг самому руками.
Gemini выдал такой вариант, но на него ругается VSCode:
val := 42
val := "Строка " + strconv.Itoa(val)
Если объявить переменную как пустой интерфейс interface{}, то можно. Но это будет не как в питоне или JS, тебе потом придётся каждый раз вручную приводить типы.
Выходит, мне каждый раз надо создавать новую переменную, когда читаю данные с json, привожу их к структуре, затем использую jsontext.Value().Indent(), чтобы придать читаемый вид и для перегона результата обратно в файл. После нетипизированных языков это как минимум кажется лишним нагромождением.
В таких примитивных вещах он обычно не косячит. Ты наверное как-то криво его спрашивал.
https://go.dev/play/p/p7ndRmvFtsI
Ты можешь сделать структуру с полями разных типов, полем kind, методами, в т.ч. собственной имплементацией маршаллера, анмаршаллера и использовать sync.Pool для того чтобы не дрочить выделение памяти под новый объект и GC.
А нахуй тебя брать, если можно волчару за копейки и результат будет одинаковый
>Я вот почти год без работы просидел, в итоге сдался и сейчас вышел на склад работать. Благо там всех подряд берут пока что, нет собесов и легко оформиться.
Пиздец жирнота
Двоч не пропускает мое сообщение, поэтому прикреплю его фоткой, в целом там все изложил что да как
Сейчас что бекенд, что фронтенд, что какая-нибудь хитровыебанная инфра или сложные большие вещи типа движков СУБД/компиляторов - все это пишется ИИшкой практически в автономном режиме. Больше нет смысла нанимать человека на проект. Вот вообще нет смысла нанимать кого-либо. Профессия автоматизирована ИИ и с этим уже ничего не поделать.
Простые уже да. Сложные пока нет.
Фронтир модели типа Astra как раз начали на поляну инженеров конструкторов и электронщиков активно заходить, так как из автоматизации программирования уже выжали все по максимуму, но еще много есть инженерной работы которую только предстоит автоматизировать.
>Сейчас что бекенд, что фронтенд, что какая-нибудь хитровыебанная инфра или сложные большие вещи типа движков СУБД/компиляторов
По-моему после обсера Антропика с попыткой реализовать компилятор Си на Расте на Опус 4.6 (меньше 8 месяцев назад, если что) особо не пытались. Или ты можешь примеры привести компиляторов, которые реализовали так? Или движок СУБД?
Я напомню, что компиляторам Си больше 50 лет, а на гитхабе полно учебных проектов компиляторов на 10к строк, сама тема хорошо описана. Но на таком уровне не получилось.
Ты несёшь хрень про вещи, в которых нихрена не понимаешь. Сидел бы и срал в своём загончике здесь, а не разносил всё по чужим темам.
>так как из автоматизации программирования уже выжали все по максимуму
Если это максимум, но программистам можно выдыхать спокойно, рынку труда ничего не угрожает
>Простые уже да. Сложные пока нет.
Простые еще в 90е pcad разводил, кек.
>>3766103
>начали на поляну инженеров конструкторов и электронщиков активно заходить
Представляю, как их оттуда погонят ссаной тряпкой после первых исков с отзывом партий горелых приборов и жареных пользователей. Пользоваться средством разработки, которое дает гарантию не на отсутствие ошибок, а на их присутствие можно только в тех областях, где за это не поведут в суд и дают субсидии за "внедрение".
Смотри, когда кожаные делают какую-нибудь схему, и это в какой-то ответственной области, должны быть какие-то регламенты-протоколы проверки, что это реально работает как надо. Формальные системы тестов, расчётов, которые в любом случае нужно проводить. Почему нельзя эти же проверки-тесты использовать для того, что нагенерила нейросеть?
>Представляю, как их оттуда погонят ссаной тряпкой после первых исков с отзывом партий горелых приборов и жареных пользователей. Пользоваться средством разработки, которое дает гарантию не на отсутствие ошибок, а на их присутствие можно только в тех областях, где за это не поведут в суд и дают субсидии за "внедрение".
https://www.ixbt.com/news/2026/09/20/437153-ii-sam-sproektiroval-cip-dlia-ii-ot-zadaniia-do-rabocego-prototipa-za-dve-nedeli.html
https://www.cadence.com/en_US/home/explore/ai-chip-design.html
https://openai.com/ru-RU/index/openai-broadcom-jalapeno-inference-chip/
Уже все делают. В M5 Ultra 184 млрд. транзисторов, ты думаешь человек способен такое спроектировать без ошибок? Просто есть готовые блоки, есть формальная валидация, есть программная эмуляция, это все чтобы проверить спроектированный чип. Все это можно применять и к чипам которые делает AI и вообще ко всему что делает AI.
>В M5 Ultra 184 млрд. транзисторов, ты думаешь человек способен такое спроектировать без ошибок?
Так его человеки делали, кек. Работает - значит способен.
>>3766251
ИИ заботливо поясняет, что итоговый нейрослоп - слишком тугой ком кала. Если кто начал забывать, то в нормальной разработке код пишется так, чтобы его было легко и понятно читать, а не писать.
> Проблема «Черного ящика» при критических сбоях
Хотя система ALP закрывает более 95% тестов верификации коммерческими инструментами САПР, сгенерированный ИИ-код объемом в миллионы строк невероятно сложен для человеческого аудита. Если в глубоких слоях архитектуры проявится редкая, специфическая аппаратная ошибка (Edge Case), двум инженерам-архитекторам будет крайне трудно найти и исправить её вручную, так как они не пишут этот код сами.
>>3766251
>Все это можно применять
Можно, но не нужно. Никому в ответственной разработке не нужен сбойный инструмент, примерно как компилятор, который гарантировано лажает. Только для компилятора потом можно порякать про обновления, дорогое (нет) время разработчиков и купите больше памяти, а партию чипов обновить не получится, как и пофиксить вызванные ими аварии. АИ внедряют, где можно забить болт на результат, это симулякр-разработка. Если на аи и будут разрабатывать чипы, то какие нибудь типизированные грошовые esp-хи для хобби, они и сейчас сделаны на отвяжись из готовых блоков. С наклейкой aсhtung, ai designed.
>>3766222
>Почему нельзя эти же проверки-тесты использовать для того, что нагенерила нейросеть?
Потому что брут форс в таких тестах фигово работает, а формальные тесты опираются на логику, которая в случае аи неочевидна.
>ты думаешь человек способен такое спроектировать без ошибок?
Да.
Был такой процессор Zilog Z80 который стоял в популярном ZX Spectrum, его разрабатывал инженер Masatoshi Shima. После разработки этого процессора он начал работать над Z8000 ньюфаги не поймут. И в этом процессоре инструкции вместо микрокода, должна была исполнять жестко зашитая аппаратная логика. В теории это увеличивало перформанс, т.к. инструкции выполнялись за один такт. И снижало количество транзисторов, например Motorola 68000 содержал 68к транзисторов, а Z8000 17,5к. Но разводка процессора почти полностью вручную была крайне сложной задачей, тогдашние эмуляторы не справлялись с этим. И первые версии процессора были не пригодны для использования из-за аппаратных багов, а когда их всё таки исправили уже сам процессор был не нужен, тем более что он был не совместим по командам с Z80
Тем не менее людей все еще набирают, думаю основное падение спроса не из-за ИИ, а в общем из-за того рынок просел, грощей нема проще говоря. Сытые годы прошли
Если знаете похожие списки вопросов делитесь ссылками.
>>3766993
ПАЦАНЫ НЕ КАЧАЙТЕ ТАМ ВИРУС
В котором права категории С на фуру. Голанг в 2026 никому нахуй не нужен. Все вакансии - это или припизднутые агенства с требованиями 10 лет опыта на голанге, или ебанаты с аи дривен, которым надо написать пейпал за два дня. Кстати, они никогда не отвечают.
Я в хихляндии, пока проедаю запасы, ебал я воевать за коротышку. Как эта хуйня развалится, пойду учиться на фуру. Я делал дома ремонт, сантехника электрика вот это все, это пиздец. Целый день весь в говне жопой кверху, а заказы хуй найдешь и по факту заработаешь меньше курьера.
Илон Маск же постепенно выкатывает беспилотные фуры. Мы начинаем жить в будущем
Так он учит какому-то старому гавну. Я смотрел его курс скачанный с торрента, там толком нихуя информации нет, просто он показывает как написать 4 микросервиса и поднять кафку. Если в 24-25 годах были лохи кто это был готов купить, сейчас желающих уже нет.
Кстати всякие там Тузов и Балун тоже кажись разорились, не нужны больше их курсы по вкатыванию в Го.
А хули ты хотел он работал по сути в Озоне и Авито. В одном месте постоянно меняющася бизнес логика и скорее всего там наgoвнокодили всякой хуйни. А в другом месте параша которая распилила монолиты вместо микросервисов в наносервисы много чего до сих пор на пыхе и героически с этим борется. Смотрел тут его видео про то как он от скрипта дошел до бигтеха с сервисом по производству каких-то космических кораблей, у меня уже через 5 минут возникли вопросы и ощущался отрыв от реальности
>сервисом по производству каких-то космических кораблей
Ага, ну вот на этом примере он показывал как написать круд из 4-5 микросервисов на Go. В этом и был весь его курс по вкатыванию в голенк.
Сейчас надо учить людей агенты делать и в целом делать бабло на ИИ волне, а не сидеть продавать курсы где ты объясняешь как микросервисы руками писать. Их уже руками никто никогда писать не будет, а те люди, кто еще будет программировать без ИИ, это энтузиасты и прочие любители хобби, которые не его целевая аудитория.
>микросервисы через кафку
Я думал, эта хуйня уже закончилась, все заебались с очередями очередей и пишут саги.
>Я в хихляндии
Удачи, анонче. Хуй знает как вы там вообще держитесь, даже профессию нормально не сменить, потому что тцкотики пасут
Да там какой-то рафинированный дезодорированный дистиллированный в вакууме сервис. Вымышленный пример где у него все гладко и красиво вписывается в архитектуру, причём даже как-то работает со сторонними поставщиками. Я когда на это всё смотрел у меня на каждом этапе был вопрос если тут логика изменится или появится новое требование или проверка, что будет если при отсутствии чего-то у поставщика мы должны собрать детали из других материалов. Вроде как красиво раскидал все по разным полочками, попрятал везде логику, а по факту получил сервис, который сделает пук среньк в реальной жизни.
Другие видео типа с задач на собеседованиях та ещё хуета в плане решения
А где работа на внешних рынках осталась? Там такие же безработные сидят нынче.
>просто он показывает как написать 4 микросервиса и поднять кафку. Если в 24-25 годах были лохи кто это был готов купить, сейчас желающих уже нет.
хз, я с микросервисами не работал и кафку не юзал. плюс все эти ддд скрс и прочие паттерны прошли мимо меня. тупо контроллер - сервис - рипазитари и тесты на моках. ну и сервис в сервис и т.д.
У упомянутого выше Олега Козырева на канале, а на практике никто такой хуйнёй не страдает
А что делать, если константа нужна только в одной функции? Объявлять переменную?
1. Чтобы дать название. Например
>readData(parallelism)
более читаемо чем
>readData(5)
2. Чтобы не повторять одно и тоже значение несколько раз.
Никто не передает значения как во втором примере, мне кажется даже стандартный линтер на это ругнется. Это или переменная, инициализированная парой строк ранее в той же функции, либо что-то типо readData(config.X.Y.Paralellism)
Кстати, а будет ли каждый раз под эту константу память выделяться?
Ты тролишь? Вообще не будет, компилятор просто везде подставит значение. Если константа строка - память выделится один раз при запуске. Точнее, линух сразу зарезервирует X страниц памяти и где-то там в блоке констант будет твоя строка.
> Никто не передает значения как во втором примере, мне кажется даже стандартный линтер на это ругнется. Это или переменная, инициализированная парой строк ранее в той же функции, либо что-то типо readData(config.X.Y.Paralellism)
Не будет никаких ворнингов.
И вообще вызов функции с какой-то константой это общепринятая практика, например у тебя есть некая приватная общая функция с кучей параметров и флагов. И несколько публичных которые её вызывают с конкретным набором флагов и параметров.
>Кстати, а будет ли каждый раз под эту константу память выделяться?
Для таких вопросов существует Compiler Explorer
https://godbolt.org/z/19nPG86cE
Если не можешь сам понять что там происходит, спроси нейронку.
> я с микросервисами не работал
Ничего особенного, это куча простых джсономешалок, которые живут в ебанутом зоопарке исторически сложившейся архитектуры и общаются между собой кто по rest, кто по grpc, кто через брокер сообщений, кто в лес, кто по дрова. Вы назначаете многочисленные созвоны между командами чтобы обсудить как правильно друг другу насрать jsonкой. При этом их проще релизить, откатывать, шардировать и тестировать на стендах.
>кафку не юзал
Кто-то насрал джсонкой в топик на который ты подписан, запускаешь джсономешалку, это прям как ручка в апи. Также наоборот у тебя есть чего кому сказать срешь в нужные топики. Настройкой этого говна обычно занимается какая-то команда из SRE и архитекторов, тебе по сути слушать что надо и отправлять что надо, об этом обычно подробно расписано аналитиками в какой-нибудь внутренней вики.
>плюс все эти ддд скрс и прочие паттерны прошли мимо меня. тупо контроллер - сервис - рипазитари
Это норма, много где вообще никакой нахуй архитектуры, поскольку изначально нахуячили какую-то простую штуку, которая хаотично обрастала функционалом и спустя лет 5 выглядит как уёбище от которого дядюшка Боб словит инсульт если увидит краем глаза.
>и тесты на моках.
Какие нахуй моки. Поднимаешь базу, кафку и мок сервера в докере, потом заполняешь БД из dlya_testov.sql только потом можешь запускать тесты, которые прогонятся с 10 раза, но при этом в пайплайне все работает с первого раза
Короче нихуя сложного нет, а Олежек там рассказывает хуету далекую от практики, но при этом эта хуета хорошо продается.
Чел нанейрослопил порт typescript компилятора с ГОУ на раст и получил х3 приростк скорости. Почему ГОУ такой медленный?
https://www.reddit.com/r/theprimeagen/comments/1x046sl/another_bro_rewrote_tsc_go_in_rust_in_2_weeks_and/
Так гоу это легаси теперь. Все новое на расте пишется, даже Гугл начал на Расте писать.
У гоу буквально никаких юзкейсов больше не осталось, тем более в эпоху ЛЛМ. То, что раньше писалось на гоу, сейчас легко пишется на расте.
В целом гоу это тупо проект роба пайка, кена томпсона и алана донована. Гоу был нужен в нулевых годах и выстрелил в 10е годы, но сейчас очевидно идет закат гоу - программирование умерло, код пишется нейронками, и больше нет смысла тащить новый проект на гоу вместо раста.
Мне кажется, что у гугла просто жопа горела, что у оракла и майкрософта есть своя джэва, а у гугла нет
Возможно, но гоу действительно был весьма интересным языком до появления ИИ.
GC, сравнительно легковесный рантайм, компиляция в бинарь, value типы нормальные, горутины, рейс детектор...
Жаль что уже нахуй никому не нужно сейчас, нейронка генерит безошибочный код на расте, а брать Go вместо Раста имело смысл только когда люди еще руками программировали. В целом мы наблюдаем закат языков программирования. Rust, Typescript и Python вероятно останутся дальше, а вот Java, Go и .NET ждет очень печальная судьба забвения.
Меня люто насторожило что гц жрет 25% ресурсов и хоть ты усрись ты на это повлиять не можешь
> нейронка генерит безошибочный код на расте,
Ну это явное преувеличение. С го-генерацией там получше.
Вообще не вижу, чего принципиально изменилось. Читать-разбирать код код всё равно нужно, это явно проще на Го. Писать вот руками там такое себе, много тупого вроде "if err != nil", что как раз больше не проблема, а вот читать легко, ИИ проанализировать это тоже легко.
Если разрабатываешь сетевые сервисы, то всё равно наверное разумнее Го. На сектор настольных приложение Го особо не претендовал, наверное этот сектор за Растом уже окончательно.
> С го-генерацией там получше
У раста есть преимущество в виде боров чекера, который защищает от гонок + есть null safety из коробки. В го этого нет.
>Читать-разбирать код код всё равно нужно,
В том и дело, что ты теперь тоже читаешь меньше кода. Во многих командах код почти не читают уже. Код ревью как практика теперь много где отправлена на свалку истории или строго опциональная. Просить людей ревьювить код становится все сложнее, никому не хочется читать километровые ллм высеры и вникать в них.
Но даже если представим что ты прав и что чтение/понимание кода все еще с нами надолго, то как-то маловато преимуществ у Го получается? Ну то есть все преимущество Go в том, что это он читается чуть легче чем раст? С этим сейчас далеко не уедешь, имхо.
Я вообще не раст фанбой и мне на него всегда было строо похуй, вот только на работе теперь все новые сервисы на расте делаем. А так мы вообще долгое время жили в основном на jvm стеке (джава + котлин, немного скалы) и у нас также были гошные микросервисы. Переписывать на раст не будем, но все новые сервисы строго на расте теперь пишем генерим.
>никому не хочется читать километровые ллм высеры и вникать в них.
Но это не высеры, это ведь откровение свыше от ИИшки и вообще нейрослоп лучше и качественнее чем код который пишут кожаные мешки, как же так?
Ну это ты дал лиха конечно.
Джэва будет жить вечно, Раст видимо теперь будущее. Питон уже просто не нужен. Если раньше он ускорял написание кода, то теперь ЛЛМ это делает намного удобнее.
Тайпскрипт непонятно как еще существует - нишевое решение для нодохайпа, который уже сошёл на нет. Ну а о дотнете и говорить нечего.
Typescript как промежуточный слой заведомо не нужен, без JS никуда, но только как браузерный язык, варианты вроде ноды явно отмирают, они ещё до начала ИИ эпохи не очень нужны были. Просто в середине нулевых удачно для ноды сложилось.
Питон в любом случае очень нужен, за ним очень широкая ниша, замены нет и, главное, замена нафиг не нужна.
Разговоры про полное написание кода ЛЛМ, полном изменении разработки и всё прочее, это ну очень большое преувеличение.
У языков есть разные ниши, для сильно разных ниш нужды разные языки, нет причин использовать один язык для всего или для чужих них. Для чужих ниш используют потому, что разработчики один язык знают, а другой не очень.
Проблемы у близких языков, у которых близкие ниши. Вот у Го и Раст достаточно близкие, а значит надо выбирать, что использовать.
Обычно ещё крупный язык перетягивает на себя пользователей с других языков, разработчиков и заказчиков. У Раста сейчас очень большая поддержка.
>но только как браузерный язык
так Rust WASM
зачем машине нужно постоянно парсить и компилить исходники непонятно
>Джэва будет жить вечно
Я джавист и у нас новые микросервисы уже на расте начали делать.
jvm микросервисы конечно у нас остались и мы их еще долго будем поддерживать, но это именно что поддержка. Весь новый код пишется/генерится уже на расте.
>>3780594
Ниши языков по большей части нужны были когда люди писали код руками и читали его. Сейчас пройдись по компаниям и поспрашивай людей на местах - они не то, что код не пишут, они не читают его и даже не понимают как он работает. Это реальность для большинства компаний сегодня.
Не, может конечно через год-два ИИ шиза реально спадет и мы придем хотя бы к тому, что программист должен понимать что ему ИИшка сгенерила, но сейчас в большинстве компаний полный цирк начался и нейрослоп льется в прод, а люди вообще не вдупляют чем они занимаются.
В новой реальности каких-то "ниш" у языков программирования просто нет. Потому что выгодно брать для всего язык с наиболее крутыми рантайм характеристиками, где нет GC пауз, где нет жора памяти, где нет лишнего оверхеда. И под эти параметры идеально Раст вписывается.
>Rust WASM
Ты не сможешь на этом клепать формочки и кнопочки. Самый близкий с WASM к реакто-ангулярам был flutter, но все интерфейсы на нем адово тормозили даже на торговом железе, потому что рендер интерфейса был не через dom, а через прорисовку canvas. И чтобы можно было выделять текст поверх этого ещё были костыли. В итоге те кто использовал сие поделие Гугла через какое-то время переписывали все обратно на js+html+css. На расте даже близко нет того что сделали во flutter. Это больше нужно чтобы делать сложные по графике и вычислениям штуки типа игр, досок для рисования и биржевых терминалов, чисто пищевая хуйня
>за ним очень широкая ниша, замены нет
Нет у него ниш без альтернатив.
>И под эти параметры идеально Раст вписывается.
Там ещё очень строгий компилятор, который вылавливает 99% ошибок из-за рукожопости и многие вещи что делаются в рантайме через рефлексию тут в компайлтайме через макросы. Это просто идеальная штука для искусственного идиота, который после ругательств от cargo check понимает где и в каком месте косяк, пока другие языки прощают рукожопость и обмякнут потом в рантайме
>Джэва будет жить вечно
Нихуя подобного, сейчас работаю в банке как раз где все авторизации эмитента и эквайера, у всех этих команд доступен код в гитлабе. У нас все что на жабе, то говно написанное до 2022 когда было много всяких различных вендоров и эти все сервисы написаны поверх них. Теперь это все постепенно выпиливается, все новые сервисы пишутся на расте. Там осталось 3,5 человека на поддержке и те еще что-то делают еще в других местах, а основная разработка как раз на расте.
>Ниши языков по большей части нужны были когда люди писали код руками и читали его. Сейчас пройдись по компаниям и поспрашивай людей на местах - они не то, что код не пишут, они не читают его и даже не понимают как он работает
Мне кажется это больше фантазии. Не видел реально такого. Для генерации ЛЛМ подключают, но они там далеко не всегда что-то могут, потом это естественно читают и ревьювят.
Необходимость читать и понимать код будет всегда. Несколько иначе, чем раньше, потому что сейчас тебе в целом важна идея, а не тонкие нюансы кода, из-за которых могут быть баги (сейчас ЛЛМ довольно хорошо пишут сами и ищут косяки подобные).
Многие вещи, что выглядят красиво и понятно в питоне, превращаются в адские простыни на расте или го. Просто реально нет смысла.
Скорость важна далеко не везде. На практике у тебя или хватает ресурсов для выполнения задачи, или не хватает и тогда надо что-то придумывать.
Ну вот у нас очень похожая ситуация, не банк, но много финтеха. И тоже было много jvm сервисов. Но мы от jvm полностью не отходим, старье как было на джаве, так и будет еще годами, даже поднимать версии спринга и openjdk будем регулярно при выходе мажорных апдейтов. Есть еще гошные сервисы, они в целом тоже полу-легаси у нас и там особой разработки нет уже, одна поддержка.
Но новое реально на расте пилится полным ходом.
>>3780745
Если опустить всякие нюансы типа лайтаймов/боровинга/овнершипа (подразумевая что ИИшка сама все сделала как надо) и просто поверхностно читать код на расте и проверять именно бизнес-логику, то он вполне неплохо читается. Нет if err != nil через каждую строчку, есть что-то типа stream API из джавы, бизнесовый код на расте на самом деле выглядит даже поприятнее чем такой же код но на гошке.
Питон хорош только тем, что его реально попроще читать (если не городить всякую магию питона на ровном месте) и что код на питоне генерировать нейронкой быстрее/дешевле (меньше расход токенов, сам код короче).
Но стоит ли новый бекенд сервис на питоне заводить? Я вот не уверен. Я поддерживал легаси копролит на питоне одно время и это был кошмар и ужас. Для нормального питона в бекенде надо обмазываться чем-то типа mypy и аннотациями типов везде и всюду. И в целом у питона как будто не так много плюсов по сравнению с растом. Надо закладывать больше ресурсов, gc и stop-the-world в питоне имеется, сам по себе он не шустрый...
Короче питон был прям хорош для быстрого прототипирования когда кодинг был руками, сейчас быстрые прототипы пилятся все строго через ИИшку и сам питон как язык уже мало чего интересного может предложить тебе как разработчику.
>Я поддерживал легаси копролит на питоне одно время и это был кошмар и ужас
Это в целом верно про любой язык, питон просто не исключение. Объективно он не очень предназначен для больших проектов. Чем больше проект, тем больше там про строгость вместо гибкости и простоты.
В питоне очень удобно оперировать с текстом, со структурами данных ("перекладывать жсоны"), там есть исключения, там есть ООП. Раст всё-таки низкоуровневый.
Про кодинг без рук, по мне просто сейчас волна хайпа, как много раз уже бывало. Однако это влечёт столько проблем в далёкой перспективе, что пыл неизбежно умерят. Примерно в духе "мы придумали NoSQL, вот оно будущее, теперь MongoDB захватит мир, деды-пердуны с SQL нинужны", а на практике похайповали, попробовали, столкнулись с кучей проблем, а в то время в SQL базах завели какую-то поддержку фич NoSQL, и в итоге кучу проектов мигрировали с Mongo на Postgres.
Ну или можно вспомнить то же ООП. Тоже был дикий хайп, просто давно это было, было общее мнение, что всё будет на классах и ООП, java вот уродливое дитя этой пьянки, но потом как-то сильно умерили. Некоторые языки вообще без ООП считай, go/rust собственно, что по мне тоже неправильно.
Необходимость кодить руками и читать код никуда не исчезнет, просто трансформируется. Написание кода вообще никогда не было основным по времени. ИИ инструменты можно и нужно использовать более грамотно.
Не, я думаю кодописательство реально умерло, причем навсегда. Ну не докажешь ты кабанчику никак что надо код руками писать, когда есть машина, которая напишет этот же код в 100 раз быстрее тебя.
Это просто экономически неэффективно. В этом смысле ИИ реально отобрал труд у программистов, так как программирование человеками теперь просто очень дорогое и неэффективное занятие для кабана. Программирование это теперь сорт оф хобби или просто очередной предмет в вузе, как матанализ или линейная алгебра.
Работа есть для ученых, например, для разработчиков алгоритмов постквантовой криптографии и ускорителей криптографических вычислений на ПЛИС: qapp.tech
Теряют работу из-за ИИ только всякие низкоквалифицированные наборщики кода, которым до ИИ каким-то чудом за набор кода платили огромные деньги.
ты думаешь они код руками пишут?
я конечно понимаю что сейчас у многих желание цепляться за любой копиум, но программирование как массовое занятие умерло совсем. может где-то в таких местах что-то будут пописывать руками, но это буквально сотые доли процента всего рынка айтишки.
и да, с математикой и алгоритмами ИИшка на ура справляется, что и показала нам openai недавно.
>ты думаешь они код руками пишут?
В научной сфере программирование вообще сугубо утилитарно. Зато требуется знание высокоуровневой алгебры, например. Не понимаю вообще, как до ИИ за набор кода макакам платили баснословные деньжища, они же ничего принципиально нового не создавали, просто текст набирали. Даже алгоритмы эти макаки не знали, а математику в вузах презирали.
это не продукт, это какой-то аналог советского НИИ.
гендир этой конторы препод на ИУ-10 вроде как (кафедра фсб в бауманке), сама контора вероятно на заказах от фсб сидит. короче это не коммерческий продукт, а просто очередная вариация совкового НИИ в новом виде (как например yadro или бюро1440). ничего плохого в этом нет, просто все эти компании существуют ровно до тех пор пока их кормят со стороны. как только подкормка кончается - сразу массовые сокращения и банкротство.
>и да, с математикой и алгоритмами ИИшка на ура справляется
Но пользоваться такими умениями ИИшки смогут только люди с высокой квалификацией в математике, которые смогут, например, проанализировать криптостойкость системы шифрования. А криптоанализ это десятилетия потной практики, которую требуется знать.
Потому что наука и коммерческий продукт это разные вещи. В коммерции всегда кратно больше денег чем в науке.
И да, ученых, математиков, алгебраистов сегодня точно так же заменяет ботохуета на ура. Поэтому не вижу причин для какой-то гордости у ученых, которые ровно в той же ситуации находятся. Реддит почитай - там вой стоит такой, что аж уши закладывает. Овердохуя людей просто в одночасье лишились работы и/или своих кандидатских, которые были в процессе написания в момент, когда OpenAI дропнула решения задачи, которую аспирант пытался решить в виде своего диссера.
>это не продукт, это какой-то аналог советского НИИ.
Совковый подход мне больше нравится. Я думаю, что ученые, которые занимаются гос безопасностью (разработчики новых поколений алгоритмов шифрования) еще долго не потеряют свою работу, потому что гос безопасность нужна государству. А вот всякие ООО "Залупец", которые жировали на аутстаффе и аутсорсе в сытое время, сейчас массово банкротятся. Пожировали и хватит, у нас кризис, надо пынямать.
совковый подход оказался неэффективным, поэтому большая часть совковых НИИ либо сгинула либо осталась без денег и навсегда стала присталищем для дедов которые чаи гоняют за околомрот.
ооо залупец хотя бы конкурентный продукт пытался выпускать (или хотя бы делал вид что пытается). всякие госушные бизнесы и компании это тупо совковые НИИ где толком люди нихуя не делают годами, а потом, когда кормушка кончается, случается визг и очередное ЗАЩО!!!! когда их на мороз выставляют.
вон, сколько всяких НИИ было околовоенных до 2022 года, которые тоже "госбезопасностью" занимались, но только в военной сфере. и как их разработки, сильно помогли? ответ мы знаем. я сам в таком НИИ даже работал и знаю о чем идет речь и лично наблюдал как там деды годами сидят и нихуя не делают.
>Не, я думаю кодописательство реально умерло, причем навсегда. Ну не докажешь ты кабанчику никак что надо код руками писать, когда есть машина, которая напишет этот же код в 100 раз быстрее тебя.
В работе программиста непосредственно написание кода всегда занимало очень небольшую часть времени. Если у тебя написание кода занимает 20% времени, то даже ускорив в 100 раз, ты получишь 20% снижение времени и кучу дополнительных проблем, а именно что разработчик не будет понимать, что там за код и почему такой.
Написание года "не глядя" хорошо только для каких-то одноразовых задач, там какие-то утилиты сделать. Или для фрагментов кода, на которые ничего не завязыно, которые только своё какой-то функционал обеспечивают не критический.
Всё это проходили и не раз. И хайп вокруг технологий, когда ставили на что-то, а потом отказывали, пример NoSQL. И про автоматическую разработку.
лет 60 назад был хайп, что вот сделаем язык программирования для не-программистов, COBOL, и тогда бизнесмены сами будут писать, что им надо. Сейчас смешно, а тогда многие всерьёз так думали.
30 лет назад был хайп вокруг "визуального программирования". Что программисты не будут писать коды, а будут собирать программу из кубиков, елозя мышкой. Появились всякие Visual C / Visual Basic. И прямо реально нельзя было сомневаться в этом, чтобы мамонтом не обозвали. Сейчас смешно.
Потом был хайп, что сайты делать через специальные конструкторы. Тут интереснее, какие-то виды сайтом стало возможным делать очень дёшево. Но провело к тому, что разрабы, что так делали, часто не понимали, как всё это работает, если что-то надо было сделать за пределами штатного функционала, то всё, без шансов. Такая же проблема часто с фреймворками бывает.
С нейронками всё то же самое.
Это коупинг. Все предыдущие проекты не давали выхлопа и требовали пердолинга. Красиво было только на бумаге. Нейронка уже сейчас работает и полностью заменяет программиста. Любая домохозяйка с нулевым знанием кудахтер саенса может спокойно сделать проект, где раньше требовался бы десяток программистов, просто вводя промпты клоду.
как же ты заебал, засрал всю доску. Сидел бы хотя бы в своё загоне
Да это местный шиз, он тут везде и на разные темы срет жырнотой типа этой
>Ну не докажешь ты кабанчику никак что надо код руками писать
Очень даже докажешь, как всё наебнётся, а ты даже не знаешь что там к чему. Мгновенное доказательство.
Смотря кого кабаном называть. Кабану в целом пофиг на код, ему надо, чтобы проект работал и развивался. Кабан знает, что сотрудники активно ИИ в работе используют, и норм, а кто там конкретно код набирает ему по-барабану в принципе. Если кабан конкретный айтишник, то ему уже не надо объяснять, что автогенерация не глядя это абсолютное зло.
Всегда можно устроить токен-максинг и попросить оплатить счета за токены.
В Rust-треде уже пояснили, что всё надо писать на Rust. Какие ещё вопросы могут быть?
потому что не совсем ясно что такого может предложить go чего не может предложить rust. при это rust может предложить то, что не может предложить go - меньший жор памяти, отсутствие GC, лучший перфоманс на уровне С/С++.
в эпоху ЛЛМок не вижу смысла писать что-то на go когда есть раст.
>при это rust может предложить то, что не может предложить go - меньший жор памяти, отсутствие GC, лучший перфоманс на уровне С/С++.
>в эпоху ЛЛМок не вижу смысла писать что-то на go когда есть раст.
Я примерно на таком же уровне в десяток классе школы спорил "паскаль — хороший язык, потому что регистронезависим". Сука, ну ты же ни дня не работал в айти, ну куда ты лезешь? В Rust до сих пор нет стабильной платформы для зелёных потоков. Отсутствие GC? А ты уверен, что это преимущество, если ты пишешь что-то чуть больше, чем hello world?
Так он не пишет, пишет ИИшка, а она никогда не делает ошибок и пишет лучший код в мире - это гарантирует отсутствие утечек, таким образом делая мусоросборку ненужной тратой времени.
в расте нет гринтредов и не будет. там async/await.
впрочем тебе на это не похуй? код за тебя нейронка пишет, для нее что гринтреды, что async/await - похую.
>>3783880
>Отсутствие GC? А ты уверен, что это преимущество, если ты пишешь что-то чуть больше, чем hello world
да, более чем уверен. gc это всегда накладные расходы и stop-the-world впридачу. если нет gc и память менеджится боров чекером - то это хорошо. я знаю что некоторые продаваны из мира jvm/go ходят с докладами по конференциям где рассказывают что GC это сущее благо и что на каких-то синтетических кейсах GC показывает лучший RSS чем языки без GC, но из моего опыта это полный буллщит.
>>3783880
>Я примерно на таком же уровне в десяток классе школы спорил "паскаль — хороший язык, потому что регистронезависим". Сука, ну ты же ни дня не работал в айти, ну куда ты лезешь?
я работаю в айти уже несколько лет, свои аналогии можешь себе в очко засунуть.
я более общую мысль пытаюсь донести - языки программирования сейчас уже не важны. ты больше не пишешь код, почти не читаешь его. какое тебе дело что там под капотом? но с другой стороны перфоманс и потребление памяти никуда не уходит, а значит в качестве языка выгоднее брать то, что лучше всего по перфу и что жрет меньше всего памяти. а еще тот язык, с которым нейронкам проще всего работать, и в данный момент это языки со строгими компиляторами.
поэтому раст актуален, а гоха и прочие - уже нет.
на сам раст мне пахую, я (а точнее нейронка) пишу проекты на расте даже толком не изучив его. никогда не был раст фанбоем, как и не был фанатом гохи или джавы. просто делаем новое на расте теперь.
>Так он не пишет, пишет ИИшка, а она никогда не делает ошибок и пишет лучший код в мире - это гарантирует отсутствие утечек, таким образом делая мусоросборку ненужной тратой времени.
У тебя телега впереди лошади. Под капотом нейросетка ебашится об харнес каждую секунду, выстреливая полурандомный некомпилирующийся код до тех пор, пока он не пройдёт все этапы проверки. Итоговый код корректный, потому что харнес не дал его сделать некорректным, а не потому, что нейросетка такая точная.
Если твой агентный цикл снаружи не будет таким же образом пиздить нейросетку за реализацию, не соответствующую поставленной задаче, то ИИ напишет тебе любой бред.
>>3783905
>в расте нет гринтредов и не будет. там async/await.
Async/await — то же самое, только с более всратым интерфейсом.
>впрочем тебе на это не похуй? код за тебя нейронка пишет, для нее что гринтреды, что async/await - похую.
Похуй ровно до тех пор, пока не возникает ошибка в проде, которую не может решить нейросеть, а код представляет собой простыни из бойлерплейтов, которые придётся неделями вычитывать, чтобы разобраться, что там накуралесила нейросеть.
inb4: да просто перепиши весь код заново, ы-ы-ы.
>gc это всегда накладные расходы и stop-the-world впридачу. если нет gc и память менеджится боров чекером
Сука, ну хоть у нейросетки спроси, что она про твой стоп зе врот думает. Современный golang с параллельным сборщиком останавливает код на миллисекунду — для большинства задач, кроме отдельных low latency, это похуй вообще. Проблемы ещё могут быть на сетапах с 200+ Гб оперативы, но там ситуация непростая и с растом, и C/C++ — можно говна поесть даже больше, чем со сборщиком.
>я более общую мысль пытаюсь донести - языки программирования сейчас уже не важны. ты больше не пишешь код, почти не читаешь его. какое тебе дело что там под капотом?
Эффективность разработки, в том числе с ИИ, особенно с ИИ, определяется наличием готовых решений и обученностью нейросеток на этих самых готовых решениях. "Нахуй готовые решения — давайте копилятор напишем с нуля" — это в школу, рядом с детьми, которые всё на свете бегут переписывать на расте, потому что в интернетах написали, что оно "лучше всего по перфу и жрёт меньше всего памяти".
>я работаю в айти уже несколько лет, свои аналогии можешь себе в очко засунуть.
Дай угадаю: туалеты в яндексе чистишь?
>ошибка, которую не может решить нейросеть
Ты сталкивался с такими ошибками? Вот чтобы опус-5.5 не смог понять в чем причина и не мог починить?
И да, логи, трейсы, метрики, мониторинги придуманы не просто так.
>>3783938
>Под капотом нейросетка ебашится об харнес каждую секунду, выстреливая полурандомный некомпилирующийся код до тех пор, пока он не пройдёт все этапы проверки. Итоговый код корректный, потому что харнес не дал его сделать некорректным, а не потому, что нейросетка такая точная
Ну вот компилятор сейчас и LSP - это неотъемлимая часть харнесса. И компилятор раста гораздо более строгий чем компилятор Го.
>>3783938
>Современный golang с параллельным сборщиком останавливает код на миллисекунду — для большинства задач, кроме отдельных low latency, это похуй вообще
Но тем не менее накладные расходы все равно присутствуют, и потребление памяти все равно придется тюнить.
----
Тв конечно хорошо так высрался, но ни одного аргумента в пользу Go так и не предоставил. Можешь рассказать зачем брать Go для новых проектов в 2027 году вместо Rust? Какие есть киллерфичи у Go, каких нет у Раста? Что такого предлагает Go особенно в эпоху LLM и агентов, чего не предлагает Раст?
Надо над этими вопросами подумать слегка. И скорее всего выводы будут таковы, что Go банально... ничего интересного не может предложить сейчас.
>Ты сталкивался с такими ошибками? Вот чтобы опус-5.5 не смог понять в чем причина и не мог починить?
Что значит "не смог понять"? После того, как я ему на две страницы разжую проблему и пути решения — мне уже нахуй не нужен опус, я сам могу проблему быстрее починить. А сам он понять предметную область, общую архитектурную идею , "эту функцию писали долбоёбы, не пользуйся ею", и прочее нетривиальное не в состоянии. Да, для этого есть скилы, но, опять же, скилы будут хороши ровно настолько, насколько они написаны — если у тебя нейросеть по скилам уже не смогла написать правильный код, то не сможет написать во второй раз. Более того, если у тебя скилы разойдутся с кодом, то можно поесть говна ещё больше, чем без скилов — поэтому я нередко делаю `rm -rf .cursor/` и делаю запрос по сорцам с чистого листа.
>И да, логи, трейсы, метрики, мониторинги придуманы не просто так.
Недавно в раковом пояснял.
https://gist.github.com/byko3y/44c6ec2f9cf592a45d0d484c8536325e
Трейсы-метрики-мониторинги тоже нужно проектировать — это такая же архитектура приложения, как и логика перекладывания заказов от пользователей.
>Ну вот компилятор сейчас и LSP - это неотъемлимая часть харнесса. И компилятор раста гораздо более строгий чем компилятор Го.
Я тебе даже больше скажу — я же на всех форумах и двачах пишу, что патологическая популярность раста вызвана тем, что он очень хорошо подходит для нейросетей — именно за счёт того, что компилятор яростно исправляет ошибки нейросети, и вся эта битва ИИ с борроу чекером для самого кодера становится почти невидимой. Но это вопрос моды и вкуса, а не технической необходимости.
>Но тем не менее накладные расходы все равно присутствуют, и потребление памяти все равно придется тюнить.
А что в расте у тебя Arc на каждый чих — это похую? Никаких накладных расходов?
>Можешь рассказать зачем брать Go для новых проектов в 2027 году вместо Rust? Какие есть киллерфичи у Go, каких нет у Раста?
Простота кода, быстрая компиляция, хорошая масштабируемость для сложных систем — в отличие от раста, на котором ни одной сложной системы не написано. Мне нужно пояснять, почему невозможно написать большой проект на Rust, или у нейросети сам спросишь?
А, так ты просто хейтер раста. Так бы сразу и обозначил себя. Понятное дело что с такими как ты спорить почти невозможно.
>>3784008
>хорошая масштабируемость для сложных систем
Что значит "масштабируемость для сложных систем" в контексте ЯП? Почему на Go можно писать сложные системы, а на Расте - нет?
> почему невозможно написать большой проект на Rust
Я вижу вполне объемные проекты на расте у себя в компании. Я вижу как фронтир разработки (Anthropic, OpenAI, xAI) делается на Расте. Я вижу как Cloudflare написана на расте. Я вижу как Гугл и Майкрософт мигрирует много своих систем и сервисов на Раст.
Я не думаю, что на расте нельзя писать большие/сложные вещи. Скорее всего эту точку зрения ты сам себе вбил в свою голову без явных на то причин.
>А, так ты просто хейтер раста. Так бы сразу и обозначил себя. Понятное дело что с такими как ты спорить почти невозможно.
Я растоскептик. Я не говорю, что это плохой ЯП — я говорю, что он намного хуже, чем его рисуют хомяки на реддите.
>Что значит "масштабируемость для сложных систем" в контексте ЯП? Почему на Go можно писать сложные системы, а на Расте - нет?
Слыш, опытный пользователь нейросети, как насчёт задать эти вопросы нейросети перед тем, как позорится на двачах? У голенга родные высокоуровневые примитивы конкурентного выполнения — тех же самых зелёных потоков в Rust нет совсем, только куцый async/await. Arc<Mutex> — эти низкоуровневая хуйня, из которой ещё нужно постараться что-то сделать. Каналы? Лепишь из говна и палок. Сложные структуры данных? Ёлочки контейнеров будут шириной с экран — и бегать это будет медленнее, чем golang, который за пределами сборщика не дёргает ни счётчики, ни мутексы.
Далее, безопасность памяти — это только безопасность памяти, она никак не гарантирует корректности логики. Логику тебе точно так же придётся писать, и на Go, и на Rust, но есть ньюанс: в го ты будешь работать с аккуратным кодом, в Rust ты будёшь грузить ёлки.
>Я вижу как Cloudflare написана на расте.
В клаудфлере дай бог 5% кода писана на расте.
>Я вижу как фронтир разработки (Anthropic, OpenAI, xAI) делается на Расте.
Нихуя не знаю — пусть за меня ответит нейросеть.
«Языковой баланс в Anthropics выглядит следующим образом
~45% – 55%PythonОбучение LLM (PyTorch), пайплайны данных, AI-исследования, базовые API.
~20% – 25%Go (Golang)Внутренние микросервисы, бэкенд-инфраструктура, распределенные системы.
~15% – 25%RustСистемные утилиты, инструменты разработчика (Claude Code), CLI и критически важные по скорости компоненты.
~5% – 10%C++ / CUDAНизкоуровневая оптимизация ядер для GPU/TPU (совместно с Python).»
Rust был, есть, и будет есть язычком для написания CLI утилиток, WAsm утилит, и изолированных сервисов. Никакого прогресса в ином направлении в последние годы я не вижу.
>Я не думаю, что на расте нельзя писать большие/сложные вещи. Скорее всего эту точку зрения ты сам себе вбил в свою голову без явных на то причин.
Просто пойди в интернет и найди большие сложные проекты, написанные на Rust. Сука, даже сама Mozilla отказалась от переписывания браузера на Rust — ты не находишь это красным флажком?
Zed — 140 тыс строк GPUI, плюс 400 тыс строк сама IDE. Охуенно большой проект. При том, что в Rust 2/3 строк — это вспомогательные объявления, а не логика. До сих пор нет отладчика в этой замечательной IDE.
>>3784058
>До сих пор нет отладчика в этой замечательной IDE
Пролистал до этого момента и остальное не стал читать. Ты просто не пользовался толком Zed, отладчик там есть.
Все остальные твои рассуждения наверняка примерно из той же оперы, что-то где-то когда-то слышал, но толком не понимаешь и знаешь что это.
Ебать у растовиков небомбит от вторжения в их уютный манямир. "Вам не понять".
>Каналы? Лепишь из говна и палок.
Есть tokio де-факто стандарт, собственно там каналы реализованы даже лучше чем у вас в голенке. В целом они не так часто нужны, например такие вещи как параллельная отправка двух запросов и получение ответов обходятся без нагромождения из каналов. Остальное шиза какая-то написана.
>Arc<Mutex> — эти низкоуровневая хуйня, из которой ещё нужно постараться что-то сделать.
У вас такой же мьютекс, только чуть по другому работаете с ним. Ты вообще сам на go пишешь или пришел тут троллить?
>В целом они не так часто нужны
Есть подходы, довольно старые, много материалов можно найти, чтобы максимально отказываться от использования мютексов и переходить на архитектуру каналов-очередей. Это даже не для го придумали. В го просто это хорошо поддержано.
Принцип и идея проектирования, что когда тебе надо работать с каким-то ограниченным ресурсом, вместо мютекса ты заводишь сервис-тред (легковесный) и высылаешь ему задание, сделать что-то с этим ограниченным-разделяемым ресурсом.
Это позволяет сделать намного более понятную и контролируемую архитектуру.
И разумеется вы у себя в мега крутой компании такой подход и используете, а не пишите абы как на отъебись лишь бы уже хоть что-то выкатить и не проебать сроки
> ты больше не пишешь код, почти не читаешь его. какое тебе дело что там под капотом? но с другой стороны перфоманс и потребление памяти никуда не уходит, а значит в качестве языка выгоднее брать то, что лучше всего по перфу и что жрет меньше всего памяти. а еще тот язык, с которым нейронкам проще всего работать, и в данный момент это языки со строгими компиляторами.
Возникает только один вопрос - где же весь этот замечательный софт которому для работы достаточно 512Мб и Pentium 4? Какого хуя гитхаб постоянно падает? Почему до сих пор не переписали с рубей на раст? Кто использует растовый компилятор TS?
>Это позволяет сделать намного более понятную и контролируемую архитектуру.
и намного более медленную. Потому что ВНЕЗАПНО гошные каналы сами используют мьютексы внутри. Так что передача чего-то через канал это дорого.
Двачую. Каналы - это рак голенга. В сишарпе, например, есть каналы, но их литерали никто не использует, ведь есть простой и понятный Task.WhenAll(). В голанге новые ньюфаги начитаются шизы от пайка, наслушаются таких же пориджей с маняконференций, а потом тащат эти ебаные каналы везде патамушта крута. Мы писали финтех на го без каналов, контекстов и прочего говна, и, внезапно, треда от сервера достаточно в 99.999% случаев реальных задач.
>есть простой и понятный Task.WhenAll()
Это вообще разные вещи. Одно дело когда ты запускаешь 5 потоков чтения из файла потому что посчитал что 5 это оптимум с т.з. IO и каждый поток считывает много данных и кладет их в очередь. А на той стороне тоже оптимальное количество консьюмеров их обрабатывают. А другое дело когда тебе надо просто из 3-х сервисов считать данные. WhenAll() это нихуя не замена очередям.
часть бекенда гитхаба уже была переписана на го с руби. алсо там проблема в том, что нагрузка выросла в разы на гитхаб из-за ИИ агентов.
Очереди нахуй не нужны. Агентную модель обоссали еще во времена эрланга, с этим говном банально неудобно работать. Когда шизопайк написал ту самую статью про каналы, 15 лет назад? В те времена на голанге писали он и его кошка, не было реального опыта в проде. То, что пайк нихуя не шарит в дизайне языков, доказано слайсами, такой лютой хуйни нет больше нигде. Психически здоровые люди не обязаны следовать его бредовым фантазиям.
Но как же изнурительные секции на сисдизайн? Неужели паджиты не смогли масштабировать нагрузку, как же так? Неужели всемогущий ии не переписал на расте?
>и намного более медленную.
Куда ты так торопишься? Если у тебя распараллеливание нужно ради вычислительной мощности и вообще адская числодробилка, то да.
Если мютекс один, то это не проблема. Вот когда он один и одном участке кода, что запускается на много тредов. Когда один мютекс обслуживает много участков кода, уже проблема. Когда мютексов много, их все надо держать в уме, контролировать, чтобы они заведомо освобождались, контролировать дедлоки. В какой-то момент это превращается в ад. Очереди и каналы во многом убирают эти проблемы.
В добавок чаще код с мютексами будет не оптимальным. То есть повсеместная история, когда лочат мютекс, делают что-то критическое, потому кучу вещей не критических, которые можно было сделать заранее, потом опять критическое. То есть код логичный в принципе, но не оптимальный, потому что мютекс залочен дольше, чем мог бы. Подход с очередями и сообщениями естественным образом это убирает.
Короче мютекс в чистом виде это реально антипаттерн. Естественно под капотом он в любом случае будет.
Подходы с очередями заставляют просто иначе думать и проектировать. Это перенос подхода "микросервисы" на то, что происходит внутри сервиса.
Вообще не понятно, по идее этот тип сервиса должен очень хорошо масштабироваться, репозитории ведь не зависят друг от друга. Единственное объяснение, что из-за агентов с их кривой разработкой, когда на каждый чих коммит и мр с конфликтами, нагрузка не в разы, а на порядки выросла, в сотни-тысячи раз, тут уже никакая оптимизация не поможет.
>>3784480
гитхаб всю свою историю был легаси монолитом и плохо масштабировался. сейчас это им выстрелило в хуй и они экстренно там чето переписывают и чинят на ходу.
>часть бекенда гитхаба уже была переписана на го с руби. алсо там проблема в том, что нагрузка выросла в разы на гитхаб из-за ИИ агентов.
Как правильно сказал >>3784451
>Но как же изнурительные секции на сисдизайн?
Передовые паджиты вооруженные передовым копайлотом не смогли реализовать рейт лимитер? ОК, пусть у агентов будут проблемы, но пусть у кожаных мешков все работает хотябы.
>Очереди нахуй не нужны.
>Агентную модель обоссали еще во времена эрланга,
У тебя полная каша в голове. Акторы используют очереди, но очереди используются не только там. Модель producer-consumer тоже использует очереди или event-driven там тоже используются очереди.
>В добавок чаще код с мютексами будет не оптимальным. То есть повсеместная история, когда лочат мютекс, делают что-то критическое, потому кучу вещей не критических, которые можно было сделать заранее, потом опять критическое. То есть код логичный в принципе, но не оптимальный, потому что мютекс залочен дольше, чем мог бы. Подход с очередями и сообщениями естественным образом это убирает.
Ну хуйня же написана! Ты просто сознательно засунул под мьютекс всё, а с очередями только реально критическую секцию. Просто надо под мьютексом делать только, то что требует синхронизации.
Например у тебя есть задача разобрать данные по категориям. Ты запускаешь 10 горутин которые читают данные из файла и пишут в очередь, на другой стороне у тебя одна горутина читает очередь и складывает все в map[Category][]Data. С т.з. архитектуры все чисто и понятно, да. Но у тебя на каждый Data два захвата мьютекса один на запись в канал, другой на чтение. В случае с мьютексом у тебя один захват, прочитал из файла без мьютекса, захватил перед записью в map, освободил после. inb4: я знаю что можно оптимальнее, это демонстрационный пример.
> В случае с мьютексом у тебя один захват, прочитал из файла без мьютекса, захватил перед записью в map, освободил после
На чтение ведь тоже потребуется, то есть ты не можешь читать в тот момент, когда кто-то другой туда пишет? Нет?
Нет таких задач. Все прекрасно обрабатывается в одном потоке. Даже если ты захочешь обработать в нескольких потоках, ты сделаешь локфри обработку каждому воркеру свой кусок, а потом соберешь результаты без блокировок. Твой пример - это классическая ошибка многопоточки.
У тебя в голове топ 20 вопросов на собеседованиях.
>producer-consumer
Я знаю только одно реальное применение этой хуйни - каналы в ROS2 и только потому, что так захотели разработчики. Если ты не пишешь дроны, тебе это не нужно.
>event-driven
Категорически нахуй это дерьмо с очередями очередей. Все уже наелись микросервисов, аж из ушей течет. Хватит.
>Категорически нахуй это дерьмо с очередями очередей. Все уже наелись микросервисов, аж из ушей течет. Хватит.
весь хайлоад event-driven если что