После шести месяцев разработки представлен релиз языка программирования Go 1.25, развиваемого компанией Google при участии сообщества. Язык сочетает высокую производительность, свойственную компилируемым языкам, с такими достоинствами скриптовых языков, как простота написания кода, высокая скорость разработки и защита от ошибок. Код проекта распространяется под лицензией BSD...Подробнее: https://www.opennet.me/opennews/art.shtml?num=63721
Доброе утро! Подскажите, неужели GO - лучший язычок для серверов? Спасибо!
GO - лучший язычок для серверов! Пожалуйста!
Нет, go - лучший язык, где условия задачи позволяют быть решёнными с помощью go учитывая потраченные силы на полученную пользу... Впрочем как и любой другой язык.
Go - это язык, на котором легко и быстро писать программистам. Но программы, написанные на Go, потом дорого и трудно сопровождать мейнтейнерам.
А на каких языках программы легко сопровождаются?
Если сопровождение админами серверов, то им легче сопровождать на скриптовых.
Сказал А, говори и Б.
Скриптовые это какие?
Баш портянки поддерживать нормально невозможно, пердолиться с версиями и окружении питона не сильно лучше. Гошка для девопсов отлично подходит.
На языках, на которых не принято при сборке вендорить пол-интернета. В реальной жизни практически любая go-программа имеет несколько десятков зависимостей в go.mod, а те, в свою очередь, имеют свои зависимости (иногда не меньше). И опакечивание такой программы превращается в квест, который заканчивается (и почти везде так и закончился), что мы просто весь этот мусор собираем статически и кладем в один пакет. (Привет, любителям динамической линковки и разделяемых библиотек). Язык просто не должен обладать возможностями и тулзами, которые способствуют делать плохо. А go полностью из этого и состоит.
Наоборот, писать их сложно и медленно из-за кривой обработки ошибок, уродского синтаксиса, скудности стандартной библиотеки, невыразительности самого языка и помойки "тяни-любое-гно -с-гитхаба" вместо экосистемы сторонних модулей. А сопровождать как раз тривиально, ибо go build и всё, причём сразу с кросскомпиляцией.
Да все так и гораздо безопаснее сей.
То что го гораздо лучше раста это просто база.
Главное не забывать defer ставить, чтобы память не подтекла...
Он особенно хорош тем, что вокруг него не скопилось достаточно людей, подменяющих написание работающего кода чем-то еще. Многие вещи, вокруг которых строятся сравнимые с отправлением культа процессы в экосистеме голанг технически невозможны.
По-моему уже всем очевидно, что го не удался. Сборщик мусора -- это сразу красный флаг (stop the world, все дела). Если нужен язык, способный компилиться в нативный бинарь -- то раст гораааа...(прошла минута)...аааздо лучше.
Если Rust хорошо, то Swift ещё лучше, т.к. он сделан святыми людьми из святой компании
Вендорлочная фигня.
так и раст жеж
Ассемблер уделывает ваш раст как в простоте, так и в производительности
Начнем с того, что инструкции, сгенеренные современными компиляторами, уделывают инструкции, написанные человеком, независимо от того, насколько этот человек гениален. Мы уже давно не в 70-ых, чувак. Компиляторы продвинулись гораздо дальше, чем "MOV EAX, 42" в лоб.
...и именно поэтому в любых языках, которые претендую на системность, есть возможность вставлять ASM-блоки, да?
Это меня как-то опровергает?
Да, по крайней мере косвенно. Если компиляторы производят более качественный код, то нет причин использовать асм, чего мы НЕ наблюдаем
Не все операции доступны через интринзики, только и всего
А в чём проблема дать написать инструкции ai-боту, вместо неоптимизированного мясного мешка?
Проблема в том, что мясной мешок понимает, что он делает.
А ai-бот это попугай-олигофрен. Он может только повторять, ничего нового он не способен создать. Он даже оптимально распределить регистры не сможет, нет у него такой способности.
Это не правда. Посмотри хотя бы канал 3blue1brown на youtube с визуальным описанием как gpt работает. И это на текущий момент уже даже не самая новая инфа.
> Это не правда. Посмотри хотя бы канал 3blue1brown на youtube с визуальным описанием как gpt работаетЧел, не трать время - этим воинам против ИИ бесполезно что-то объяснять.
Так не надо объяснять. Покажи готовую реализацию распределения регистров, которую сделал ИИ. Это нетривиальная задача, интересно посмотреть как мощный искусственный интеллект решит ее лучше чем кожаные дурачки.
> Это нетривиальная задача, интересно посмотреть как мощный искусственный интеллект решит ее лучше чем кожаные дурачкиЧто, еще нетривиальнее, чем шахматы и Го?
> 3blue1brownДаже искать такое не буду, дабы статью какую не схлопотать.
До 1 сентября еще все можно.
Ну ну. Видел я этот сгенерированный код. Даже при максимальной оптимизации часто лучше руками написать.
Видел я этот написанный руками код, 5 лет ревьювил, половину лучше бы бот генерировал.
>Видел я этот написанный руками код, 5 лет ревьювил, половину лучше бы бот генерировал.Скоро ваша мечта исполнится ☺.
Хаха. Сразу видно эксперта.
Там, где нужно ДЕЙСТВИТЕЛЬНО что-то быстро делать, приходится писать на ассемблере.
https://github.com/FFmpeg/FFmpeg - Assembly 7.9%
> Assembly 7.9%Ты хотел сказать ВСЕГО 7.9%
Учитывая что считают по строчкам кода, а асм нааамного многословнее любого языка, то там именно "действия" меньше 1%.
> Ты хотел сказать ВСЕГО 7.9%Зато быстро! 😭 Зато уделали компилятры языка С! 💪
> Хаха. Сразу видно эксперта.
> Там, где нужно ДЕЙСТВИТЕЛЬНО что-то быстро делать, приходится писать на ассемблере.Хаха. Сразу видно эксперта.
Там, где нужно действительно быстро, юзают GPU, а не греют CPU. Как там твой ассемблер поживает в областях 3Д рендеринга, крипты и Machine Learning?
Кек.
Ты наверное не в курсе, но вендоры не дают доступ к ассемблеру GPU. Если бы он был, очевидно что самые горячие места переписали бы на нем.
> Ты наверное не в курсе, но вендоры не дают доступ к ассемблеру GPU.Не слышал о PTX у Nvidia? Кек.
https://developer.nvidia.com/blog/understanding-ptx-the-asse.../
Не слышал, что AMD и вовсе публикуют ISA спеки? Кек номер два.
https://gpuopen.com/amd-gpu-architecture-programming-documen.../
> Если бы он был, очевидно что самые горячие места переписали бы на нем.
Кек. Очевидно, что пока достаточно переписать горячие места с ассемблера CPU на "не ассемблер" GPU, чтобы получит такой прирост, что даже сама идея ручного сношания с ассемблером на CPU в большинстве случаев будет абсолютно бессмысленной.
Поэтому твое экспертное "там, где нужно ДЕЙСТВИТЕЛЬНО что-то быстро делать, приходится писать на ассемблере." - это абсолютно мимо.
>AMD и вовсе публикуют ISA спеки?Я могу взять их и сделать свою видеокарту?
> Я могу взять их и сделать свою видеокарту?Я лично тебе разрешаю. Или в чем суть вопроса?
Суть вопроса: 1 наличие необходимых данных на сайте АМД для создания. 2. Лицензия, правовой аспект.
>PTX is a virtual machine ISA
>PTX is similar to LLVM IRАга, ассемблер для GPU, понимаю.
> AMD и вовсе публикуют ISA спеки
А какой командой запускается ассемблер для AMD GPU? Покажи туториал, как запустить helloworld на ассемблере для GPU.
>абсолютно мимо
Даже строковые операции в libc/glibc написаны на ассемблере (именно потому что их нужно ДЕЙСТВИТЕЛЬНО быстро делать), но эксперта это не смущает.
>>PTX is a virtual machine ISA
>>PTX is similar to LLVM IR
> Ага, ассемблер для GPU, понимаюЧел, ну тебе черным по белому написано:
"You can think of PTX as the assembly language of the NVIDIA CUDA GPU computing platform."
Это максимально низкий из возможных уровень - ниже, чем сама CUDA. Для Nvidia ниже не бывает. Бери и оптимизируй на нем "горячие" места, как тот эксперт выше завещал - в чем проблема?
Я не понимаю, в чем ты меня обличить пытаешься.
> А какой командой запускается ассемблер для AMD GPU?
Юзаешь hipcc, АМДшный асм вставляшь через asm():
https://rocm.docs.amd.com/projects/HIP/en/docs-6.0.0/referen...
> Даже строковые операции в libc/glibc написаны на ассемблере (именно потому что их нужно ДЕЙСТВИТЕЛЬНО быстро делать), но эксперта это не смущает.
Ну да, меня бы смущало, если бы строковые операции из стандартной сишной либы требовали GPU. 😂
Чел, ты на ассемблере вообще программировал?
Понимаешь в чем разница между IR и ассемблером для конкретной железки? Посоветуй авторам glibc писать на LLVM IR вместо их зоопарка ассемблеров для разных платформ. Ведь IR же максимально низкий из возможных уровень.>GCN ISA In-line assembly, is supported
>GCN was succeeded by the RDNA microarchitecture and instruction set architecture in 2019Понятно. Попрограммировали на ассемблере для AMD GPU.
>строковые операции из стандартной сишной либы
написаны на ассемблере для конкретных железок. Потому что
а) нужна ДЕЙСТВИТЕЛЬНО хорошая производительность
б) Intel и остальные нормальные вендоры не занимаются фигней и дают всем желающим возможность писать низкоуровневый софт на ассемблереЛадно, я вижу ты настоящий эксперт в ассемблерах. Очень круто в этом понимаешь чел. Не буду больше спорить.
> Ведь IR же максимально низкий из возможных уровень.По-моему там вполне ясно написано, что это максимально низкий из возможнх уровень *для видях NVIDIA*.
>>GCN ISA In-line assembly, is supported
>GCN was succeeded by the RDNA microarchitecture and instruction set architecture in 2019
> Понятно. Попрограммировали на ассемблере для AMD GPU.Есть подозрение, что попросту не обновили доку к компилятору. Вряд ли набор инструкций новой микроархитектуры будет примо на 100% отличаться от предыдущей.
Но в любом случае, асм для AMD и для CUDA есть, что уже множит на ноль твое заявление об отсутствии асма для GPU.
>>строковые операции из стандартной сишной либы
>написаны на ассемблере для конкретных железок. Потому что [...] нужна ДЕЙСТВИТЕЛЬНО хорошая производительностьНу да, хорошая - насколько можно это возможно сделать на CPU. Как я и писал, было бы странно требовать для строковых операций GPU.
Но опять же: вроде никто не спорит, что на CPU с асмом как правило быстрее, чем без асма. Но вот заявленной тобой МАКСИМАЛЬНОЙ производительности с CPU ты в большинстве случаев не получишь (хоть с асмом, хоть без него) - тут только GPU.
>там вполне ясно написано, что это максимально низкий из возможнх уровень *для видях NVIDIA*Нет, там вполне ясно написано "compilation of PTX for a specific GPU can happen just-in-time (JIT) at application runtime".
Это IR, не ассемблер для конкретного железа. Максимально низкий уровень, который вендор хочет дать.>Вряд ли набор инструкций новой микроархитектуры будет примо на 100% отличаться от предыдущей.
Даже в статье википедии написано про отличия в instruction set между GCN и RDNA. А есть уже RDNA 2, RDNA 3 и RDNA 4.
>асм для AMD и для CUDA есть
Нет. Для актуальных GPU ты не можешь разрабатывать на ассемблере так же, как и для x64/arm/risc/mips и т.д. Уровень анальной огороженности железа GPU сильнее чем у Эльбруса.
>только GPU
Нет. Из более-менее массовых решений есть ASIC'и (ты же сам писал про крипту), FPGA, блейд-системы и еще разные узкоспециализированные железки.
Но это все как бы отдельные железки, они отдельно программируются, хотя даже по ним видно - чем на более низком уровне вендор дает возможность их программировать/конфигурировать, тем больше можно из них выжать производительности.
> Ты наверное не в курсе, но вендоры не дают доступ к ассемблеру GPU. Если бы он был, очевидно что самые горячие места переписали бы на нем.Как это утверждение противоречит его словам о том, что для МАКСИМАЛЬНОЙ производительности уже давно используют GPU, а не греют CPU? И что в областях 3Д рендеринга, крипты и Machine Learning твой GPU с ассемблером абсолютно бесполезны?
> И что в областях 3Д рендеринга, крипты и Machine Learning твой GPU с ассемблером абсолютно бесполезныТы хотел написать "CPU", я надеюсь? 😂
О, еще один эксперт.
Максимальной производительности ЧЕГО?
Про ASIC'и ты тоже не слышал?Или у опеннетовцев какая-то профдеформация - читают про ассемблер и не понимают что они могут быть разные, в том числе и для GPU.
Еще раз - чем более низкий уровень доступа к железке дает вендор, тем больше из нее можно выжать производительности. Если бы вендоры давали доступ к ассемблеру GPU, то на нем переписывали бы горячие куски и увеличивали производительность. Так же, как сейчас делают на "традиционных" CPU.
Это далеко не так... Написанный ручками код на интринсиках может быть быстрее в разы. Наблюдаю это прямо сейчас.
>Начнем с того, что инструкции, сгенеренные современными компиляторами, уделывают инструкции, написанные человекомТы хоть раз смотрел в дизассемблерные листинги прог, скомпилированных компиляторами?
Ты хоть раз видел вручную написанный на ассемблере код?
Скорее всего ни того, ни другого, но ценное мнение вещает.
Вы шутите? Кто в 2025 году будет писать софт для серверов на ассемблере? Можно ссылочку на такие проекты?
> Вы шутите? Кто в 2025 году будет писать софт для серверов на ассемблере?Ты на Опернете, друг. Тут местные эксперты и не такой бред пишут.
Подтверждаю, уровень экспертизы местных экспертов выше любых ожиданий и за пределами понимания!
А кто будет писать софт для серверов на расте?
> А кто будет писать софт для серверов на расте?Напр. чуваки, через которых идет трафик к каждому пятому сайту.
Написали как замена nginx. И оно работает быстро, а главное написано не на дырявой.github.com/cloudflare/pingora
> Напр. чуваки, через которых идет трафик к каждому пятому сайту.
> Написали как замена nginxВы все врети! 😭 На вашем Расте ничего не написано111
А если серьезно, то любо-дорого смотреть, как этот весь спектакль от местных воинов против Раста подходит к концу, так как пунктов в методичке у них почти не осталось. Будет в комментариях почище.
> А если серьезно, то любо-дорого смотреть, как этот весь спектакль от местных воинов против Раста подходит к концу,Шота пока не сильно заметно.
> так как пунктов в методичке у них почти не осталось.
всегда можно бухтеть про синтаксис, отсутствие поддержки некроплатформ, куракекать про "вендорлок" и тд
> Будет в комментариях почище.
Вангую, что не станет(
Вон один до№№№№ уже завел шармнку про ночнушки.
Доку он не читал, про edition не знает.
Но наcpaть в комментах - для него дело принципа.
Так и что начинать учить Rust? Найду на нём работу?
> Так и что начинать учить Rust?Нет, не надо.
Вообще раст сложный, нестабильный, постоянно меняется.Не нужен тебе такой язык.
А мне не нужны конкуренты)> Найду на нём работу?
В каждой теме народ плачет что на расте что-то переписывают...
А если серьезно, то в РФ - скорее всего нет.
За пределами или на "мировом рынке" - вполне.
>А мне не нужны конкуренты)ссылку на свой гитхаб давай, "конкурент" ты наш ненаглядный
посмотрим на хелловорлды
пока что все опеннетовские воины зараст только языком чесать умели а вот про сам язык дальше баззвордов ничего не знали и уж тем более не писали на нем
а те кто знали и писали - не занимались воинствованием зараст
> ссылку на свой гитхаб давай, "конкурент" ты наш ненаглядныйлол, ты думаешь я настолько отбитый, чтобы тратить усилия и время на опенсорс для васянов?))
> посмотрим на хелловорлды
мамке под юбку смотри, а у меня nda есть
> пока что все о
какой-то шизофреничный бред, даже не знаю что на это ответить..
ты пойти, что ли, таблеточек попей
Ты погоди, мы щас как за границу методички выйдем, а там много всего)
Ну и чё, заменило оно нгинкс или местячковая поделка которая нужна 1 конторе?
хз как у других, а мы выкинули нгинкс на помойку и заюзали ее. Причем эта штука легко интегрируется прямо в твой растовый код.
> местячковая поделка которая нужна 1 конторе?Нгинкс оно, разумеется, не заменило. Еще не заменило.
Как минимум потом что nginx 20+ лет, а pingora - чуть больше года с первого публичного релиза April 5, 2024.Но сам факт того, что конторе, которой нужен очень надежных инструмент с хорошей производительностью, выкинула nginx с сишкой на мороз и написала свое на расте, которое еще и оказалось быстрее, говорит очень о многом.
Как минимум опровергает мифы местным клованов о том что "на расте никто не пишет" и "на расте нельзя писать быстрые программы".А клаудфаре как раз нужно быстро и надежно. Потому что у них огромные нагрузки как для одной конторы.
"Cloudflare is used by 80.7% of all the websites whose reverse proxy service we know. This is 19.5% of all websites."
(w3techs.com/technologies/details/cn-cloudflare)
Любой, кому Go недостаточно, а с крестами связываться не хочет.
Я бы не сказал что на расте писать сложнее или дольше чем на гошке. Так что если ты знаешь раст, то голанг тебе наверное не нужен. Оба языка отлично подходят для сервера.
А ниче тот факт, что целые операционные системы пишут на ассемблере?
> А ниче тот факт, что целые операционные системы пишут на ассемблере?В 2025 году?
Разве что если начали лет 20 назад, и двигаются по инерции.Если ты про коллибриОС, то она оказалась никому не нужной.
> Если ты про коллибриОС, то она оказалась никому не нужной.миникс тоже никому не нужен был, а поди оказалось, что пригодился в самом нужном месте ;)
//www.opennet.ru/opennews/art.shtml?num=47539
>> Если ты про коллибриОС, то она оказалась никому не нужной.
> миникс тоже никому не нужен был, а поди оказалось, что пригодился в
> самом нужном месте ;)Вот когда пригодится, тогда и поговорим (с)
Систему пилят с 2004 года, там уже были сpaчи и форки (собственно сама колибри это форк MenuetOS).
А толку?
> Вот когда пригодится, тогда и поговорим (с)Ок, у меня хорошая память, напомню вам (ц)
> А толку?
Любой софт (не заказанный), в первую очередь пишется для себя. :)
> Ок, у меня хорошая память, напомню вам (ц)Да без проблем.
Я умею признавать свои ошибки.>> А толку?
> Любой софт (не заказанный), в первую очередь пишется для себя. :)Тогда можно дойти до темплеОС, как средство от (или для?) шизофрении.
Но ценности для человечества оно не добавит)
> Но ценности для человечества оно не добавит)альтруисты в треде пхааа, человечество - стадо, ресурс, "скот". Это "общество" должно ценить каждого индивида.
>> Но ценности для человечества оно не добавит)
> альтруисты в треде пхааанеа, тут ты ошибся
темплОС вообще бесполезна для меня, а т.к я - непосредственная часть человечества...
Другие разработчики и пользователи могут рассуждать так же.
> темплОС вообще бесполезна для меняона не создавалась вам в пользу, это продукт болезни людской (гениальность пора уже диагностировать как "болезнь"). Когда у вас в голове заиграет музыка, тогда осознаете, что вы Моцарт :) Поскольку она у вас не играет, Моцартом вам не быть.
> Другие разработчики и пользователи могут рассуждать так же.
Другие стали "разработчиками", потому-что какой-то "больной" выдумал "бесполезное программирование" для посредственного "дворника".
> темплОСютуб, щас мне в рекомендации сунул его стрим (фейспалм)
>Тогда можно дойти до темплеОС, как средство от (или для?) шизофрении.TempleOS часто упоминается в комментариях анонимными экспертами потому что среди них много не диагностированных шизофреников или просто ценителей?
вопрос же в другом, способны ли вы, "нормальные" без шизы, написать TempleOS?
> вопрос же в другом, способны ли вы, "нормальные" без шизы, написать TempleOS?Думаю нет. Такое можно писать только или с шизой или под веществами.
Вообще с шизой можно много чего делать, вот только ценность будет как у "🐓 из 💩"Хоббийных осей написано много, некоторые даже местами используюся.
Некоторые просто для обучения.
> Кто в 2025 году будет писать софт для серверов на ассемблере?за еду уж точно никто не будет, а вопрос надо бы переформулировать, кто заказчиком то будет?
> Вы шутите? Кто в 2025 году будет писать софт для серверов на ассемблере? Можно ссылочку на такие проекты?Ну не на чистом асме, но на интринсиках каких-нибудь avx2 - да, пишем, производительность выше в разы
> Ассемблер уделывает ваш раст как в простотеНе будь пустозвоном и покажи FizzBuzz на асме. 😉
Их же сотни, этих FizzBuzz на асме.Я не тот Аноним, но тоже делал когда-то FizzBuzz на gas
https://gist.github.com/vmxdev/075d1015abc2ff05b7236c2486787...Обмазываешься макросами по вкусу и пожалуйста.
> Я не тот Аноним, но тоже делал когда-то FizzBuzz на gas: https:...Спасибо, этот код гораздо проще, чем Rust!
Это ты ещё в машинных кодах не видел, таким вообще красота!
"Простота" - это дело привычки. Для человека, который пишет на x64 ассемблере там довольно простой код. Если этот же человек никогда не видел Rust, естественно для него ассемблерный код будет "проще".
Я уверен, что уважаемый Жироватт видел оба. А вот понял ли хотя бы один - вопрос открытый. 😂
ФизБаз херня. Вот подсчёт символов в строке я бы на асме посмотрел.
На простой, короткий и быстрый код, хех.
> Вот подсчёт символов в строке я бы на асме посмотрел.
> На простой, короткий и быстрый код, хех.Я боюсь, ни того, ни другого уважаемый Жироватт нам не покажет. 😭
Не понимаю, это какой-то странный траленк.
Подсчет символов в строке (strlen) в libc буквально написан на ассемблере
https://github.com/openbsd/src/blob/master/lib/libc/arch/amd...
Код не простой, конечно, но достаточно короткий и быстрый.
> Не понимаю, это какой-то странный траленк.Было заявление, что на асме код проще, чем на Расте. Набросивший это эксперт закономерно утих и на вопросы не отвечает. Что непонятного?
> достаточно короткий и быстрый...и не выполняет поставленную задачу, ага.
Я бы понял, если бы ответ написал американец, у них все строки – это совокупность цифр, букв A-Za-z и пару знаков препинания.
Но мы живём в мире utf8 и подсчёт _символов_ в таких строках задача ни разу не "простая и короткая".
> Я бы понял, если бы ответ написал американец, у них все строки – это совокупность цифр, букв A-Za-z и пару знаков препинания.Ну, или сишочник, лол. 😂 У этих ребят вообще символ и байт - синонимы, ибо нормальных строк они и не видели.
Зато нагородили простыню асма, и теперь линейный поиск нуля стал... быстрым линейным поиском нуля! Ну, то есть как быстрым... Все еще медленне, чем даже в скриптовом Питоне, где, как и в любом адекватном языке, количество символов вообще не нужно считать, ибо оно храниться в переменной, являющейся частью строкового типа.
> Подсчет символов в строке (strlen) в libc буквально написан на ассемблере
> https://github.com/openbsd/src/blob/master/lib/libc/arch/amd...По причине того, что в дыряшке убогая нуль терминированная строка.
В нормальном коде просто бы спросили "а сколько у тебя символов и сразу получили ответ".> Код не простой, конечно, но достаточно короткий и быстрый.
Работает с utf8? А если глифы динамической длинны?
Тогда привычно выходим за пределы буфера))?Ты сейчас приводишь примеры того, как лепят костыли героически преодалевая трудности.
> Подсчет символов в строке (strlen) в libc буквально написан на ассемблере[...] достаточно короткий и быстрый.
Быстрый, лол. Ты сколько это недоразумение асмом не обмазывай, а оно все равно будет тормознее даже скриптоты типа Питона. 😂Потому что будет бежать по всей строке в поисках нуля, в то время как в нормальных языках с человеческим строковым типом - просто вернется значения инта, хранящего количество символов.
Это просто феерический пример, когда гениальный дедовской дизигн настолько ущербен на корню, что его даже ассемблерные оптимизации под целевую платформу не могут спасти. Но нет: сишочники с упорством барана накатывают оптимизации на то, что давно нужно выкинуть на свалку.
Он не удался, потому что в нём нет классического ООП
>Он не удался, потому что в нём нет классического ООПВот это как раз максимально мимо ☺☺☺. Никому уже не нужен "классический ООП". А если вдруг взяться разрабатывать на Go в стиле ООП, обнаруживаешь, что даже это намного лучше, чем Java и C++.
>По-моему уже всем очевидно, что го не удалсяНет, не очевидно. Я сам поработал года два на Go, когда соскочил с C++ (потом перешёл на Rust). Go имеет право на жизнь, это альтернатива Питону, Джаве, PHP и прочему подобному; Go намного лучше и практичнее их. А Rust — альтернатива C и C++.
> Go имеет право на жизнь, это альтернатива Питону, Джаве, PHP и прочему подобномуGo - альтернатива Питону? А Баш им тоже поди можно заменить? 😂
Можно, почему нет. Юниксоподобным системам пофиг, бинарник или скрипт в текстовом файле.
> Можно, почему нет.Потому что отсутствует здравый смысл.
> Юниксоподобным системам пофиг, бинарник или скрипт в текстовом файле
Только человеку не пофиг, на чем писать скрипты на выброс.
Здравый смысл как раз присутствует. Можно не таскать рантайм и зависимости (привет node_modules), выше производительность (на порядок).
> Можно не таскать рантаймДа, очень здраво таскать исходники и компилятор, и делать собственно саму компиляцию, когда в "скрипте" нужно что-то поправить.
Я уж не говорю о том, что Питон есть из коробки на любом Линуксе и даже Маке. В отличие от компилятора Go, лол.
> выше производительность
Да, это очень важно в сценариях использования скриптовых языков. 🤦
> Здравый смысл как раз присутствует.
Напрочь отсутствует, что и требовалось доказать.
ваш rust постоянно меняющееся переусложненное болото. ждем всех его преимуществ в C и C++
> ваш rust постоянно меняющееся переусложненное болото.ну так фиксируй edition и сиди сколько пожелаешь
это не будет отличаться от "30 лет на C89"> ждем всех его преимуществ в C и C++
ждите-ждите)
если они поломают обратную совместимость, плакать будете?
> ваш rust [...] переусложненное
> ждем [...] в C++Не, ну главное что C++ не переусложненное. 😉
> очевидно, что го не удалсяКак не удался?
Вот есть soong_build, написанная на go, - сборочная система для ОС android, точнее, генератор мейкфайлов. И вот, только этот генератор сжирает минимум 40 гигов памяти и заметное время. И при малейшем изменении какого-либо проекта - полная перегенерарция.
Так сказать, фильтр тех кто достоин собрать свой андроид.
> В команде "go build" по умолчанию активирована опция "-asan", выполняющая проверку утечек памяти при завершении работы программы.секундочу! Поясните, пожалуйста, как в memory managed & safe ЯП могут быть утечки памяти, если за всей памятью следит GC (и берёт свой налог в виде недетерминированных тормозов)?
из-за неправильного управления ссылками на объекты
например забытые дискрипторы или неуправляемо плодящиеся и забытые горутины
>> The go build -asan option now defaults to doing leak detection at program exit. This will report an error if memory allocated by C is not freed and is not referenced by any other memory allocated by either C or Go.
В rust тоже есть утечки памяти, с подключением.
"Memory leaks are memory safe" ©
Это правда? Я в смысле про раст. Ну, значит через пять лет ждём появления языка с защитой от утечек. И переписывания его фанатами всего уже на него.
> Ну, значит через пять лет ждём появления языка с защитой от утечек.Это вряд ли. От утечек памяти мало реальных проблем с безопасностью, в отличие от других проблем с памятью. Плюс еще не придумали универсальный способ как с ними бороться в языках с ручным управлением памятью.
Вот когда придумают новый язык с быстрой и дешевой верификацие - тогда буду топить за закапывание раста.
Утечка памяти это когда память заняли и не освободили. Ответственность лежит на разработчике, т.к. это может быть нужно, например для реализации арен.С точки зрения безопасности, в том же расте, проблемы нет – несанкционированного доступа к этой памяти "со стороны" нет, значит ОК. А то что пришел OOM killer – да, обидно, фикси.
Опять же, в расте надо постараться, чтобы написать код, который течёт. Надо, буквально, использовать специальные структуры данных, для которых в явном виде указано, что будешь за собой чистить сам. Не умеешь с ними работать – не лезь к ним.
В Rust нет сборщика мусора, с которым утечек не должно быть по определению
Вот бы на него 3Д движок игр какой-то завезли, язычок очень понравился, компактный, простой, легкочитаемый (для меня лично), для 2Д есть ebiten, классный, осталось 3Д покоритьА так всё есть: GUI, игры, web-приложения, embedded, утилиты, красотааа
http://g3n.rocks/
GUI для Go? Это какой?
>GUI для Go? Это какой?Тысячи их.
>Код достаточно лакониченЭто с его то проверками на err - nil?) смешно
Использовать функции не пробовали?func checkErr(err error) {
if err != nil {
log.Fatal(err)
}
}// 🥰
checkErr(someFunction())
>func checkErr(err error)Костыль, который пробуют приладить все новички в Go ☺. Потом просто смиряешься и повторяешь мантру "явное лучше неявного" ☺. Go, конечно же, не про лаконичность.
Никогда так не делайте. Это кидает паники, а их надо избегать.
откуда тут паники? log.Fatal же просто завершает с программу
Нет, он кидает панику с сообщением об ошибке в аргументе
Ну знаешь...по сравнению с 1СовскимЕсли ЗначениеЗаполнено(МассивОтбора.Ссылка) Тогда
Если ЗначениеЗаполнено(МассивОтбора.Ссылка.алкПунктРазгрузкиКонтрагента) Тогда
Если НЕ ПустаяСтрока(МассивОтбора.Ссылка.алкПунктРазгрузкиКонтрагента.КПП) Тогда
...
или хрустовской тайнописьсьюfn Fdmdm(d,mn+fd;?8,**?vla)
да, вполне лаконичен
а че это через точку свойства читаешь, непорядок вообще
Не проверяй, пиши res, _ := someFunc()
Будет максимально лаконично и надежно
Есть свежая либа, которая повторяет поведение rust (в zig похоже) для обработки ошибок: реализует паттерн try (? в расте, try в zig) и все ошибки оборачивает в Result.При этом добавляет цепочку контекста (файл, строка, функция/метод, аргументы вызова), не надо самому постоянно оборачивать и/или использовать fmt %w. В существующий код легко добавляется, тк преобразование из Result в val, err тоже делает легко.
https://github.com/nordborn/mo
Но на реддите людям не понравилось. Неидеоматично. Говорят, if err != nil { rerurn wrapSomeHow(err) } привычнее вместо callFunc.Try(). Ну, может и так.
Забавно, что авторы языка пытались к некоторому check свести, но до джереников это не работало, а сейчас забили и вопрос закрыли.
Хз. У меня в проде mo везде теперь. Код чистый стал, многое теперь в одну строку обрабатывается, перестал плеваться на этот шум от ошибок. Скажем так, получил вид кода, который хотел.
вангую что твой код вообще не обрабатывает ошибки. итак сойдёт?
К err != nil быстро привыкаешь. Самое главное это обернуть ошибку и расширить контекст, вместо того чтоб тупо писать return err.
Более лучший язык пока не придуман.
ЧатГПТ придумает скоро, раст покажется цветочком, сможет осилить только сам ИИ, но убедит кожаных что это лучший язык. Дальше вы все знаете продолжение что будет
Если бы он смог то уже бы написал.
Всё идёт по плану. Не торопитесь.
Просто наблюдение, без токсирования. На Go простейшая утилита, проверяющая IP - в VirusTotal получает более 10 срабатываний. На Rust - 0! :-)
Ну какие-то мощные сервера типа SQL или веб-проксей на 100500 соединения на нём писать конечно не стоит, но для всякой прикладнины для потребления внутри компании или написания консолей железок лучше средства разработки нет.
Ох уж эти язычники, основной язык в Linux - это C, всё остальное должно собираться из C напрямую или через компиляторы которые собираются из C.
> Ох уж эти язычники, основной язык в Linux - это C,Был) Теперь, насколько я помню, языков уже два.
> всё остальное должно собираться из C напрямую или через компиляторы которые собираются из C.
А какие компиляторы собираются из СИ?
Даже GCC теперь разрабатывается на С++, тк на убогой сишке сделать н̶а̶д̶е̶ж̶н̶ы̶й̶ хотя бы рабочий оптимизирующий компилятор оказалось не возможно.
Ну не 2, в ядре их чуть больше: C 98.2% Assembly 0.7% Shell 0.4% Python 0.3% Makefile 0.2% и другие.
На С сервисы в docker будешь дольше писать, на порядок. Столько же времени на их дальнейшее развитие и поддержку.
>На С сервисы в docker будешь дольше писать, на порядок. Столько же времени на их дальнейшее развитие и поддержку.Однозначно. Роб Пайк, кстати, предлагал слоган "Go — это Си 21-го века". В том смысле, на каком языке пишется большинство самых актуальных систем.
> Роб Пайк, кстати... забыл добавить в "си 21-го века" возможности 21-го века. В результате имеем бинарники по 30МБ. У меня в /bin+/sbin+/usr/bin+/usr/sbin 5171 бинарный файл. Если каждый из них будет весить 30МБ, всё вместе потребует 155ГБ. И это только бинарники. Приглашаю в чат клоунов, которым везде продают диски по цене грязи.
> ... забыл добавить в "си 21-го века" возможности 21-го века. В результате имеем бинарники по 30МБ.Это много?
Но ты можешь подождать пока на сишке напишут меньшего объема.
А потом ловить CVE/RCE.> У меня в /bin+/sbin+/usr/bin+/usr/sbin 5171 бинарный файл.
Это твои проблемы.
> Если каждый из них будет весить 30МБ, всё вместе потребует 155ГБ.
О ужас! Это же почти треть СД диска.. хотя даже сд-юков в компах почти не осталось, двд победил еще 10 лет назад)
> Приглашаю в чат клоунов, которым везде продают диски по цене грязи.
Но зачем??!
Ты уже тут, и устроил отличный стендап "нытье нищуброда"! Я просто в восторге!ps терабайт hddшки стоит примерно 13-15 баксов, ссдшки - 40.
нет никакого смысла ориентироваться на луддитов, которые еще молятся на свой maxtor.ps2 у тебя есть отличный вариант - не пользоваться программами на ГО, а искать СИшный вариант
а если их нету... sad to be you))
> А потом ловить CVE/RCE.То ли дело у гошников. Появился CVE в библиотеке - обновляй все бинарники, с ней скомпонованные. И нет никакой проблемы, интернет же бесконечный.
> Это твои проблемы
Нет, это проблемы будущих поколений, если у них софт будет на этом недоразумении писаться. У меня 99% бинарников на C/C++ , там тоже жирноты много, но хотя бы приемлемо.
> Это же почти треть СД диска..
По-твоему треть ссд-диска только на бинарники - это нормально?
> не пользоваться программами на ГО, а искать СИшный вариант
К счастью, на данный момент выбор как раз обратный. НЕ ИСКАТЬ программы на ГО, а пользоваться уже написанными и отлаженными СИшными вариантами.