У фреймворков есть недостатки: у них хуёвая оптимизация которая в первую очередь проявляется огромным пореблением памяти. Например открыть простейшее окошко на win32 api займёт 64кб, в то время как .net уже пара мегабайт. И из-за огромного слоя функций раздувается стэк + время тратится на 100500 вызовов из одной функции в другую.
Так вот теперь фреймворки нахуй не нужны, потому что есть нейросетки. Нейросетка теперь читает те самые 1000 ёбаных страниц говна и раскидывает тебе всё по полочкам. Что непонятно уточняй и т.д.
Поэтому всё. Нейросетки как ни парадоксально порешали именно любителей высокоуровневых хуёвин и сделали низукровневую разработку снова перспективной. К тому же реально назрело, фреймворки на фреймворках уже так заебали что даже новейшей железо убивают по производительности. К тому же в условиях дефицита комплектующих очень актуально писать сберегая циклы проца и байты памяти.
Сделали ставку на количество пожертвовав качеством, к тому же перспективы постоянно растующего по мощности железа были радужными.
И вот сейчас вышли нейросетки которые позволяет писать уже низкоуровневое ПО с высокими темпами. Так что пацаны, все идём в указатели, в ручное управление памятью и т.д. Я уверен что многие супер наноёба фреймоврки которые жрут по 2 гига в долгосрочной перспективе пойдут нахуй
>И вот сейчас вышли нейросетки которые позволяет писать уже низкоуровневое ПО с высокими темпами
Тем не менее Zed отказывается от дальнейшей разработки своей супер-оптимизированной GUI библиотеки и выбрал wgpu обычный растовский. Почему так?
https://news.ycombinator.com/item?id=47002825
https://github.com/zed-industries/zed/pull/46758
Почему они с LLM не могут поддерживать свою супер-пупер библиотеку для GUI?
>>3644165
>писать уже низкоуровневое ПО с высокими темпами
Писать то может и можно, а вот читать и отлаживать заебешься. Ну и легаси никуда не уйдет кстати.
Я вот ставлю что будет некоторый рост популярности раста, но не сильный. В основном бекенд как будет на .net/java/python/typescript делаться, так и будет дальше делаться, а не на расте писаться.
Писать ПО высокими темпами - кому надо? Большая часть технологий и продуктов уже написана и их не станут переписывать на Rust или не дай бог С/С++. Миллиарды строчек кода на джаве, питоне и прочих языках так и останутся там навечно, слишком дорого переписывать даже с LLM.
>>3644165
>Так что пацаны, все идём в указатели, в ручное управление памятью и т.д.
Нет, это плохие практики и никто не будет так писать код, даже с LLM.
Байтоеб, спок. Все еще надеешься найти работу после книг Столярова?
Никто не будет писать нейронкой низкоуровневый код. Его приходится не только писать, но и читать. Поэтому фреймворки и языки высокого уровня никуда не исчезнут.
Правильно мыслишь, согласен. По сути это простая логика: повышается производительность -> повышается эффективность. Производительность написания кода уже повысилась, но где эффективность? А вот для эффективности как раз нужно будет выкинуть все неповоротливые фреймворки вся суть которых была только в облегчении читаемости кода, а это как раз становится менее релевантным. Так что да, программирование будущего это миллионы ассемблерных строк которые разруливает нейронка, а нейронкой управляет инженер.
> И вот сейчас вышли нейросетки которые позволяет писать уже низкоуровневое ПО с высокими темпами.
Что-то может и напишут, примерно как они пишут для 1с, но это же говно говна не оптимизированное.
Нейросетка может сносно накорябать на питоне, жс, даже жабе потому что этого кода в ее датасетах много. А по низкоуровнему коду что там есть? На одном ядре пинукса многому не научишь.
Да и вообще идея генерировать нейросеткой код на языках, которые изначально создавались под человека ну так себе костыль. А ведь даже асемблер это человекочитаемая абстракция над машинным кодом.
У нас сейчас получается, что машина сначала генерирует человекочитаемый программный код, который потом обратно через компиляторы должен преобразоваться в машинный для работы. Хуйня какая-то.
Но и заставить нейронку адекватно генерировать сразу байткод как-то не получается, чтобы получилась не микропрограмма, а полноценный софт. И где взять датасеты для подобного обучения пока вообще не ясно.
Я не говорю про написание кода нейросетью, тем более низкоуровневого, он только ручным может быть. Я тред создал к тому что нейросети ускорят освоение программистом низкоуровневых API типа win32 api и аналогов. Нейросеть теперь читают муторную 1000 страничную документацию за секунды, выводит суть и можно уточнять до бесконечности что хочешь и как хочешь.
О том чтобы делегировать нейросетям код речи не идёт. Я к тому что низкоуровневое программирование стало доступней
>Почему они с LLM не могут поддерживать свою супер-пупер библиотеку для GUI?
Ну некоторые проекты просто принципиально делают какую-то фигню, объяснить это сложно. Вот LFS недавно отказалась от проверенной системы скриптов просто потому что сложнаа нипанятнаааа как букавок-то столько писать. Хотя щас почти любая нейронка може сгенерить мануал уровня LFS. Вот и думай есть ли вообще логика в таких мувах.
Если ты об этом, то тут ты мне кажется ошибаешься. От ручного написания кода ушли не просто так, он очень сложен в обслуживании. И дело вовсе не в том что тяжело было читать мануалы по вин32 апи. А вот чем тут реально может помочь нейронка - так это быстро находить проблемные участки кода, быстро вносить изменения в существуюший код. По сути все языки высокого уровня были сделаны чтобы облегчить эту работу. С нейронкой же можно вернуться к программированию в оп-кодах или ассемблере где человек будет писать основную логику, а нейронка поддерживать код и быстро исправлять баги.
>сберегая циклы проца
Никто их не считает с конца 90х. Основная проблема обмен данных с памятью.
>так это быстро находить проблемные участки кода
Вкурсе что существуют анализаторы кода?
>миллионы ассемблерных строк которые разруливает нейронка, а нейронкой управляет инженер
Ты не сможешь понять что делает этот код. И не сможешь его отдебажить. Для тебя код навсегда станет черным ящиком. Сейчас ты его хоть прочитать можешь, а потом уже нет. Любая попытка разобраться в том, что сгенерила нейронка будет как реверс инжиниринг бинаря - долгий и очень мучительный процесс. И нет, нейронка это не компилятор, который гарантирует результат. А еще генерировать миллионы строчек на ассемблере потребует больше токенов чем написание этого кода на языке высокого уровня. Плюс нейронки банально не умеют писать настолько длинные ассемблерные коды, их учили писать коды на языках высокого уровня.
Ну и я уже молчу, что пара строчек на какой-нибудь джаве/тайпскрипте/питончике это десятки тысяч тысяч строк на ассемблере. Объемы можешь имаджинировать.
Мне кажется мув тут был в том, что они банально не вывозят разработку своего GUI/GPU фреймворка и выбрали стандартный инструмент. Почему не вывозят? Ну видимо даже с LLM не получается такие вещи хорошо делать. Учитывая, что кроссплатформенный Гуи это всегда адская боль, особенно когда помимо macos и винды надо еще и линукс поддерживать с его зоопарком всего и вся.
>низукровневую разработку снова перспективной
Зачем?
Будут править нейронки в связке лоукод/ноукод/вайбкодом.
Пользователь приучен жрать медленное и тяжеловесное ПО.
Сейчас важен не комфорт пользователя, не качество ПО, а дешевизна разработки. Потому что железо всё равно дешевле даже самых паршивых кодомакак.
> фреймворки ВСЁ
ты сильно мелко взял. в принципе нет смысла писать на языках. сразу в машинные коды переводи и будет норм.
я думаю будут тупо чипы NPU которые просто уже загружают нейросети.
> Тем не менее Zed отказывается от дальнейшей разработки своей супер-оптимизированной GUI библиотеки и выбрал wgpu обычный растовский. Почему так?
Zed это долбоебы вебмакаки которые нагородили 1500 зависимостей.
> wgpu
у меня он крашится. через минуту пользования редактором.
> Почему они с LLM не могут поддерживать свою супер-пупер библиотеку для GUI?
потому что они дебилы. у меня GUI занимает 900 строк. да оно примитивно. нет поддержки векторных шрифтов и прочих иконок. но эта хрень работает всюду и не отваливается.
> Ты не сможешь понять что делает этот код.
вебмакака вроде тебя не сможет. а нормальные инженеры вполне такое прочитают.
Инженеры уже много десятилетий не читают ассемблерный код. Только разве что разработчики компиляторов.
В целом если бы LLM были такими "сверх-высокоуровневыми" компиляторами, то проблем бы не было. Но так как LLM не дает детерминированных результатов, то надо читать что она выдает. Ну если конечно тебе не похуй на результат.
>нейросети ускорят освоение программистом низкоуровневых API типа win32 api и аналогов
книжные библиотеки ускорят освоение программистом низкоуровневых API типа win32 api и аналогов.
защено нейросетью
> Инженеры уже много десятилетий не читают ассемблерный код.
исповедь вебмакаки.
тут сидят такие дебилы в разделе /pr походу дальше укладки джейсонов и монгодб нихера не видели.
Нейросети очень плохо пишут низкоуровневые программы. Они больше по декларативному программированию нежели императивному. В точных последовательных алгоритмах где важна каждая запятая они до сих пор хуевые, даже думающие флагманские модели.
Нщн ты не понимаешь что такой нейросеть. Они не про то что ты ей скормишь 1000 страниц и она вдруг научится писать на этой версии асемблера. Нет бля. Не научится. Но тут тебе надо нырять в архитектуру нейросетей, в их галюны и прочее, чтобы разобраться в теме. Я тебе тут пояснять, дауну, нихрена не намерен больше
да какая нахуя исповедь. это такая работа. у тебя же есть работа?
Вообще-то есть тенденция переписывания на Rust, даже Microsoft вкатилась в это дело
мир так не работает...
В фреймворках (настоящих фреймворках а не мелоксофтовых поделиях) суть в высокой связанности компонентов между собой. Написал кнопку, пробросил данные, настроил сеть - всё автоматически обновилось когда пришли новые данные. Всё это может быть сколь угодно низкоуровневым, можно даже байты отсылать напрямую в видеокарту.
Низкой компетентности инженеров и проёбом полимеров в образовании и порадили столь отсталые фреймворки и жирнющие прослойки. Слишком много всего нужно знать, чтобы всё собрать воедино.
Ну а нейрокалыч будет писать дичайшие высеры, кривые и несогласованные между собой куски кода, им контекста и окна внимания не хватает, 500~ строк почти предел окна в котором они могут достойно понимать хоть что-то, всё что дальше - нейрослоп.
Ядро только на pure c может писаться. Высокоуровневые конструкции c++ там не нужны, вставки безопасности от раста тоже, они хоть и незначительно но херят производительность, лучше вручную на си все дыры прикрыть
>> Высокоуровневые конструкции c++ там не нужны
Ну да, есть же void и макросы.
>> лучше вручную на си все дыры прикрыть
Открыть
Все уязвимости которые возникают вследствии компляции или просто известные уязвимости языка си закрываются либо специально усовершенноствнными безопасными функциями либо ручной правкой. Это оправдано когда речь идёт о ядре ос: крохотном компоненте на котором завязана вся производительность.
А то что там майкрософт раст впихивает, ну они много что впихивают, они и пытались ос свою на мобилки впихвать, и в игро рынок пытались. У дебилов в 2000 году была охуенная ос, с охуенными перспективами для захвата серверного рынка нужно было влошиться в написание годных серверных гуи программ с интуитивно опнятным интерефейсом + контракты с корпорациями по всему миру на внерение их серверной ос и всё было бы заебись.
А теперь мы дошли когда дебилы разрабатываю WSL пидорасят ради неё ядро впихивая драйвера-мокрописьки, то есть полнейшая капитуляция члинуксу даже уже не настаивают как раньше чтобы программу из пакетоублюдского формата перекомпилировали в нормальный .exe .dll эксосистему.
>вставки безопасности от раста тоже, они хоть и незначительно но херят производительность
можно пример?
Нет, не можно. Я в этом не разбираюсь, но эта инфа абсолютно верна что раст в целом чуть медленей pure c за счёт авоматизированных вставок. А теперь рякай ТЫ НИ РАЗБИРАЕШЬСЯ ТАК НЕ ПИЗДИ но те кто разобрались сделали тесты и дали выводы, я в интернете читал. Гуглить тебе ничего не буду ищи сам, всё лежит. Не согласен, так не еби мозги
просто странно, тк суть раста в статическом анализе. те эти проверки часть времени компиляции, однако вставки в рантайм есть, например, проверка границ и она кста оптимизируется, те если есть проверка границ явно, то доп проверки нет. ещё есть проверки переполнения, но они обычно вырубаются в релизном профиле. и самое главное, за счёт правил, которые выдвигает язык, компилятор может агрессивнее оптимизировать код, не нарушая корректность. те система типов это не только про проверку во время компиляции, но и про эффективность генерируемого кода
Бро, ты лучше меня шаришь в этом, я с тобой спорить не могу так как даже этот твой пост с трудом понял. Я скажу честно я опираюсь лишь на то что в своё время читал где-то сравнение pure c и rust и тот кто сравнивал пришёл к выводу что rust в некоторых моментах чуть медленней pure c будет.
>то доп проверки нет
Ты либо делаешь unsafe на с скростью си без проверки границ, либо делаешь safe медленную поеботу. Других вариантов нет, никак иначе это не работает. Пока есть нужда в грязных играх с указателями - раст не нужон.
Офк, это исключая инудсов на месте программистов которые указатели онлайн без смс проёбывают, но с этим и любые другие компиляторы справляются неплохо.
подразумевалось, что проверку всё же пишут, те для лупа например for i in 0..s.len() { f(s) } проверки в каждой итерации (кроме кондишена лупа) не будет. если же известно, что i не будет выходить за пределы и проверку не хочется, то да ансейф
Дело не только в циклах. Не забывай что с указателями можно делать какие угодно хаки уничтожая целые слои косвенности, вычитать, прибавлять, устраивать джампы. Сейф программы на срасте будут в несколько раз медленее из-за отсуствия этих хаков.
>Так вот теперь фреймворки нахуй не нужны, потому что есть нейросетки.
Гений, ты думаешь на примерах какого кода нейронки учатся?
>Гений, ты думаешь на примерах какого кода нейронки учатся
Они уже сами друг другу код скармливают. То есть одна нейронка учится у другой нейронки итд.
Конечно в них дозагружают новые знания, но самих новых знаний сейчас очень мало, почти нет.
>одна нейронка учится у другой нейронки
Ошибка множится, приехали, конечная.
Кутешка относительно современного вебговна ещё та низкоуровщина
Нейронки нужны не чтобы писать код или делать работу за тебя, а чтобы ускорять обучение уже опытного программиста, пынямаешь?
Я про это в оп посте писал, просить нейронку код писать, а использоваь её для более быстрого освоения низуокровневых фремворков.
оп треда