После шести месяцев разработки представлен релиз языка программирования Go 1.25, развиваемого компанией Google при участии сообщества. Язык сочетает высокую производительность, свойственную компилируемым языкам, с такими достоинствами скриптовых языков, как простота написания кода, высокая скорость разработки и защита от ошибок. Код проекта распространяется под лицензией BSD...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63721
Доброе утро! Подскажите, неужели GO - лучший язычок для серверов? Спасибо!
GO - лучший язычок для серверов! Пожалуйста!
Потом, лет через тридцать будут искать прогеров не в павших в слабоумие которые могут сопровождать старый код на этом, ибо ай-жпт его не понимает
Нет, go - лучший язык, где условия задачи позволяют быть решёнными с помощью go учитывая потраченные силы на полученную пользу... Впрочем как и любой другой язык.
Go - это язык, на котором легко и быстро писать программистам. Но программы, написанные на Go, потом дорого и трудно сопровождать мейнтейнерам.
А на каких языках программы легко сопровождаются?
Если сопровождение админами серверов, то им легче сопровождать на скриптовых.
Сказал А, говори и Б.
Скриптовые это какие?
Баш портянки поддерживать нормально невозможно, пердолиться с версиями и окружении питона не сильно лучше. Гошка для девопсов отлично подходит.
> Баш портянки поддерживать нормально невозможноИз всех интерпритаторов, баш (точнее клаccический sh/dash) поддерживается десятилетиями и без проблем, т.к. не ломают обратной совместимости
"Поддерживать" в моем комментарии означает "исправлять ошибки и дополнять/изменять функциональность". А не "адаптировать под новые версии" интерпретатора/компилятора.
>"адаптировать под новые версии" интерпретатора/компилятораЭто диверсия, а не поддержка. Типичная тактика гугла и прочих корпоратов.
> "Поддерживать" в моем комментарии означает "исправлять ошибки и дополнять/изменять функциональность".Так и я про то же, хоть на 30 лет назад откатись и все тот же синтакс и семантика, в отличие от питона,пхп и прочих популярных интерпритаторов, где с новыми версиями языка ломаются скрипты и их надо именно "адаптировать"
На языках, на которых не принято при сборке вендорить пол-интернета. В реальной жизни практически любая go-программа имеет несколько десятков зависимостей в go.mod, а те, в свою очередь, имеют свои зависимости (иногда не меньше). И опакечивание такой программы превращается в квест, который заканчивается (и почти везде так и закончился), что мы просто весь этот мусор собираем статически и кладем в один пакет. (Привет, любителям динамической линковки и разделяемых библиотек). Язык просто не должен обладать возможностями и тулзами, которые способствуют делать плохо. А go полностью из этого и состоит.
Таких как ты хочешь - больше не делают.
Хотя не можно gfortran2k3 установить, и он будет работать :)
так пейши на стандартной либе и/или подсовывай зависимости руками
Дай мне любой язык и я сделаю плохо🤣
>легко сопровождаются?RPG (https://en.m.wikipedia.org/wiki/IBM_RPG)
В нём процедуры - это просто исполняемые файлы (exe), а список параметров можно расширять, причём процедуры, которые использовали эту процедуру с более коротким списком параметров, изменять не надо.Также легко сопровождать программы на Lisp и на императивных языках.
Трудно сопровождать - на структурных языках.
Ты ___сам___ его пробовал?!
Тут тусовались as/400-ки - спроси у них, всю глубину глубин тЫгсказать...И вообще - _всё_ что голубые делают в софте получается даже не голубым а коричневым! ... и запах!(С)
;-)
Вероятно, потому ему и идеален. Бывает.
А, особо жесть у него про лёгкость сопровождения в перечисленном... Автору м.б., как и Brainfuck тоже тогда.
Но, тогда ему не хватает хотя бы: ОГРОМНЫЙ-IMHO
Наоборот, писать их сложно и медленно из-за кривой обработки ошибок, уродского синтаксиса, скудности стандартной библиотеки, невыразительности самого языка и помойки "тяни-любое-гно -с-гитхаба" вместо экосистемы сторонних модулей. А сопровождать как раз тривиально, ибо go build и всё, причём сразу с кросскомпиляцией.
> сопровождать как раз тривиально, ибо go build и всё, причём сразу с кросскомпиляциейНатянул смысл термина сопровождать...
Да все так и гораздо безопаснее сей.
То что го гораздо лучше раста это просто база.
То что Rust гораздо лучше Go - это база.
Неотключаемый сборщик мусора - огромнейший минус.
Постоянный подсчет процентов переписанного кода (вместо наличия реальных продуктов) - вот это реальный минус
Главное не забывать defer ставить, чтобы память не подтекла...
CVE-2025-4673
Уязвимость Golang Go существует из-за того, что конфиденциальные заголовки не очищаются при кросс-доменных перенаправлениях в пакете net/http. Эксплуатация уязвимости может позволить нарушителю, действующему удалённо, получить конфиденциальную информацию.CVE-2024-45336
Уязвимость языка программирования Golang связана с недостаточной защитой служебных данных. Эксплуатация уязвимости может позволить нарушителю, действующему удалённо, получить несанкционированный доступ к учётным данным.CVE-2024-45341
Уязвимость языка программирования Golang связана с неправильной проверкой входных данных. Эксплуатация уязвимости может позволить нарушителю, действующему удалённо, обойти внедренные ограничения безопасности.CVE-2025-22866
Уязвимость компонента crypto-elliptic языка программирования Golang связана с отсутствием освобождения памяти после эффективного срока службы. Эксплуатация уязвимости может позволить нарушителю получить доступ к конфиденциальной информации.
CVE-2025-22871
Уязвимость пакета net/http языка программирования Go связана с недостатками обработки HTTP-запросов. Эксплуатация уязвимости может позволить нарушителю, действующему удалённо, выполнить произвольный код.
Он особенно хорош тем, что вокруг него не скопилось достаточно людей, подменяющих написание работающего кода чем-то еще. Многие вещи, вокруг которых строятся сравнимые с отправлением культа процессы в экосистеме голанг технически невозможны.
c#
Его уже выпустили.
А по законам зекавским шарит?
По-моему уже всем очевидно, что го не удался. Сборщик мусора -- это сразу красный флаг (stop the world, все дела). Если нужен язык, способный компилиться в нативный бинарь -- то раст гораааа...(прошла минута)...аааздо лучше.
Если Rust хорошо, то Swift ещё лучше, т.к. он сделан святыми людьми из святой компании
Вендорлочная фигня.
так и раст жеж
нет
Ассемблер уделывает ваш раст как в простоте, так и в производительности
Начнем с того, что инструкции, сгенеренные современными компиляторами, уделывают инструкции, написанные человеком, независимо от того, насколько этот человек гениален. Мы уже давно не в 70-ых, чувак. Компиляторы продвинулись гораздо дальше, чем "MOV EAX, 42" в лоб.
...и именно поэтому в любых языках, которые претендую на системность, есть возможность вставлять ASM-блоки, да?
Это меня как-то опровергает?
Да, по крайней мере косвенно. Если компиляторы производят более качественный код, то нет причин использовать асм, чего мы НЕ наблюдаем
Не все операции доступны через интринзики, только и всего
Ну расскажи каких это asm операций тебе не хватает в совремнных компиляторах...(но, то что компиляторы давно неплохо оптимизирую - не спорю, часто лучше ручного и порой вовсе шикарно на первый взгляд но, вот только дело в том что они так пишутся чтобы искусственно устаревать компы - хорошо оптимизируя для самой последней(их) архитектур ЦП - а, остальные все и даже все не от Intel - идут куда подальше! А, то и начиная дополнительно тормозить из-за оптимизации под топовую архитектуру, отсюда дополнительные тормоза у всех пользователей не смотря на всё более новые версии (всех раскрученных)компилятора(ов) с всё более улучшенным оптимизатором. Который для топовых ЦП - как раз ВСЕГДА куда менее нужен за счёт его большей же мощности чем у не из топовых. Т.е. если с ним у тебя 60 FPS на топе а на не из последних архитектур цп - например 30 FPS, а то же на более старом [том же] компиляторе и когда там с полноценным оптимизатором но ещё типично настроенном под ту тогда топовую архитектуру - 60 FPS, да пусть даже 40(т.е.всё же заметно больше погрешности измерения, чем 30 FPS), то вот тебе и каждый раз "в новой версии - улучшенная оптимизация", проблема эта решаема но, не выгодна разработчикам расматриваиемых компиляторов а, часто и разработчику софта из-за доп.затрат на тестирование на не топовых цп, т.о. часто образуя фактически сговор тут, пусть и не гласный, из-за перекладывания своих расходов - на миллионы/миллиарды пользователей; что решается только введением стандартов качества и производительности и ОТК к нему, причём для каждого релиза и обновления, а значит opensource шара пролетает, хоть конечно люди и на freeware умудряются зарабатывать но, тут ещё же вопрос ответственности требует продуманности)
А в чём проблема дать написать инструкции ai-боту, вместо неоптимизированного мясного мешка?
Проблема в том, что мясной мешок понимает, что он делает.
А ai-бот это попугай-олигофрен. Он может только повторять, ничего нового он не способен создать. Он даже оптимально распределить регистры не сможет, нет у него такой способности.
Это не правда. Посмотри хотя бы канал 3blue1brown на youtube с визуальным описанием как gpt работает. И это на текущий момент уже даже не самая новая инфа.
> Это не правда. Посмотри хотя бы канал 3blue1brown на youtube с визуальным описанием как gpt работаетЧел, не трать время - этим воинам против ИИ бесполезно что-то объяснять.
Так не надо объяснять. Покажи готовую реализацию распределения регистров, которую сделал ИИ. Это нетривиальная задача, интересно посмотреть как мощный искусственный интеллект решит ее лучше чем кожаные дурачки.
> Это нетривиальная задача, интересно посмотреть как мощный искусственный интеллект решит ее лучше чем кожаные дурачкиЧто, еще нетривиальнее, чем шахматы и Го?
Пример - некорректный же. Там вроде был сверх-специализированный ИИ... (и GPT ли?) А, он явно про общий.
Хоть и эти уже - просто как из фантастики.
Точней - уже куда круче того что я в ней встречал. Пусть это кому и не видно, из-за ИИ фантазирования и брехнотрёпства/вредительства или узости тем общения.В общем то, не вижу проблем сделать специализированный или натренировать общий GPT, так же как просто писать на высокоуровнёвых языках ныне. Но, тут же в случае нетривиальности кода/проекта - куча вопросов доверия и ответственности поднимается... человек хотя бы знает что его за саботаж и просто вредительство в коде могут даже посадить/прикопать, и то может же рискнуть навредить, а вот ИИ-компилятору(т.б. сделанному не тобой а, даже заведомо врагами тебе)?...
Т.о.даже если сделать - адекватные люди не будут пользоваться ИИ-компилятором, а прочих самих лучше за решотку отправить, пока серьёзно не навредили, и не только таким образом.Впрочем, видим что и обычные современные компиляторы не многим лучше в безопасности
(вон же писали что MS VS одно время, пока публично это не раскрыли, даже вставлял код не запрошенного автором подключения к сети и т.д.! да и без этого всячески идентификаторы авторства скрыто пихая, впрочем не исключено что и что угодно там и ранее было но как узнаешь когда кода много), и даже вот сегодня ранее косвенно упомянул и open-source компиляторы тут:
https://www.opennet.dev/opennews/art.shtml?num=63710#76
На вопрос "Сколько время?" ИИ развернуто и структурировано ответит всё что он знает о времени. ))
> 3blue1brownДаже искать такое не буду, дабы статью какую не схлопотать.
До 1 сентября еще все можно.
>Посмотри хотя бы канал 3blue1brown на youtubeНеправда, эта мясорубка не может работать плохо. Посмотрите как она наяривает в рекламном ролике Магазин на диване. ))
Человеческий мозг потребляет всего 20 Вт на решение сложных проблем (миллионы лет эволюции), но уберубогоLLMмашины так не могут
Был бы умным - потребовал бы от Дарвина и его научных сторонников - доказательств, в их Эволюции человечества,
- чуть более чем, на половину череп макaки, выдаваемый за череп предка человека.
Ну ну. Видел я этот сгенерированный код. Даже при максимальной оптимизации часто лучше руками написать.
Видел я этот написанный руками код, 5 лет ревьювил, половину лучше бы бот генерировал.
>Видел я этот написанный руками код, 5 лет ревьювил, половину лучше бы бот генерировал.Скоро ваша мечта исполнится ☺.
В зависимости от задачи, кому то - уже... т.б.не умеющим программировать, сам уже сталкивался с такими людьми, причём с весьма нетривиальными задачами.Точно известно: ИИ - создаёт код сайтов, разный код даже минимум знаю 2D игры...
так же 3D модели, 3D уровни в 3D-редакторе тут писали же помогает, да и прочие все ресурсы для игр, особо жесть в ч.н. с музыкой и рисунками - уч.что, ещё недавно можно было услышать что, ИИ обобщённо говоря - никогда не сможет быть хорошим музыкантом, художником и что либо сочинять а, тут на те... вот уже и в (удобно кое-кому скрыто управляемого) бога-правителя готовят...
Кто идет он железки, предпочитает ассемблер, си. Кто идет от "кнопочек" предпочитает ИИ.
Хаха. Сразу видно эксперта.
Там, где нужно ДЕЙСТВИТЕЛЬНО что-то быстро делать, приходится писать на ассемблере.
https://github.com/FFmpeg/FFmpeg - Assembly 7.9%
> Assembly 7.9%Ты хотел сказать ВСЕГО 7.9%
Учитывая что считают по строчкам кода, а асм нааамного многословнее любого языка, то там именно "действия" меньше 1%.
> Ты хотел сказать ВСЕГО 7.9%Зато быстро! 😭 Зато уделали компилятры языка С! 💪
> то там именно "действия" меньше 1%.Хватит даже и 3-5 строк - когда там очень "тяжолый" цикл...
> Хаха. Сразу видно эксперта.
> Там, где нужно ДЕЙСТВИТЕЛЬНО что-то быстро делать, приходится писать на ассемблере.Хаха. Сразу видно эксперта.
Там, где нужно действительно быстро, юзают 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, блейд-системы и еще разные узкоспециализированные железки.
Но это все как бы отдельные железки, они отдельно программируются, хотя даже по ним видно - чем на более низком уровне вендор дает возможность их программировать/конфигурировать, тем больше можно из них выжать производительности.
> Нет, там вполне ясно написано "compilation of PTX for a specific GPU can happen just-in-time (JIT) at application runtime".
> Это IR, не ассемблер для конкретного железа.Ну так там же написано, в чем суть:
NVIDIA GPUs of different generations and even different products within a generation can have different ISAs. This is part of the reason for having PTX.
Как ты сам видел, что у Nvidia, что у AMD архитектур уже в несколько раз больше, чем у CPU. Поэтому и причина того, что:
> Для актуальных GPU ты не можешь разрабатывать на ассемблере так же, как и для x64/arm/risc/mips и т.д.
...вовсе не в "анальной огороженности железа", а в том, что ну не вытянешь ты ручками писать асмом под 15 разных архитектур GPU - тебе нужно будет как минимум знать работу каждой железки на уровне ее инженеров, чтобы твои "оптимизации" действительно были оптимизациями и имели бы практический эффект.
В целом, удивительно, как можно петь про "огороженность" АМДшного железа в свете того, что спеки открыты и по ним HIP может генерировать код для RDNA и более новых архитектур.
>>Вряд ли набор инструкций новой микроархитектуры будет примо на 100% отличаться от предыдущей.
> Даже в статье википедии написано про отличия в instruction set между GCN и RDNA. А есть уже RDNA 2, RDNA 3 и RDNA 4.А где я писал, что отличий нет? Лучше тебе на подумать, как asm() в hipcc может не поддерживать что-то кроме GCN, если сам hipcc генерирует инструкции для того же RDNA и новее. Как я и говорил, вероятно документацию просто не обновили, и ты вполне себе можешь ковыоюряться в асме вручную.
"Хаха. Сразу видно эксперта."
> Ты наверное не в курсе, но вендоры не дают доступ к ассемблеру GPU. Если бы он был, очевидно что самые горячие места переписали бы на нем.Как это утверждение противоречит его словам о том, что для МАКСИМАЛЬНОЙ производительности уже давно используют GPU, а не греют CPU? И что в областях 3Д рендеринга, крипты и Machine Learning твой GPU с ассемблером абсолютно бесполезны?
> И что в областях 3Д рендеринга, крипты и Machine Learning твой GPU с ассемблером абсолютно бесполезныТы хотел написать "CPU", я надеюсь? 😂
О, еще один эксперт.
Максимальной производительности ЧЕГО?
Про ASIC'и ты тоже не слышал?Или у опеннетовцев какая-то профдеформация - читают про ассемблер и не понимают что они могут быть разные, в том числе и для GPU.
Еще раз - чем более низкий уровень доступа к железке дает вендор, тем больше из нее можно выжать производительности. Если бы вендоры давали доступ к ассемблеру GPU, то на нем переписывали бы горячие куски и увеличивали производительность. Так же, как сейчас делают на "традиционных" CPU.
> Максимальной производительности ЧЕГО?Алгоритмов, наверное? Или мы о чем сейчас говорим?
> О, еще один эксперт.
> Про ASIC'и ты тоже не слышал?Чел, ну тут ты уже совсем чушь пореш, на серьезных щах сравнивая мощности аппаратной (тот самый ASIC) и программной программной реализацией одного и того же алгоритма.
> Если бы вендоры давали доступ к ассемблеру GPU, то на нем переписывали бы горячие куски и увеличивали производительность
Посыл был в том, что МАКСИМАЛЬНУЮ производительность ты на своем компе получишь только при использовании GPU, а не CPU с асмом. А ты все про "если бы у бабки был х...".
> Посыл был в том, что МАКСИМАЛЬНУЮ производительность ты на своем компе получишь только при использовании GPU, а не CPU с асмом.Что?... Смотря какая задача и какие методы оптимизации используются, насколько обоюдно.
Например, на алгоритмах сжатиях даже совершенно разных - GPU жутко лажает.
Движок игр, сама ОС, даже видеодрайвер и DirectX - тоже выполняются именно на ЦП "почему то"...
Это далеко не так... Написанный ручками код на интринсиках может быть быстрее в разы. Наблюдаю это прямо сейчас.
>Начнем с того, что инструкции, сгенеренные современными компиляторами, уделывают инструкции, написанные человекомТы хоть раз смотрел в дизассемблерные листинги прог, скомпилированных компиляторами?
Ты хоть раз видел вручную написанный на ассемблере код?
Скорее всего ни того, ни другого, но ценное мнение вещает.
Тут не хватает уточнения: что, далеко не всегда более короткий код - более быстрый. И что, даже не всегда более оптимизированный код - гарантированно будет исполнятся заметно быстрей, причём это по кучи причин. Именно потому чаще на ассемблере - оптимизируют только отдельные самые тяжолые блоки. Хоть это конечно не значит что, если всё делать на ассемблере нельзя получить доп.выигрыша, вот только он сильно непредсказуем и даже весьма зависим от программиста, задачи и целевой архитектуры цп.Но, тот кто умеет на ассемблере оптимизировать, для чего нужна практика,
- оптимизированней может писать и на не-ассемблере... Потому его ассемблерная версия - может и не отличаться по производительности от ассемблерной, например. Что не так - у не знающего ассемблер и его оптимизации. Хоть если ему подфортить "сливом" оптимизаций в ЦП -то результаты могут быть эквивалентны. Т.к.архитектура современных и даже 20-ней давности ЦП весьма трудно предсказуема из-за внутренних оптимизаций и скрытых ограничений неизвестных широкой публике даже при желании. Т.о.тут лотерея - повезёт/нет с оптимизацией.
Вы шутите? Кто в 2025 году будет писать софт для серверов на ассемблере? Можно ссылочку на такие проекты?
> Вы шутите? Кто в 2025 году будет писать софт для серверов на ассемблере?Ты на Опернете, друг. Тут местные эксперты и не такой бред пишут.
Подтверждаю, уровень экспертизы местных экспертов выше любых ожиданий и за пределами понимания!
Вовсе не только на опеннете:
> Кто в 2025 году будет писать софт для серверов на ассемблере? Можно ссылочку на такие проекты?Например, "Making Minimalist Web Server in Assembly on Linux (x64)"
youtube. com/watch?v=MpsDNv-I8i0И прочее использование:
Совремнная (пусть и заброшенная за отсутствием перспективности доходов с проекта авторами) попытка проекта:
"Майнкравт на АССЕМБЛЕРЕ!":
youtube. com/watch?v=34Zf1TVbS0Y
Или
"Написал нейросеть на языке ассемблера (Assembler, FASM), система технического зрения":
youtube. com/watch?v=ultmESX4VAUИ просто пример, пусть и древней, уже готовой успешной ААА игры, тоже можно считать полностью на ассемблере:
"ЭТА ИГРА СОЗДАНА НА САМОМ СЛОЖНОМ ЯЗЫКЕ ПРОГРАММИРОВАНИЯ! 👩💻🎢":
youtube. com/shorts/NAc8P6xr6XUТ.б.всякие самодельные ОС,и оптимизации звука и видео обработки, в игровых движка с оптимизацией, в звуковых и графических драйверах ОС.
А кто будет писать софт для серверов на расте?
> А кто будет писать софт для серверов на расте?Напр. чуваки, через которых идет трафик к каждому пятому сайту.
Написали как замена 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)
>>Но сам факт того, что конторе, которой нужен очень надежных инструмент с хорошей производительностью, выкинула nginx с сишкой на мороз и написала свое на расте, которое еще и оказалось быстрее, говорит очень о многом.Без бенчмарков вообще ни о чем не говорит.
И да, насколько я понимаю - это библиотека, а не законченный продукт.
Так что неплохо бы то что у них на базе этой библиотеки работает, еще бы и по функционалу с nginx сравнить.
Потому, что специально заточенное решение всегда будет эффктивнее.
Любой, кому Go недостаточно, а с крестами связываться не хочет.
Я бы не сказал что на расте писать сложнее или дольше чем на гошке. Так что если ты знаешь раст, то голанг тебе наверное не нужен. Оба языка отлично подходят для сервера.
А ниче тот факт, что целые операционные системы пишут на ассемблере?
> А ниче тот факт, что целые операционные системы пишут на ассемблере?В 2025 году?
Разве что если начали лет 20 назад, и двигаются по инерции.Если ты про коллибриОС, то она оказалась никому не нужной.
> Если ты про коллибриОС, то она оказалась никому не нужной.миникс тоже никому не нужен был, а поди оказалось, что пригодился в самом нужном месте ;)
//www.opennet.ru/opennews/art.shtml?num=47539
>> Если ты про коллибриОС, то она оказалась никому не нужной.
> миникс тоже никому не нужен был, а поди оказалось, что пригодился в
> самом нужном месте ;)Вот когда пригодится, тогда и поговорим (с)
Систему пилят с 2004 года, там уже были сpaчи и форки (собственно сама колибри это форк MenuetOS).
А толку?
> Вот когда пригодится, тогда и поговорим (с)Ок, у меня хорошая память, напомню вам (ц)
> А толку?
Любой софт (не заказанный), в первую очередь пишется для себя. :)
> Ок, у меня хорошая память, напомню вам (ц)Да без проблем.
Я умею признавать свои ошибки.>> А толку?
> Любой софт (не заказанный), в первую очередь пишется для себя. :)Тогда можно дойти до темплеОС, как средство от (или для?) шизофрении.
Но ценности для человечества оно не добавит)
> Но ценности для человечества оно не добавит)альтруисты в треде пхааа, человечество - стадо, ресурс, "скот". Это "общество" должно ценить каждого индивида.
>> Но ценности для человечества оно не добавит)
> альтруисты в треде пхааанеа, тут ты ошибся
темплОС вообще бесполезна для меня, а т.к я - непосредственная часть человечества...
Другие разработчики и пользователи могут рассуждать так же.
> темплОС вообще бесполезна для меняона не создавалась вам в пользу, это продукт болезни людской (гениальность пора уже диагностировать как "болезнь"). Когда у вас в голове заиграет музыка, тогда осознаете, что вы Моцарт :) Поскольку она у вас не играет, Моцартом вам не быть.
> Другие разработчики и пользователи могут рассуждать так же.
Другие стали "разработчиками", потому-что какой-то "больной" выдумал "бесполезное программирование" для посредственного "дворника".
> темплОСютуб, щас мне в рекомендации сунул его стрим (фейспалм)
>Тогда можно дойти до темплеОС, как средство от (или для?) шизофрении.TempleOS часто упоминается в комментариях анонимными экспертами потому что среди них много не диагностированных шизофреников или просто ценителей?
вопрос же в другом, способны ли вы, "нормальные" без шизы, написать TempleOS?
> вопрос же в другом, способны ли вы, "нормальные" без шизы, написать TempleOS?Думаю нет. Такое можно писать только или с шизой или под веществами.
Вообще с шизой можно много чего делать, вот только ценность будет как у "🐓 из 💩"Хоббийных осей написано много, некоторые даже местами используюся.
Некоторые просто для обучения.
> Такое можно писатьимеется ввиду "неработающее" и не "готовое" для вашего потребления?
> Вообще с шизой можно много чего делать, вот только ценность будет как
> у "🐓 из 💩"Ценность понятие такое себе, особенно когда встает вопрос "кто оценивает-то?", чтобы "бездари" могли оценить дар "божий" (I was chosen by God make His Temple. I was given divine intellect.)
> Хоббийных осей написано много, некоторые даже местами используюся.
> Некоторые просто для обучения.Для него это не было хобби.
> имеется ввиду "неработающее" и не "готовое" для вашего потребления?Так оно и для практически любого потребления не готово: сети нет, изоляции нет, VGA режим и 16 цветов (в 2003 году...), свой диалект си.
> Ценность понятие такое себе, особенно когда встает вопрос "кто оценивает-то?", чтобы "бездари" могли оценить дар "божий"
Это уже оценил его психиатр: там и биполярочка, и шиза, и инопланетяне и еще куча всего.
> I was chosen by God make His Temple. I was given divine intellect.
И при этом он же говорил про себя:
"It looks a lot like mental illness, as opposed to some glorious revelation from God." motherboard.vice.com/read/gods-lonely-programmer
Но это нормально для биполярного расстройства.> Для него это не было хобби.
Для него это было проявление заболевания, что-то вроде паталогического желания.
> Так оно и для практически любого потребления не готово: сети нет, изоляции
> нет, VGA режим и 16 цветов (в 2003 году...), свой диалект
> си.автокомплит в редакторе зато был :)
> Это уже оценил его психиатр: там и биполярочка, и шиза, и инопланетяне
> и еще куча всего.Инфу о псих. состоянии никто не имеет права распространять, так что шиза там или биполярка, а может и похлеще - все это относится к категории домыслы, ибо доступа к этой инфе (о диагнозе) мы не имеем. Мое личное мнение - биполярка и маниакальный синдром.
> Для него это было проявление заболевания, что-то вроде паталогического желания.
Маниакальный синдром.
пс: 3 дня назад (11 августа) как раз была годовщина его смерти.
> Кто в 2025 году будет писать софт для серверов на ассемблере?за еду уж точно никто не будет, а вопрос надо бы переформулировать, кто заказчиком то будет?
> Вы шутите? Кто в 2025 году будет писать софт для серверов на ассемблере? Можно ссылочку на такие проекты?Ну не на чистом асме, но на интринсиках каких-нибудь avx2 - да, пишем, производительность выше в разы
> Вы шутите? Кто в 2025 году будет писать софт для серверов на ассемблере? Можно ссылочку на такие проекты?Держи тебе ссылочку: https://github.com/johnfound/asmbb
> Ассемблер уделывает ваш раст как в простотеНе будь пустозвоном и покажи 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 и пару знаков препинания.Ну, или сишочник, лол. 😂 У этих ребят вообще символ и байт - синонимы, ибо нормальных строк они и не видели.
Зато нагородили простыню асма, и теперь линейный поиск нуля стал... быстрым линейным поиском нуля! Ну, то есть как быстрым... Все еще медленне, чем даже в скриптовом Питоне, где, как и в любом адекватном языке, количество символов вообще не нужно считать, ибо оно храниться в переменной, являющейся частью строкового типа.
Когда вы поймёте, что процессор оперирует байтами, а символами - приходите программировать.
> Когда вы поймёте, что процессор оперирует байтами, а символами - приходите программировать.регистрами фиксированной длины
Минимальная единица адресации == 1 байт. Про тyнцa рассказывать?
Да, до сих пор есть куча машин где это не так, но ты не факт что с такими работал.
Вообще-то(С) до IBM S/360 - таких было дофига, даже наш БЭСМ брал минимум слово, но вот народу зашло и теперь - так ...
> Ну, или сишочник, лол. 😂 У этих ребят вообще символ и байт - синонимы, ибо нормальных строк они и не видели.А реализации Unicode по твоему не на Си сделаны? Лашпак :)
Для совсем уж на всю голову волшебных, то что в Си называется "строкой" ... ну да состоит из байтов :)
И раз уж тут по $subj (который как известно умные люди делали) - то в нем _две_ функи возвращающие длину строки :) Одна как раз тупо _в_байтах_ ;-) для системных вещей. Живи теперь с этим.
Вторя (utf8.RuneCountInString) отдаёт длину в рунах (codepoints), для бусинеЗЪ-ложыки, а то начнёте тут щаз фантазировать...Имена Си-шных аналогов оставлю на домашку, мамкиныпрограммеры :)
ППЦ, пиплы с юникодом уже более 20 лет сношаются, а всё ещё тайна великая :)))
> Подсчет символов в строке (strlen) в libc буквально написан на ассемблере
> https://github.com/openbsd/src/blob/master/lib/libc/arch/amd...По причине того, что в дыряшке убогая нуль терминированная строка.
В нормальном коде просто бы спросили "а сколько у тебя символов и сразу получили ответ".> Код не простой, конечно, но достаточно короткий и быстрый.
Работает с utf8? А если глифы динамической длинны?
Тогда привычно выходим за пределы буфера))?Ты сейчас приводишь примеры того, как лепят костыли героически преодалевая трудности.
> Подсчет символов в строке (strlen) в libc буквально написан на ассемблере[...] достаточно короткий и быстрый.
Быстрый, лол. Ты сколько это недоразумение асмом не обмазывай, а оно все равно будет тормознее даже скриптоты типа Питона. 😂Потому что будет бежать по всей строке в поисках нуля, в то время как в нормальных языках с человеческим строковым типом - просто вернется значения инта, хранящего количество символов.
Это просто феерический пример, когда гениальный дедовской дизигн настолько ущербен на корню, что его даже ассемблерные оптимизации под целевую платформу не могут спасти. Но нет: сишочники с упорством барана накатывают оптимизации на то, что давно нужно выкинуть на свалку.
Подозреваю, что прежде чем упомянутое значение инта было прописано в структуру строки, кто-то как-то это значение посчитал. Если ты не в курсе, на Си можно не только посчитать длину строк, включая utf8, но и хранить эту длину рядом с указателем на строку и больше подсчетами не заниматься.
> Подозреваю, что прежде чем упомянутое значение инта было прописано в структуру строки, кто-то как-то это значение посчитал.Тебе объясняют, что длина - часть структуры строки, и операции над строкой при необходимости обновляют её длину, а ты продолжаешь думать, что её нужно каждый раз пересчитывать. Проф-Си-деформация налицо.
Так эти бедняги другой жизни и не видели.Вон выше еще один сишочник на это возразил, что "процессор оперирует байтами" (хз, какая связь с нормальными строками, но ладно) - и поэтому, видимо, эти персонажи будут продолжать упрямо дергать strlen на каждый чих.
Этот рак пустил метастазы в набор инструкций x86:https://www.felixcloutier.com/x86/pcmpistri
> ... A byte/word is considered valid only if it has a lower index than the least significant null byte/word.
SSE4.2
>> ... A byte/word is considered valid only if it has a lower index than the least significant null byte/word.Именно так и происходит, к сожалению.
Сначала одни гении решают экономить 1 байтик в строке
Потом у нас тоннына писанного хммм кода.
Потом такие же гении решают запихнуть костыли уже и в железо.А потом в современных языках приходится делать 2 вида строк, тк дыряшечное убожество расползлось по тысячам библиотек((
Так может дело не в языке, а в "персонажах", кто-то проверят пустая строка или не пустая через strlen, и что, язык виноват?
> Так эти бедняги другой жизни и не видели.Ну расскажи про то что видел ты онлифащица :)
> Вон выше еще один сишочник на это возразил, что "процессор оперирует байтами"
И ВНЕЗАПНА! - он прав! :) Прикинь?! Живи теперь с этим.
> (хз, какая связь с нормальными строками,
Вот по этому ты веб-мaкaкa, а не пргоаммер :)
> но ладно) - и поэтому, видимо, эти персонажи будут продолжать упрямо дергать strlen на каждый чих.А за тебя это будет делать твоя нода\пистон или что там у тебя :) Причем не когда ты хочешь, а когда оно само решит :) Прикинь?! Живи теперь с этим.
Ух! Аж настроение поднялось :)
хм, ты всегда такой дол№№№ или только по пятницам?>> Вон выше еще один сишочник на это возразил, что "процессор оперирует байтами"
> И ВНЕЗАПНА! - он прав! :) Прикинь?! Живи теперь с этим.Но, только на половину.
Возможно в его техникуми животноводства не рассказывали, что процессор оперирует не только байтами, но и битами.
И были процессоры с 12 битными байтами куда c ascii еще влезет, а были и 6-битные куда уже нет.
А про специализированные, типа DSP, лучше на вспоминать, чтобы не вызывать у колхозников культурный шок.> Вот по этому ты веб-мaкaкa, а не пргоаммер :)
опа-опа, кажется у нас тут гигачад программирования!
может поделишься репозиторием с достижениями?)
или твой удел только языком размахивать))?> Причем не когда ты хочешь, а когда оно само решит :) Прикинь?! Живи теперь с этим.
Ой, типа в дыряшке пограммисты решают, когда получит ̶а̶б̶ы̶р̶в̶а̶л̶г̶ SIGABRT по причине "вышли за границы буфера час назад" .
> Ух! Аж настроение поднялось :)
Нагадил в коммент и доволен?
Не то чтобы я сильно удивлен.
Ты, я смотрю, читать не научился. Покажи мне где я писал, что ее нужно каждый раз пересчитывать? Для непонятливых: есть буфер с строкой, есть размер строки в буфере; вопрос: как этот размер ИЗНАЧАЛЬНО там оказался? Кто-то же пробежался по этой строчке и посчитал буковки. Или в других, правильных языках длина строки в буфере появляется из астрала? Если данные изначально были не null-терминированы и размер был изначально известен, то и сишка ничего лишнего делать не обязана. Совсем недавно делал биндинг для liblua в си коде, в том числе была работа с lua строками. Ты же в курсе, что внутри строк lua могут быть \0 символы, а значит никакие strlen, strncpy и т.п. работать не будут? Код работает, брат жив.
> есть буфер с строкойВот это и называют сишкой головного мозга, уж извини за токсичность.
Нет в буфере никаких строк. Там байтики, которые станут строкой после валидации, если будут корректной последовательностью. И дальше работа будет со строкой, со всеми её свойствами и методами. Без необходимости её измерять.
А то что в си нет нормальных строк и приходится пердолиться с нультерминированными последовательностями, ну штошь, сочувствуем, но не разделяем.
Ну что ты как маленький. В буфере есть ровно то, что туда положили и как это назвали. Я же не просто так упомянул lua строки. Там это обычный набор байт, причем любых байт и от этого они не перестают быть строками.Вот тебе строка, как ты любишь:
struct superstring {
char *pointer;
size_t size;
};а вот тебе динамический буфер с бинарными данными (не строка!):
struct buffer {
char *pointer;
size_t size;
};Разницу видишь? Уж извини за токсичность.
> Вот тебе строка, как ты любишь:
> struct superstring {
> char *pointer;
> size_t size;Чел, сори, но это та самая сишка головного мозга, о которой он говорил. Ибо это не строка, а все тот же байтовый буфер, где size говорит о длине в байтах. О UTF-8 и Юникоде в целом мы традиционно не думаем, поэтому задачу "вернуть количество симолов в строке" вот этому твоему поделию придется решать за тот же O(n), что и strlen() (даром что utf8 в теории, поддерживается). И, соответственно, будет оно даже медленнее, чем Python-скриптота.
Что непонятного?
size хранит ровно то, что я хочу, чтобы он хранил. Если размер строки меняться не будет, то размер буфера мне без надобности, и в size будет лежать не длина буфера, а количество utf символов (не байт!). Если будет меняться длина строки, а значит и буфер, то к size добавится length. Если мне нужно будет резать строку, или что-то в ней искать, то это уже будет не utf8, а что-то другое. И все равно это будут строки. А вот у Python-скриптоты выбора вообще нет, зато думать не нужно.Но изначально я писал о другом: любому "неподелию" также придется хотя бы раз пробежаться по всей строке, чтобы выяснить ее длину и заполнить другие служебные структуры, поскольку большинство входных данных это utf8 с нулем на конце или буфер с размером.
> Если размер строки меняться не будет, то размер буфера мне без надобности, и в size будет лежать не длина буфера, а количество utf символов (не байт!).И что ты, интересно, собрался делать с такой "строкой", если у нет ни завершающего нуля, ни размера? 😂 Ни банальной конкатенации, ни вывода ее в файл/stdout у тебя не получиться.
> Если будет меняться длина строки, а значит и буфер, то к size добавится length.
И тогда твой аргумент выше про "Разницу видишь?" с двумя одинаковыми кусками кода лопается, не так ли?
> И все равно это будут строки. А вот у Python-скриптоты выбора вообще нет, зато думать не нужно.
Нет, дружок, в Python скриптоте точно так же можно героически сношаться с байтиками через bytearray() и т.п. Только вот те, кто таки думает - те вместо такой дичи используют инструмент, прямо созданный для задачи, т.е. строки.
> И что ты, интересно, собрался делать с такой "строкой", если у нет ни завершающего нуля, ни размера? 😂 Ни банальной конкатенации, ни вывода ее в файл/stdout у тебя не получиться.Если мне нужен будет размер данных в буфере, я воспользуюсь вторым вариантом или третьим. Выбор у меня есть.
> И тогда твой аргумент выше про "Разницу видишь?" с двумя одинаковыми кусками кода лопается, не так ли?
Еще раз - это все равно строка. Можешь назвать ее константой или literal или чем-то еще. Одной длины данных в таком случае за глаза хватит. У меня есть несколько проектов, где модификация строки не требуется вообще. Тупо взять на сервере и отдать клиенту с минимальными проверками. Нафига мне вся эта ненужная обвязка в таком случае, оверхеда ради? Мне скорость нужна, а не понты.
> Если мне нужен будет размер данных в буфере, я воспользуюсь вторым вариантом или третьим. Выбор у меня есть.Только некомпетентный сишечник вместо соответствующей задаче абстракции и ее проверенной реализации делает выбор в пользу своих корявых велосипедов. Причем сишечник, пишущий в одно лицо свои хэллоуворлды - ибо при работе над реальным проектом в команде ты бы за такое велосипедостроение сразу получил бы по шапке.
Сразу видно теоретика. Других аргументов нет?
Лол, а какие еще тебе аргументы нужны? Извини, но это факт.
> Сразу видно теоретика.Та не, друг, теоретик как раз у нас ты: у тебя вон выше целая ветка понтов "я и так бы мог, и сяк бы мог" о своих огрызочных велосапедах. А вот на практике было бы, как я и писал: получил бы за них по шапке от коллег, причем еще на этапе этой своей больной идеи.
> Вот тебе строка, как ты любишьДа, это эталонная демонстрация фундаментального непонимания сишниками концепции типов.
Для вас всё – байты, как в процессоре. Если процессор работает с байтами, то и мы будем!
Современные языки дают вам бесплатную и мощную абстракцию, а вы продолжаете бегать по граблям.> Вот тебе строка, как ты любишь
Нет, это не строка. Это просто жирный указатель, не более.
1. Он может указывать на что угодно. А может не указывать и быть равным нулу.
2. Он создаёт неоднозначность на ровном месте: пустыня строка это какое сочетание нулей/нулов в значениях?
3. Он абсолютно ничего не говорит о характеристиках строки. Сколько байт в ней занимает символ? Один байт? Два? Четыре? Пять с половиной? Сколько угодно?
4. Он абсолютно ничего не гарантирует в части содержимого: по адресу может быть мусор, и этот мусор может образоваться в любой момент и после вызова любой функции, работающей с этой "строкой".Можно и дальше продолжать, но смысл, если ты не понимаешь абстракцию типа.
> Можно и дальше продолжать, но смысл, если ты не понимаешь абстракцию типа.Как я уже говорил, этим персонажам что-то объяснять бесполезно - у них о одного слова "абстракция" уже припадок начинается.
> А то что в си нет нормальных строк и приходится пердолиться с нультерминированными последовательностями, ну штошь, сочувствуем, но не разделяем.Написать обвязку для паскалевских строк тривиальная задача. Раз написал и используй сколько хочешь. Мало того, уверен, что такие библиотеки уже есть на любой вкус и под любые требования.
В 80-е - начале 90-ых прошлого века, когда Си vs Паскаль было в самом разгаре ...
Ой ... чето звездными войнами повеяло :)))Так вот - _все_ Си-шники делали свою реализацию Pascal-string-s ...у меня к примеру на макросах была... работало, но _не_ пригодилось.
Кстати - все пасквилянты в ответочку :) делали Си-строки :) Хотя в борланде (кажись) встроенные были...А нынешним ... ну этим ... которых гопотой заменяют :) - вот им понять что строка нынче - это сложный обЪект - ТРУДНААА!(С)
Для системы - птр на начало, /0 в конце, знаем длину в _байтах_ ! :)
Для бусинес-ложЫки птр на (смотри в спеки чего это в реале) и полезно знать длину в рунах.Is that fucking Rocket Science, B0b?!?!
;-)
> Так вот - _все_ Си-шники делали свою реализацию Pascal-string-s ...у меня к примеру на макросах была... работало, но _не_ пригодилось.Конечно не пригодилось.
Если приучить людей, что можно писать овнокод, то зачем оно надо?
Это сейчас начинают задавать вопросы "а чего ваша злловонная куча такая дырявая?"> Для системы - птр на начало, /0 в конце, знаем длину в _байтах_ ! :)
Ага. На каждый пук бежим конец и дергаем за /0 считая длину за O(n)
Генитальнейшее решение!
Но это еще не все! можно эт о лабуду просто потерять в процессе пихания в различные буферы.А потом получаем вот такое
cvedetails.com/cve/CVE-2024-45288/
A missing null-termination character in the last element of an nvlist array string can lead to writing outside the allocated buffer.или такое
nvd.nist.gov/vuln/detail/CVE-2016-6187
The apparmor_setprocattr function in security/apparmor/lsm.c in the Linux kernel before 4.6.5 does not validate the buffer size, which allows local users to gain privileges by triggering an AppArmor setprocattr hook.или в БЗДе - nvd.nist.gov/vuln/detail/CVE-2000-0312
cron in OpenBSD 2.5 allows local users to gain root privileges via an argv[] that is not NULL terminatedЗдорово, правда! (с)
> Is that fucking Rocket Science, B0b?!?!
Это просто fucking №№№, CVEшки не дадуть соврать)
> Если ты не в курсе, на Си можно не только посчитать длину строк, включая utf8, но и хранить эту длину рядом с указателем на строку и больше подсчетами не заниматься.Можно, да. 😂 Но почему-то 97% сишочников продолжают гордо юзать и "оптимизировать" дидовские отрыжки в виде strlen. Видимо, не по-сишочному это - использовать здравый смысл и подходящие абстракции при решении задачи. Нас же только с байтиками научили сношаться, да еще и в асме.
Это где такое? В твоем собственном коде наверное? :)
Ну открой сырки к примеру мерзкого гнома, оно на Си - посмотри работу со строками...Ну ужас, но не ужас-ужас! (С) :)))
PS: Любой йунный Си-шник делал собственную Ымплементайи паскалевских строк. Я вот тоже, на макросах. Лет эдак ... да ППЦ просто, сколько лет назад! :( Работало ... но не пригодилось ;-p
Всякое попадается. Но не 97%. Откуда такая статистика?
В лучшем случае - из носа :) Но быстрее всего из (_|_)
Он не удался, потому что в нём нет классического ООП
>Он не удался, потому что в нём нет классического ООПВот это как раз максимально мимо ☺☺☺. Никому уже не нужен "классический ООП". А если вдруг взяться разрабатывать на Go в стиле ООП, обнаруживаешь, что даже это намного лучше, чем Java и C++.
>По-моему уже всем очевидно, что го не удалсяНет, не очевидно. Я сам поработал года два на Go, когда соскочил с C++ (потом перешёл на Rust). Go имеет право на жизнь, это альтернатива Питону, Джаве, PHP и прочему подобному; Go намного лучше и практичнее их. А Rust — альтернатива C и C++.
> Go имеет право на жизнь, это альтернатива Питону, Джаве, PHP и прочему подобномуGo - альтернатива Питону? А Баш им тоже поди можно заменить? 😂
Можно, почему нет. Юниксоподобным системам пофиг, бинарник или скрипт в текстовом файле.
> Можно, почему нет.Потому что отсутствует здравый смысл.
> Юниксоподобным системам пофиг, бинарник или скрипт в текстовом файле
Только человеку не пофиг, на чем писать скрипты на выброс.
Здравый смысл как раз присутствует. Можно не таскать рантайм и зависимости (привет node_modules), выше производительность (на порядок).
> Можно не таскать рантаймДа, очень здраво таскать исходники и компилятор, и делать собственно саму компиляцию, когда в "скрипте" нужно что-то поправить.
Я уж не говорю о том, что Питон есть из коробки на любом Линуксе и даже Маке. В отличие от компилятора Go, лол.
> выше производительность
Да, это очень важно в сценариях использования скриптовых языков. 🤦
> Здравый смысл как раз присутствует.
Напрочь отсутствует, что и требовалось доказать.
Ну ты же сам просил "скрипты на выброс"?
Вот у меня Go тоже установлен, как и пистон с башем...
И я иногда беру и делаю такой шебанг:#!/usr/local/bin/go run
Потому что могу!(С) ;-)
Фанбойчик питончика детектед ) Мало вайти в айти, надо немного осмотреться.
>таскать исходники и компилятор, и делать собственно саму компиляцию, когда в "скрипте" нужно что-то поправитьТаскать исходники и интерпретатор типа лучше? Не забывайте о том, что ваш скрипт работает только если установлены зависимости. Они зачастую компилируемые и вы их компилируете при установке. Или получаете опакеченными и с этим нюансов еще больше. И все это не портабельно между архитектурами и разными версиями ОС. Если вы с этими проблемами не сталкивались, то исключительно из-за недостатка рабочего опыта.
Перекомпилить гошную прогу - миллисекунды. И если собралось, значит в первом приближении работает. С динамическими языками заметить привнесенную при редактировании проблему сложнее.>Да, это очень важно в сценариях использования скриптовых языков
Да очень важно, если скрипт обрабатывает пайп, в который льются миллионы строчек. Обработать данные за 3 часа или за двое суток - характерная вилка для скриптовых языков.
> И если собралось, значит в первом приближении работает.Оптимист(С)
Как по мне:"если собралось, значит в первом приближении запускается."(С)
Как то таГ!(С) :)
> Таскать исходники и интерпретатор типа лучше?Еще раз: Питон есть из коробки на линуксах и маке. Читай, пожалуйста, не пятой точкой.
> Не забывайте о том, что ваш скрипт работает только если установлены зависимости. [...] И все это не портабельно между архитектурами и разными версиями ОС.
А гошные зависимости портабельны между архитектурами и разными версиями ОС? К чему ты вообще приплел зависимости, если в большинстве скриптов на выброс их вообще нет? А у тех, что есть - та же морока, что и программами на Го.
> Перекомпилить гошную прогу - миллисекунды.
С скриптоту не надо перекомпилировть. В этом весь смысл.
> Мало вайти в айти, надо немного осмотреться.
> Да очень важно, если скрипт обрабатывает пайп [..] Обработать данные за 3 часа или за двое суток - характерная вилка для скриптовых языковЧел, пайпы работают на уровне ОС, а не скрипта.
Очередной эксперт сел в лужу, зато с гонором про "вайти в айти". 🤦
ваш rust постоянно меняющееся переусложненное болото. ждем всех его преимуществ в C и C++
> ваш rust постоянно меняющееся переусложненное болото.ну так фиксируй edition и сиди сколько пожелаешь
это не будет отличаться от "30 лет на C89"> ждем всех его преимуществ в C и C++
ждите-ждите)
если они поломают обратную совместимость, плакать будете?
> ваш rust [...] переусложненное
> ждем [...] в C++Не, ну главное что C++ не переусложненное. 😉
> очевидно, что го не удалсяКак не удался?
Вот есть soong_build, написанная на go, - сборочная система для ОС android, точнее, генератор мейкфайлов. И вот, только этот генератор сжирает минимум 40 гигов памяти и заметное время. И при малейшем изменении какого-либо проекта - полная перегенерарция.
Так сказать, фильтр тех кто достоин собрать свой андроид.
>> очевидно, что го не удался
> Как не удался?Все major clouds - на Go, ога ога - не удался ;)
Просто чел вкинул, а ты как йунный - повёлся :)
Весь интернет в алфавите, преклонный падаван.Го удался, и алфавит тут не причем.
Ога - щаз!(С)
Я про облака, а алфавит там только нумбер _три_ ... :)
И в каком из них golang используется как основной? В Azure что ли? Даже в алфавите не основной/преобладающий язык.
> В команде "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 нет сборщика мусора, с которым утечек не должно быть по определению
Со сборщиками мусора утечки тоже есть, правда называются unintended retention.
> Со сборщиками мусора утечки тоже есть, правда называются unintended retention.Речь была про "at program exit"
Т.е когда все корневые объекты что разработчик выделял для хранения других объектов тоже признаны мусором
Сборщик мусора следит только за памятью. Освобождать другие ресурсы, такие как соединения и горутины - надо вручную.
Вот бы на него 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 же просто завершает с программу
Нет, он кидает панику с сообщением об ошибке в аргументе
> Это кидает паники, а их надо избегать.Надо обрабатывать каждую ошибку? А что делать при обработке?
Прокидывать выше, где она уже и будет обработана. Чаще всего уйдет в метрики и логи.
Но тупо прокидывать тоже плохая практика, нужно расширить контекст ошибки. Например мы вызвали некую функцию, которая делает запрос: err := DoRequestToStore(id). Мы можем вернуть ошибку выше в виде: fmt.Errorf("do request to store by id %s: %w", id, err). Таким образом мы в логах увидим где именно произошла ошибка и при каком действии.
Если не расширять контекст, то в логах будет обобщенная низкоуровневая ошибка, которая ни о чем нам не расскажет. Будет сложно понять что произошло.
Ну знаешь...по сравнению с 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.
Более лучший язык пока не придуман.
ЧатГПТ придумает скоро, раст покажется цветочком, сможет осилить только сам ИИ, но убедит кожаных что это лучший язык. Дальше вы все знаете продолжение что будет
Если бы он смог то уже бы написал.
Всё идёт по плану. Не торопитесь.
Есть же zig
Как? А цань-дзе? https://cangjie-lang.cn/en
Он понимает даже не совсем формальные конструкции, в нём развитые макросы и аннотации.
Во всех языках макросы принимают последовательность параметров, но макросы в цань-дзе принимают последовательность токенов, и выдают тоже последовательность токенов. https://mp.weixin.qq.com/s/cW697gXfH753NlPG7R_BLA
Однозначно, коллега!
Просто наблюдение, без токсирования. На 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++ , там тоже жирноты много, но хотя бы приемлемо.
> Это же почти треть СД диска..
По-твоему треть ссд-диска только на бинарники - это нормально?
> не пользоваться программами на ГО, а искать СИшный вариант
К счастью, на данный момент выбор как раз обратный. НЕ ИСКАТЬ программы на ГО, а пользоваться уже написанными и отлаженными СИшными вариантами.
Для CD не надо делать приставку диск потому что в аббревиатуре CD буковка D от слова disc.
> Это много?ты дурак? представляешь, что будет твориться с дисками в шелл-скриптах? или ты предлагаешь все шелл скрипты на свете переписать на вендорлок? так ведь тогда никаких дисков не хватит в принципе
>В результате имеем бинарники по 30МбГошный рантайм может быть в виде отдельной so'шки.
Вобщем-то верно, и такие компиляторы есть, которые транслируют в C: gccgo, GNU Pascal, GNU Modula-2, Vala, GNU Cobol
Только кто ими пользуется?Тот же Vala - интересный. Но т.к. на нём мало кто пишет, экосистема развивается медленно. Вплоть до того, что компилятор Vala генерит такой C код, на который gcc сыплет варнингами.
Смысл операционной системы - позволять пользователю запускать программы. И язык системы тут никак не должен влиять на то, на каком языке написаны программы.
Лучше не пользоваться, пока не уберут телеметрию
Или пока не актуализируют gccgo до версии эталонного.
Так не пользуйся, а мы деньги зарабатываем.
так вы деньги зарабатываете, пока другие пользуются, на то она и телеметрия. перестанут - перестанете
экосистема в гоу убогая, мало пакетов
питон в свое время взлетел, потому что сообщество написало кучу библиотек просто так за бесплатно
а в гоу этого никто не делает, потому что здесь все на порядок дорожесами посудите - кто в здравом уме будет создавать бесплатную экосистему для компилируемого языка, у которого порог вхождения сильно выше по сравнению с тем же питоном ?
> сами посудите - кто в здравом уме будет создавать бесплатную экосистему для компилируемого языкаmicrosoft, .net создали
и давно виндовс бесплатной стала?
Всегда была в умелых руках, есть иные примеры?
> и давно виндовс бесплатной стала?дотнет в 99% случаях это сервера в докере. Это золотая середина всего дебилизма, который накопился в разработке. Всё остальное ещё хуже
В джаве деды упоролись с билдерами фабрик провайдеров и унылым ООП/DDD образца 2004 года
В ноде - компиляция по 5 минут TS в JS, кривой NPM, и разваливающаяся на ходу сборка, которая раз в два месяца рассыпается, а если код не поддерживать пол года - можно выбрасывать
GO переупрощён и там как раз нехватает унылого ООП из джавы
c++/c для поехавщих пней, которые в 2025 году выползают за буфер.
питон вообще умалчиваю, он как нода, только разработчики бескультурные
То есть надо чтобы другие за просто так написали кучу программ на все случаи жизни чтобы самому оставалось только натаскать нужные библиотеки?
Ну... Да? Это сишники не ленивые и переизобретают велосипеды уже 50 лет - а остальным фигак-фигак н-нннада
> потому что сообщество написало кучу библиотекПутаешь причину и следствие. "Куча" – это следствие. Языки "взлетают" когда появляются ниши, в которые они удачно вписываются. Показательные примеры: руби и Раст.
А куда руби взлетел? А то я бы на него с радостью ушёл и даже забыл бы про линукс и купил бы макбук уже, чтобы не видеть питон и чтоб зарплата была больше, но что-то ниши нету.
Руби взлетел, когда появились рельсы. До этого был достаточно маргинальной поделкой японского хикки. Но не смог занять полностью нишу веба, потеснив PHP и не смог проявиться нормально в других отраслях, поэтому сейчас потихоньку угасает.Лично мне всегда не нравился из-за обилия магии и "есть 100500 способов сделать что-то", но не могу не отметить его красоту и изящество.
Сейчас пытается возродиться в Crystal. Посмотри, интересный проект.
Есть вакансия с Ruby на rosa.ru
> Путаешь причину и следствие.Вы оба путаете. Тут всё причины, и всё следствия. Как в случае курицы и яйца. В социальных вопросах как правило именно так и происходит. На самом деле в любой сложной системе способной гибко адаптироваться именно такое с неизбежностью и возникнет, потому что обратных связей там больше, чем прямых.
ОЛОЛО, через пакеты это самого Го уже раздают малварь чистящую сервера под ноль. Смузхлебы так хвастались что у них в язык встроены пакеты, не то что у дидов. Ну вот как видите фича работает, малварь качается.
> ОЛОЛО, через пакеты это самого Го уже раздают малварь чистящую сервера под ноль.Ага, как хорошо что у дырявых такого не бывает.
А, погодите-ка, всякие dirtyCow, хартблибы, CUPSы и ХЗ-библиотеки наверное завистники подбросили.> Смузхлебы так хвастались что у них в язык встроены пакеты, не то что у дидов.
> Ну вот как видите фича работает, малварь качается.Да встроены.
Но диды с майлварью справляются еще лучше - в ведре АНБшный бекдор жил 10 лет без всяких пакетов))
>релиз языка программирования Go 1.25, развиваемого компанией Google при участии сообщества.Хорош врать там где есть Google - там нет сообщества. Google - это же лютый копираст.
> Хорош врать там где есть Google - там нет сообщества. Google -
> это же лютый копираст.Хочешь сказать, что все эти тыщщи goшных либ на все случаи жизни гугёл сам написал???
А ведь именно они являются фундаментальной частью экосистемы го.
Хороший — и при этом седьмой-восьмой по скорости реальных вычислений.
Да и здесь было бы неплохо освежить данные: