Comments 306
помянем?
Помянем. Наверняка к 2030 году появится ещё более инновационный и безопасный язык, который заменит Rust. Или, может быть, уже появился.
Почему не так?
2030 - 1972 [создание Си] = 58 лет.
2012 [создание Rust] + 58 = 2070 год - время перехода на убийцу раста.
Ещё добавить коэффициент, учитывающий замедление относительно разных муроподобных законов, и "ещё чего - нейронку на новый язык тренировать".
замедление? у вас рост по экспоненте буквально повсюду
замедление? у вас рост по экспоненте буквально повсюду
Не тот слайд, там цены на оперативку!
По-моему, вокруг нас хватает замедляющихся экспонент. В основном в железе, но ещё в ~2000 с лёгкой руки бросили, что
Proebsting's Law: Compiler Advances Double Computing Power Every 18 Years
А после проверки получилось, скорее, так:
Compiler Advances Double Computing Power Every 50 Years, And The Interval Keeps Growing
Скорее Microsoft выпустят слегка улучшенный несовместимый Rust и начнут перетягивать на свою реализацию.
Они с этого и начали: Project Verona язык inspired by Rust, Cyclone, Pony. Но как-то тяжело пошло у них, и сейчас откат на стадию "надо всё переписать".
Вот я прям вообще не расстроюсь, если это произойдёт под руководством Хейлсберга.
выпустят слегка улучшенный несовместимый Rust и начнут перетягивать на свою реализацию.
Скорее, XRust, от слова "хруст".
Пришло время для классики.
История программных революций от Microsoft, вкратце: Сначала были Windows API и DLL Hell. Революцией №1 было DDE – помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток – его писали не они!
Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием «по месту», при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз.
Но OLE не собиралась сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда – и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток – его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через броузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).
Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они таки представили концепцию «System File Protection», исключающую DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java - её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие.
Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно – недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили «COM» или «Active» или «X» или «+» – они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про «Windows DNA» (почему не DINA) и «Windows Washboard», и вопил некоторое время, но все это почило раньше, чем все поняли, что это было.
К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как «doughnut (пончик по-нашему)», но по-другому), похожей на Интернет, но с большим количеством пресс-релизов. Главное, что нужно очень четко понимать - .NET исключает DLL Hell.
В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.
это какие то галлюцинации
Был ассемблер. И тут мужик по имени Ричи нашёл в нём недостаток - его придумал не он...
Увы, потрачено. И вишенка на торте.
«Вырвиглазность» классического Win32-интерфейса в 2025 году обусловлена его технологической отсталостью от стандартов современных дисплеев: отсутствие встроенного сглаживания, примитивные системные шрифты и жесткая привязка к пикселям делают старые приложения либо невыносимо мелкими, либо «мыльными» при масштабировании. Визуально такие программы пугают нагромождением серых прямоугольных форм, плоскими кнопками без анимаций и хаотичными каскадами вложенных меню, которые совершенно не адаптированы под сенсорный ввод или эстетику прозрачности и закруглений актуальных ОС. В итоге работа в таких интерфейсах превращается в испытание для глаз из-за визуального шума и отсутствия логичной иерархии, характерной для современного дизайна.
примитивные системные шрифты
Обоснуйте.
Вектор 20 лет назад от вектора сейчас принципиально не отличается ничем.
жесткая привязка к пикселям делают старые приложения либо невыносимо мелкими, либо «мыльными» при масштабировании.
Чушь и компот.
Мыльным или мелким делает либо рукожопость либо сознательный саботаж. Если ни того, ни другого не наблюдается, то каждый пиксель оригинала заменяется квадратом 2x2 или больше идентичного цвета и никакого мыла и в помине нет. А сглаженных линий вам ни кто и не обещал, приложения-то старые.
без анимаций
Отсутствие анимаций это плюс.
сенсорный ввод
На десктопе на хрен не нужен.
не адаптированы под ... эстетику прозрачности и закруглений актуальных ОС
Ещё один неоспоримый плюс.
Дизайнерам, рожающим скругления, анимации и полупрозрачность место на урановых рудниках.
Вектор 20 лет назад от вектора сейчас принципиально не отличается ничем.
Системные шрифты и системные приложения 20 лет назад поддерживали лигатуры?
Мыльным или мелким делает либо рукожопость либо сознательный саботаж.
У меня есть игровая машина с виндой, и там в некоторых приложениях диалог открытия файлов, подозрительно похожий на системный, мылится. Чья именно это рукожопость?
Отсутствие анимаций это плюс.
Анимации по делу помогают.
Я себе в читалке на планшете включил анимацию перелистывания, и теперь если я ошибаюсь с кнопкой перелистывания, то это видно сразу, а не спустя пару секунд чтения «так, пажжите, что-то фраза резко оборвалась, и вообще я это уже читал».
Анимация сворачивания окна в таскбар тоже помогает мозгу отслеживать, что именно куда именно свернулось.
На десктопе на хрен не нужен.
А на ноуте — нужен. У меня есть ноут с сенсорным экраном, и сенсорный ввод там — это удобно.
Правда, там линукс, но это другой вопрос.
Ещё один неоспоримый плюс.
Субъективщина. Лично мне нравился визуальный стиль шиндошс 7.
Все верно, только забыли добавить, что с такой "логикой" и колесу в автомобиле comerc'а уже давненько "пора на покой", не как ему бедному аж 2.5 тыс.лет.
Мыльным или мелким делает либо рукожопость либо сознательный саботаж.
Как-то на тему "мыльности" интерфейсов жёстко зацепились на RSDN. Разумеется, консенсуса в дискуссии не нашлось, но всплыло интересное наблюдение: что отношение к разным стилям рендеринга, сглаживания, подходам к спейсингу и лигатурам сильно зависит от персонального зрения, и в первую очередь от наличия/отсутствия близорукости. Близорукий значительно меньше реагирует на "мыльность", но больше -- на другие факторы. Как по мне (≈-4 и обычные очки на слегка неполную корректировку), наблюдение подтверждается.
Цитата:
Тут есть такое соображение: те, кто видят хорошо, в основном предпочитают более контрастный рендеринг шрифтов. Потому, что "грязь" или "размазанность" вызывает у них ощущение, что картинка не в фокусе — и глаза, постоянно пытаясь подстроиться, устают.
Те, у кого зрение и так блюрит картинку, больше обращают внимания на равномерность оптической плотности — им всё равно, отрисована ли линия шириной в один пиксел чёрного цвета или в два пиксела серого цвета.
Не то чтобы 100%, но имеет смысл как отправная точка для дальнейшего исследования.
Тем не менее в Accessibility настройках винды до сих пор нет соответствующей регулировки, в отличие от массы других настроек типа ярких траекторий мыши.
Говорите ли Вы о классическом Win32-интерфейсе как о классической теме (которую можно включить в Windows 7, например) или о интерфейсе через Win32 API вообще?
Как по мне, многие современные интерфейсы сглаживают шрифты сильно хуже чем ClearType, работающий еще с Windows XP. На высоких DPI не очень заметно, а на стандартных 96 DPI разница очень видна. В том же Windows XP появились и поддержка разных DPI, и красивые скругленные кнопочки и прочие свистелки/мигалки, нужно лишь чтобы приложение указало поддержку всего этого в манифесте. А начиная с Windows 10 поддерживаются и темные темы (хоть и через полускрытый API). Правда настройки системных цветов для классических тем работали еще с Win 95 и были утрачены с Win 8.
Тот же модный современный Qt получил нормальную поддержку DPI на Windows только в версии 6. Qt 5 мог менять DPI только кратно, полому про масштабе 150% приложения Qt 5 были на 200% больше.
Про визуальный шум и логическую иерархию непонятно. Не больше ли шума и хаоса когда каждое приложение имеет свой совершенно уникальный интерфейс? Если уникальный дизайн и лучше, то во времена XP популярны были скины приложений (особенно плееров), вполне через Win32 работало, с анимациями и пр.
Не проблема и сенсор. У самого уже больше 10 лет ноут с сенсорным экраном. Можно делать крупные элементы, большие зазоры в меню и т.п., но часто это неудобно. Если у тебя мышь, то элементы управления на пол экрана раздражают и крадут место у рабочего пространства. Крупных элементов влезет меньше. Неудобно работать в каком-нибудь Excel или VS Code на сенсорном экране.
Кастомный рендер точно нужен приложениям где нужно 120 FPS на 4K, но придется платить системными ресурсами, которые многие программисты посчитали неисчерпаемым ресурсом.
Речь вообще не идёт о графических интерфейсах
идёт еще как и она устаревает тоже, винда апала продукт пропуская сквозь время самое сердце, нтфс, и планировщик который смотрит в системную отрисовку
резюме теперь винда на пороге того момента, когда можно просто спросить у безесды как бы они делали интерфейс. В обливионе и в морровинде был имбовый интерфейс, ну почему не позвать этих людей, и просто не спросить как они видят интерфейс просто спросить, тоже самое и у Кармака можно спросить, туда же виндовс создала аналог зфс, но оставила старые алгоритмы, телеметрии и планировщика, и гди всё там же, так что тут дофига изменять если по честному
Проблема не в Win32 как таковом, а в том что Microsoft каждые 5 лет продвигает новый UI-стек, потом забрасывает. Разработчики устали и сидят на чём работает
.NET включает виртуальную машину
Это надо перенести в начало этой простыни, чтобы те, кто хоть немного в теме, не тратили время и дальше её не читали. А, ну и еще, конечно, "шедевр" про MFC и ATL. Автор просто реальный эксперт.
А что не так с виртуальной машиной и atl с mfc?
Я уже как-то рассказывал: в то время как сантехники тупо назвали свою виртуальную машину Java Virtual Machine, хитрые маркетологи из Микрософта назвали свою Common Language Runtime. Потому что Virtual Machine быстрой быть не может, а крутон Language Runtime — может. Соответственно, я поверил, и долго ходил и всем доказывал, что CLR не VM. (Для тогдашнего моего юного возраста простительно). А потом на одной конфе я увидел выступление майкрософтовского архитектора, который сказал что-то вроде: «…наша виртуальная машина…», и его поправили: «Так CLR же не виртуальная машина?», а он засмеялся: типа, вот уж не думал, что кто-то реально поведётся на эту мульку с «лэнгвич рантаймом». Ни один обоссанный фанат рок-группы не чувствовал себя таким преданным, как я в этот момент.
Видимо, автор предыдущего комментария просто не видел эту конференцию и это выступление.
Что касается MFC, тут, возможно, критика и уместна. MFC никто не понимал. Я вообще ни разу в жизни не видел, чтобы её использовали по назначению! То есть, для написания MVC-редакторов, с документами (CDocument) и представлениями (CView). Она как тот писсуар из поговорки, в который никто отродясь не попадал. Я иногда думаю, каково себя чувствовать разработчиком MFC или jQuery. Вроде, и продукт востребованный, но смотреть одно расстройство.
он засмеялся наверно потомучто пока не придуман иной способ интерпретации, высокоуровнего асма что и есть виртуалка, на регистрах она или на стеке не суть, суть в том что её и рантаймом можно назвать потомучто прыжки по коду того асма не сразу известны, отсюда и багаж языкового рантайма, но сути это не меняет всё теже команды
Фатальный недостаток = "Его писали не они"
?)
помню эти времена, первая заплата, почти во всем объеме, была потрачена на ATL как нечто очень перспективное, чем COM
Или, может быть, уже появился
Google продвигала Carbon lang как плавную замену C++, но вроде уже сдулся.
Проблема в этой идее не в расте. А в "и писать миллионы строк кода нейросеткой". А дальше хоть какой язык в эту схему подсунь - можно сразу заказывать отпевание.
Наверняка к 2030 году появится ещё более инновационный и безопасный язык, который заменит Rust.
В 2030 году ИИ будет визуализировать код в форме трехмерной блок-схемы. Архитектор программы будет вращать блок-схему, и объяснять ИИ, что должен делать тот или иной блок. ИИ будет отвечать - "Ваши ожидания это ваши проблемы. Но этот блок работает совсем не так." После короткой перепалки, они вместе полезут внутрь блока, и будут смотреть как он работает. Заодно узнают на каком языке он написан.
В 2030 году ИИ будет визуализировать код в форме трехмерной блок-схемы.
Это в фильмах. На практике человечество привязано к языку, а не к образам. Образы легче на первых порах, когда их мало - а затем только язык. Когда транзисторов было мало - можно был схему процессора нарисовать, изучать. Потом только Verilog. Визуальное программирование и диаграммы уже сколько раз пытались притянуть - и оно удобно пока кода мало или для пояснения конкретной концепции.
Образы легче на первых порах, когда их мало - а затем только язык
Не образы, а обычные программные модули, представленные в виде трехмерной блок-схемы. Трехмерная, потому что структура программы разветвленная. Сам код никуда не денется. Но навигация по коду и понимание работы программы значительно упростится.
Визуальное программирование и диаграммы уже сколько раз пытались притянуть - и оно удобно пока кода мало или для пояснения конкретной концепции.
Это потому что у программистов (велосипеда) ИИ не было. А теперь он есть, и сможет программу представить в каком угодно виде, и визуализировать потоки данных. То есть пока не может, но сможет к 2030 году*. Примерно. Если ИИ-пузырь не лопнет.
Это все не работает. Во всех сферах люди пришли к описанию всего текстом. Ничто другое не позволяет описывать сложные системы так чтобы человек мог их понять и осмыслить.
Вайбкодерам тоже придется учиться программировать и читать исходники. Или оставаться на уровне простенького типового сайта и конкурировать с конструкторами.
Почему же. Вот например nodered для реализации алгоритмов управления устройствами умного дома, вполне себе класная штука.
Управление пятью лампочками точно сложнее типового простого сайта?
Мы тут про сложные системы все-таки.
вполне себе класная штука
А что там классного? Те же самые слова, просто их обрамили в квадратики. Когда пишешь на ЯП - то же самое, просто без стрелочек и квадратиков - эти стрелочки и квадратики ты как бы сам видишь, а часто и визуально в коде {} - это квадрат а () - это стрелочка. Т.е. просто другая форма записи.
Текст удобнее, понятнее и универсальнее, безусловно, но хватает тех, кто до сих пор тащит всякое визуальное программирование. И, самое интересное, у них вопреки этому получается хороший продукт. Например, AIMP. Я бы предпочёл, чтобы он был сделан вокруг текстовой разметки, а не был копией Delphi, но приходится кушать что дают. Потому что есть ещё богатство функционала, качество исполнения, грамотная поддержка, стабильное развитие, число юзеров и так далее.
АIMP - это же вроде бы музыкальный плеер. При чём тут копия Delphi? 🧐
Попробуйте поменять местами пару кнопок в аимповском скине, и поймёте. В каком-нибудь WMP я открывал блокнот и делал это не задумываясь за пять минут. А тут надо скачать дельфоподобный редактор и заниматься визуальным программированием. Какие-то стрелочки с байндингами рисовать, и прочую муть. Но, ещё раз, лучше AIMP'а по совокупности критериев я ничего не видел.
Как я много раз убеждался, программисты что видят перед собой, то и воспроизводят. Видят перед собой Delphi — пишут свой Delphi. Видят VS Code — пишут VS Code. Видят Студию — пишут Студию. И сейчас, к сожалению, хороших примеров для подражания просто нет.
Из того, что есть — DevTools, наверно, самое лучшее. Знаете, как поменять шрифт в лисичкином DevTools'е? Открываете глобальный мультипроцессный DevTools! Находите через инспектор условие выборки нужного вам субредактора, привязываете к нему свои определения шрифта, и готово. Ах да, ещё надо разрешить такие переопределения. Учились бы все программисты писать UI в DevTools, и делали бы такие же универсальные решения — и в этом мире можно было бы жить. Но сам FF ведь не в DevTools'е пишут.
Трехмерная?
У меня уже N-мерные структуры и алгоритмы соответственно, я тону даже в их проекциях на трехмерный мир и я понимаю что я давно хожу по доступной мне грани предела моего воображения, физический предел, что никакого качественного скачка мой мозг уже не совершит и что вот это вот ограничение трехмерного воображения это куда как более перспективный вектор атаки на целесообразность моего существования, а не скорость генерации кода.
Тормозит этот процесс моего вымещения ИИшечкой только то, что очень редкому заказчику доступна такая же гибкость н-мерного мышления и что выстроенные ими процессы, которые я автоматизирую, сыпятся на более низких уровнях.
А так если вы еще видите трехмерность как решение всех проблем - то вы уже неактуальны. N-мерность сразу, из коробки.
N-мерность сразу, из коробки.
Как N-мерная визуализация должна выглядеть на экране? Трехмерная визуализация дает оптимальную плотность информации на экране. Довольно удобно крутить на экране 3D-модель, и быстро масштабировать, начиная от общей блок-схемы, и вплоть до кода на ассемблере, если понадобится.
Так же как трехмерная - проекцией на двухмерную плоскость экрана)
Только это нас с Вами не спасет, мы ограничены в сложностях анализируемых структур не экраном и голограммами, а мозгом, обученным на 3х-мерном мире. Мы так же не можем эффективно управлять непосредственно больше чем M-человек, много какой деятельности у нас резко теряет свою эффективность при превышении какой то цифры меньшей или равной 5ти. Наш мозг как инструмент все же для другого.
//Гипотеза такая - мозг, допустим, каким то образом можно выучить на 3+N пространство (где N - больше нуля), но потеряв при этом его функции в базовом ориентировании житейском в пространстве. Все таки мы в процессе мышления опираемся на блоки мозга, развитые до условных 7 лет, которые выстраиваются во взаимодействии с "реальным миром, данным нам в ощущениях". Но это только моя гипотеза.
А ИИшечка, гипотетическая, не экспоненциально ресурсо-зависимая от операционной размерности, могла бы быть или лишена этого ограничения или иметь его много выше этих 5ти. И мы ее просто-напростаки не будем в состоянии понять в какое то ограниченное время.
Трехмерная, потому что структура программы разветвленная
Для человека это не удобно для восприятия. Возможно для гуманоидов с другим мозгом, превосходящим наш на порядки - да, удобнее трехмерное. А у нас карты двухмерные.
Далее - если вы каждое слово программного кода обрамите в квадратик и добавите стрелочку - удобство восприятия не сильно повысится. Возможно что с непривычки, кто не работал с кодом - будет удобнее - а сейчас и так {} выделяется отступами и воспринимается как блок - только компактнее когда меньше визуального мусора.
у нас "трехмерная картина" это прежде всего наложение двух двумерных проекций под небольшим углом на сетчатке глаз + ближайший тактильный круг обусловленный нервными окончаниями мышц и кожи - довольно сложный концепт на самом-то деле, плохо работающий с внутренними полостями и внешними, исключенными из направления взгляда структурами. Если Вы попытаетесь представить трехмерную вещь не как объект в руках перед взглядом, а "в общем", "вокруг" Вас, почувствуете как падает эффективность наблюдения за ним, как его детали начнут исчезать из пятна внимания вникуда.
(Представьте себе в руках чайник с 3х-мерным лабиринтом внутри вместо полости. В попытке держать во внимании этот лабиринт Вы неизбежно будете терять в восприятии его остальных частей. И это мы так теряем еще на этапе восприятия, до мыслительной деятельности мы еще не дошли)
"двумерная картина" - много-много проще, она задействует минимум аппарата мозга, оставляя основной его ресурс на связанные абстракции. Мы можем читать текст и генерить воображением связанный с текстом мир.
Так это же будет Xrust !
“1 инженер, 1 месяц, 1 миллион строк кода”
А этот инженер точно кожаный? Миллион строк за месяц это будет нормальное такое собрание сочинений...
Наша путеводная звезда — «1 инженер, 1 месяц, 1 миллион строк кода»
А можно чтобы блокнот без тормозов ресайзился? на 16-ядером CPU с 5 ГГц
Нельзя, скоро весь код блокнота перед запуском будет генерироваться нейронкой. Поэтому в минимальных системных требованиях Windows 2030 будет квантовый сопроцессор на 100 кубитов.
Точно. Вместо раста будет промт язык для ИИ, описывающий алгоритм и ии будет налёту при каждом запуске приложуху генерить
Зачем мелочиться, включаешь комп а операционную систему генерит нейронка и все приложения по мере надобности...
"мы вам уже и магазин к блокноту прикрутили, и облачное хранилище, и ИИ-чат добавили - чего вам ещё не хватает?" ©
Нет. Алгоритм такой, что чтобы понять на какой он позиции ему приходится пересчитать длину всех строк выше открытой строки - нужен ли перенос и т.п.
Очень мало кто может сделать быстрый блокнот для больших файлов под миллион строк.
Не тормозит разве что notepad++, других не знаю
Не тормозит разве что notepad++
Смотрите-ка, смогли. А корпорация со всеми деньгами и программистами мира не смогла.
Если точнее, не тормозит Scintilla, на которой основан в т.ч. и Notepad++.
Реально крутая штука. Как-то делал монитор последовательного порта для дебага одной железки, которая с определённой периодичностью выплёвывает серию значений. И вот когда эти значения стали отправляться несколько сот раз в секунду, я столкнулся, что отрисовать это без зависания могут не только лишь все. Пришлось городить свою утилитку.
А зачем отрисовывать то что невозможно рассмотреть? 100 значений в секунду глаз не различит все равно
Зачем сразу с козырей заходить, пусть сначала поупражняются в ускорении отрисовки!
Ну, ок. А то любой монитор последовательного порта умеет 115200 и быстрее, не видел проблем с отрисовкой.
Одно дело установить коннект на 115200, по которому приходит десяток байт в секунду. Другое дел, когда реально начнут приходить данные в объёме 100 кбит/с, тогда и увидите, как тот же putty просто виснет наглухо.
Всегда думал, что прием байтов и отрисовка крутятся в разных потоках. Значит, либо авторы дурнее меня, или не умеют в синхронизацию.
А при чём здесь эти потоки вообще? У вас есть некий источник, который может выплюнуть вам в порт сотню килобит инфы в секунду. У вас есть клиент на этом порту. И здесь есть два варианта:
1. Как-то даунсэмплить данные и выводить только часть, поскольку человек всё равно ни сто, ни даже один килобит в секунду не прочтёт. Такой функции, как я уже написал, не нашлось в опробованных мной клиентах. Нужно писать свой велосипед.
2. Таки вывести эти данные тем или иным способом. Например батчами, чтоб избежать частого обновления контрола. В случае, к примеру, стандартного TextBox из дотнета, в любом случае это дикие тормоза. Нужен такой контрол, который может корректно работать с такими объёмами данных, и лучший из виденных мной вариантов - это Scintilla.
В 2000 году, когда в ходу были Delphi , можно было научить любой контрол перерисовываться по своим правилам. Не пытаться рисовать то что не помещается в видимую область. Не перерисовывать весь контрол, если пришел 1 байт.
Секрет утерян походу.
Putty опенсорсный вроде (да и .NET тоже, не уверен, впрочем, насчёт WinForms), так что вы можете найти своим знаниям куда более достойное применение, чем пассивно-арессивно язвить собеседникам, как думаете?
авторы дурнее меня
Все тупые, один вы – светоч знаний, ага?
У меня слушанием порта занимается костыль из cu и xterm. Он же и логи пишет, всегда можно открыть vim и неспешно почитать. Не помню чтобы оно тормозило.
Не найдётся. Это как Casey Muratori против виндовс-терминала.
Когда он завёл issue на гитхабе https://github.com/microsoft/terminal/issues/10362 о том что производителньость рендеринга падает до жалких 2 фпс, в обсуждении разработчики микрософта начали объяснять почему всё так медленно, а в итоге заявили что быстрый рендеринг терминала это задача уровня "doctoral research project" Попытки Кейси возразить, что игровые движки уже десятилетия как вполне способны справится с рендерингом 60+фпс при отрисовке сложнейших 3D-сцен и ещё кучу другого успевать просчитывать, это несравнимо сложнее чем вывести буквы на экран - были проигнорированы. Разработчики закрыли его Issue.
После этого кейси записал видео https://www.youtube.com/watch?v=hxM8QmyZXtg "How fast should an unoptimized terminal run?" и выпустил свою референсную реализацию RefTerm, которая поддерживала скроллинг, Unicode, RTL языки, многоцветные шрифты - и работала на нескольких тысячах FPS.
Спустя год Microsoft выпустила блог-пост где назвала эти же самые оптимизации "тривиальными", упомянув кейси лишь как "community member" без указания имени.
Ну то есть у Кейси получилось только потому что он сам по себе довольно известный чувак, крутой разработчик и тех-инфлюенсер к тому же. У рядового разраба тут нет шансов
Да я-то знаю, но за интересную историю всё равно спасибо.
Просто забавно как у комментаторов всё просто решается, всего-то надо Delphi и пару потоков, и тут же UI начинает летать.
только следующей точкой будет превращение в дерево
было gap буффер, будет rope буффер, но есть и далее
то что Кейси не проверил, еще следующий пойнт заключается в том, что мы отталкиваемся от мышки пользователя, и это уже бвх квадратиков
тоесть ограничивающий обьем 2д и ограничивающий обьем 3д, где пространство или 3д-2д или только 2д и мышка в том же пространстве кстати
тоесть было gap, на первой итерации должен быть rope, но как только нужна интерактивность нужен мгновенный доступ и это бвх, бвх в вопросе интерактивности будет своеобразной ультой уже, импакт при использовании бвх просто молниеносный, нам надо знать где глиф на уровне физики к сожалению
туда же добавляем структуру или аналог(чтобы не тупо копировать) zfs, структура zfs из мира bvh тоже, только она метит совсем другое, в вики можно поискать какая там структура и за счет чего достигается скорость, так что терминал это не фс, значит эта структура не подойдёт, а значит подойдёт только бвх
мы с вами копнули гораздо глубже в контексте текста терминала и архитектурных решений виндовса на текущий момент к сожалению потомучто реализация аналога зфс взлетит только на планировщике на принципе реалтайм без тех диких калбеков (процесс main)
в текущих условиях нужны гарантии кванта времени, и эти кванты нужны будут как для интерфейса, так и для аналога зфс, так и для обработки других частей или механизмов, как-то так в целом
А развести потоки никак? Это ж классика: клиент принимает данные и складывает их в буфер, а паралллельный поток этот буфер читает и что-то с прочитанным делает.
Я в курсе про downsampling, децимацию и агрегацию, спасибо. Речь шла вообще не об этом, но если вы подскажете готовую утиитку - монитор последовательного порта, в которой эти фичи есть, буду благодарен.
Я не знаю готовых утилит, в которых можно настраивать этот параметр. Все выводят на экран всё, что пришло в порт. Если приходит много и быстро - начинает лагать.
Очень много лет использую teraterm 2.3 выпуска 1998 года от T.Teranishi.
Работает на всех вариантах виндов, какие мне попадались. Есть поддержка русских кодировок 866, 1251, КОИ8. UTF8 нет.
Потерь данных не замечено за многие годы, объем данных - сотни мегабайт.
Доступен в исходниках. Есть более новые версии, но мне они не зашли.
Секрет прост - он работает в текстовом окне, не графическом.
Секрет прост - он работает в текстовом окне, не графическом.
Чушь. Текстовое окно, в котором он работает, тоже кто-то должен отрисовать. И стандартный conhost в винде рисовать быстро не умеет.
Так что секрет явно в чём-то другом.
Не поленился, набросал тестовую программку на сях. Консольное приложение, выводит 10 000 строк по 62 символа + перевод строки. Время выполнения 7 секунд. Скорость 90 000 символов в секунду. Получается на порядок быстрее стандартного последовательного порта.
UPD: Такой результат получился при использовании putchar. После его замены на printf, выводящий строку целиком, время выполнения упало с 7 секунд до 0.2 секунды, соответственно скорость около 3 мегабайт в секунду.
Вывод: используйте буферизацию для минимизации накладных расходов.
других не знаю
Sublime Text же!
Он даже на пустом документе тормозит. А ещё когда ПКМ щелкаю по рабочему столу, меню открывается только через полсекунды.
пересчитать длину всех строк выше открытой строки - нужен ли перенос и т.п.
Очень мало кто может сделать быстрый блокнот для больших файлов под миллион строк.
Эм. А зачем все строки то? Отресайзились — берем текст, который виден на экране и перебираем‑пересчитываем текст вверх и вниз до тех пор, пока не вылезем за пределы экрана. Только те куски, которые в поле зрения. Если пользователь начинает мотать куда‑то — досчитываем относительно того, что уже отобразили. Если мотает далеко — то считаем примерную позицию и снова считаем только то, что на экране. Я просто рассуждаю.
Sublime text вполне резво работает
Total Commander - Lister, спокойно открыл текстовый файл на 35 GB и поресайзил с нулевой задержкой.
Vim и Neovim без проблем отображают и редактируют даже многогигабайтные файлы.
пересчитать длину всех строк выше открытой строки - нужен ли перенос и т.п.
В абзаце же, а не во всём документе. Вряд ли ведь у кого документ на миллион строк, и все одним абзацем...
Нет. Алгоритм такой, что чтобы понять на какой он позиции ему приходится пересчитать длину всех строк выше открытой строки - нужен ли перенос и т.п
Во времена 16-разрядных процессоров была известная проблема: в одном сегменте памяти помещалось 64 килобайта. И если файл больше - его делили на сегменты и загружали по частям.
Если я правильно помню - Блокнот в Винде тогда не умел открывать файлы больше 64кбайт.
А сторонние приложения почему-то умели, тот же Нортон Командер.
Видимо, это фирменная фишка у них...
очень мало кто может сделать быстрый блокнот
по моему мнению логика тут весьма тривиальная. винды это про массового пользователя и домохозяек, им не нужно открывать логи длиной в гигабайты. сделать можно, но заработать на этом на массовом пользователе нельзя.. а значит специализированный инструмент напишет кто-то другой
А можно чтобы блокнот без тормозов ресайзился? на 16-ядером CPU с 5 ГГц
Можно. А зачем?
10 слоёв древнего UI под новомодным фреймворком сами себя не загрузят
Такое на простом C надо писать, а тут Rust, с корпоративными переподвыподвертами.
Как на rust перепишут, так можно будет. Но это не точно.
Как говорил классик: "Можно, а зачем?"
del
Ещё одна хорошая причина чтобы полностью перейти на Linux.
Решения Microsoft в последнее время вообще не радуют. Пихают этот ИИ везде где только можно и нельзя, лучше бы на производительность Windows 11 обратили внимание и дали возможность юзерам самим определять нужен им этот "ИИ-помощник" или нет.
Но, конечно, оправдать огромные инвестиции куда важнее мнения пользователей, безопасности ОС и её производительности...
Linux тоже активно переводят на Rust.
Вроде как просто отдельные драйвера, ну да, драйвера там это модули ядра, но чтобы прям совсем ядро переписывали - такого не слышал. И systemd написан на сишечке.
Дело не в факте перевода на какой-либо язык. Дело в самом подходе. Rust только недавно в Linux вышел из экспериментального режима, а здесь они хотят миллион строк кода в месяц переводить на Rust через некие "автоматизированные механизмы".
То, что происходит с Rust в Linux - это скорее дополнение, чем полная замена или переписывание на "безопасный по памяти язык" ядра.
"И, Боже вас упаси, не читайте перед обедом советских газет..." Мало ли кто там что обещал к 2030 году. Обещать - не значит жениться.
Ну так и в венде rust в ядре появился еще в 23 году)
https://habr.com/ru/companies/selectel/articles/719174/
Не в расте ж дело. Если Шизософт уперся рогом в генерацию 1кк строчек к месяц - уж будьте уверены, так все и будет. Как минимум в маректинговых и пиаровских целях. В линукс-сообществе такой шизы нет, насколько я знаю.
А в чём пиар? Кажется, каждая последующая винда уступала в производительности в каких-то задачах предыдущей. Не удивлюсь если до сих пор найдутся задачи в которых ХР окажется быстрее или удобнее 11. Пиар будет, если производительность везде станет на 15% быстрее предыдущей, а сколько там строчек на каком языке примерно всем наплевать.
За счет чего операционка должна ускоряться от версии к версии?
За счёт алгоритмических нау хау, решения техдолга. Какие-то фичи могли прототипироваться на скорую руку инородным микросервисом на питоне или типа того. Откуда-то берётся же разница в производительности и она не всегда в минус. Я не работал на мелкомягких и подробностей не знаю. Но как пользователь понимаю что для меня хорошим пиаром было бы улучшение моего взаимодействия, например, через поднятие производительности.
Операционная система - это вообще история про монопольный контроль ресурсов, разного рода изоляции, абастракции и прочие рантаймовые проверки. Эти вещи почти всегда оплачиваются производительностью, в сравнении с программированием на голом железе.
Тем не менее, некоторые измерения показывают увеличение производительности 11 над 10 https://youtu.be/K2C2RgAW5Tw?si=o3lFrluobyIsDiS8 Что, кстати, удивительно, так как в интернетах у неё репутация замедленной из-за шпионских программ)) Видимо, что-то оптимизировали.
То, что абстракции и их взаимодействия жрут больше всего ещё не означает что внутри негде оптимизировать.
Очень мало переводят линь на раст и только новый код. И это верно: старый код уже проверен.
А тут полностью выкинуть старый код
Очень мало переводят линь на раст и только новый код.
Ну ок, не к 2030-му, так к 2035-му переедет. Это же вопрос только времени, раз процесс уже запущен.
С другой стороны, ну раст и раст, проблема-то в чём?
https://www.opennet.ru/opennews/art.shtml?num=64114
Убунта уже отличилась заменой coreutils на это поделие. Результат ожидаем
Ага, и каноникал постоянно получает ссаными тряпками по морде когда очередную системную тулзу заменяют аналогом на раст и оказывается что там функция получения даты-времени застабблена и возвращает одно и то же тестовое значение из-за чего какой-нибудь apt отваливается и уже не поднимается.
Только руками, а не нейронкой.
В Винде оставить один WSL. Профит.
Микрософт: давайте сделаем винду более безопасной.
Линуксоиды: ещё одна причина перейти на линух!
Вопрос то не в намерениях, а в методах
А что не так? Если код ревьювит хороший специалист, то не вижу проблемы.
лям строк за месяц это по 50 000 строк в рабочий день, если я правильно сосчитал.
Т.е. на выходе мы будем иметь полный рефакторинг кодовой базы, сделанный и принятый двумя хорошими ИИ специалистами в одном лице. Где объем работы и сроки не позволяют в принципе иметь никаких других кнопок кроме "верю, делай".
Я ж не против таких экспериментов по сути, я против таких экспериментов надо мной.
Но, если все будет так, как заявляют и будет удачно, после такого наверное надо будет обновить резюме, где указать что я еще и на велосипеде по городу не плохо катаю и на самокате могу...
Почти правильно, 32 тысячи в день при самом длинном месяце, 35 при самом коротком. Но в любом случае, очевидно, ревьюить это никто не будет и не сможет. Остаётся надеяться только на наличие хоть сколько-нибудь вменяемых автоматических тестов. Хотя, если и их сгенерировали...
С какого-то момента доходы от биржевых спекуляций начинают настолько существенно перекрывать реальные доходы от деятельности, что заниматься собственно реальной деятельностью становится третьестепенной задачей. Важнее хайп, словесные интервенции и рост капитализации.
Озвучен срок очередного "вендекапеца"?
Microsoft Visual C++ — тоже амба будет?
Ржавчиной покроется :)
Его место займёт Visual Rust++, ЕВПОЧЯ.
Ждем с и с++ разрабов в гости. Дроны, ракеты, девайсы, связь... очень ждём.
Со времён "мифического человека-месяца" известно, что толковый разраб может выдавать в среднем 50-100 отлаженных строк кода в день, независимо от языка программирования. Умножить на 20-22 рабочих дня это пару тысяч строк кода в месяц, но никак не миллион.
Несколько лет назад МС посокращало тестировщиков, переложив эту почётную обязанность на юзеров.
Теперь они хотят вываливать на этих юзеров по миллиону строк нагенеренного ИИ кода без проверки человеком.
Вот даже интересно, что же может пойти не так?)
Придётся выкинуть 90% кода в windows 12. Поддерживаю
Ну всё же "писать на Rust" и "переписывать с C на Rust" - это разные вещи. Как "сочинять" и "переводить". Хороший переводчик не обязательно должен быть хорошим сочинителем.
Не боги горшки обжигают. Покрываем код железобетонными юнит-тестами. И переписываем на раз-два.
Yandex CodeRun Winter Challenge - я в топе на Rust-е, хотя его почти не знаю.
Со времён "мифического человека-месяца" известно, что толковый разраб может выдавать в среднем 50-100 отлаженных строк кода в день, независимо от языка программирования
Если это не ассемблер, как было в случае Excel vs Lotus 1-2-3.
Excel переписали на C, получили и скорость, и продуктивность разработки — классический пример из Спольски.
Но тезис Брукса про 50-100 строк — про зрелые проекты с тестами, код-ревью, интеграцией. На хакатоне или прототипе можно и 1000, только это другое.
Да и от предметной области зависит сильно.
Помнится уже 2012 винду обещали без Win32 API (только .NET Framework). И?
Так была же RT. Как раз примерно в те годы. Попробовали, увидели, что не заходит, отказались - нормальный подход.
.NET Framework
Закончился этот "ускоритель кодирования" очень плохо. Программы на нём нельзя перевести на что-то более новое, только выкинуть: контракты одновременно на все слои это сейчас антипатерн, а тогда было "не надо думать, он всё за нас решит"©
Так же и другие ускорители плохо заканчивали
Ну тогда они забьют крышку в гроб не только мобильной, но и десктопной Винды. Важные, но некритичным компоненты UI глючат уже сейчас. Что же будет, когда M$ перепишет код ключевых компонентов ядра на Rust, но с помощью ИИ?
На последней версии 25h2 уже глючит кривое меню Пуск, ещё и сломали механизм ExplorerPatcher, теперь не работает нормальный пуск из 10ки, а дефолтный из 11ки ну очень не удобный...
глючит кривое меню Пуск
Так оно на жабаскрипте
Притом на реакте вроде. Ещё более костыльно.
Серьёзно? Почему не на C# MAUI, интересно?
О, снова вижу про жс в пуске. Можете подкинуть инфы, где там жс?
где там жс?
Наверное там же, где и "виртуальная машина" в .NET, про которую выше эксперты писали :-D
Можно начать погружение здесь https://habr.com/ru/news/913050/
И там же закончить. Нет ни одного хоть какого-то доказательства, что там реакт(нейтив), кроме каких-то картинок из твиттера о загрузке ЦПу. Загрузка ЦПУ = реакт?
UPD: там же есть ссылка на https://devblogs.microsoft.com/react-native/rnw-settings-win11/ - в котором пишут об одной конкретной странице настроек, которая использует React Native for Windows для отображения информации о подписках и чем-то там ещё. Не пуск, а конкретная страница настроек.
Продолжить плаванье здесь https://youtu.be/kMJNEFHj8b8?t=290
Секция рекомендаций на реакте как минимум (на 2023 год). Остальное - солянка из крестов, шарпа и xaml.
Окей, покопался и это звучит очень странно, но местами интересно.
Сам React Native использует hermes - движок выполнения JS. Его же судя по документации МС использует и версия for Windows. Насколько я понимаю, это встраиваемый движок, т.е. он не работает как электрон\вебвью с запуском пятка процессов и прочей мишурой (но вопрос производительности против V8 хромовского всё равно под вопросом).
Звучит как очень большой оверхед для "пуска", но включив рекомендации и потыкав в меню в разных вариациях, больше всего нагрузки я увидел в dwm (т.е. рисование окошка, прозрачности и композиции окошек), а не в чём то ещё.
Не смог гарантированно понять используется ли js в пуске, поэтому если он используется, то у меня лично никаких проблем это не вызвало. С одной стороны, если хорошо работает, то почему бы и нет. С другой - всё равно звучит странно, затащить js движок туда где точно можно обойтись без него (и это те же люди, которые секунды не хотят отображать на панели для экономии электроэнергии).
" сломали механизм ExplorerPatcher " как будто были обязаны поддерживать?
Это их приложение, их пуск и их поддержка пуска. А патчер - неофициальный, для тех кто готов к приключениям. И его вылеты\поломки на совести пользователей, но уж точно не МС.
1 инженер, 1 месяц, 1 миллион строк кода
Я так понимаю, что promt будет выглядеть как-то так:
1) Выполнить перевод на Rust этой библиотеки
2) Добавить 1 миллион строк и некоторые случайные задержки а также случайные алгоритмические секции, занимающие процессорное время
В статье:
технический директор Azure Марк Руссинович запретил разработчикам начинать новые проекты на C/C++
По ссылке на слове "запретил": "запущен проект по включению разработки драйверов для Windows на Rust, разработчики проекта пояснили, что этот репозиторий всё ещё находится на ранней стадии разработки и пока не рекомендуется использовать его для коммерческого использования". Новость тоже ИИ писал?
Ну и да, новость - классическая шняга про Ходжу, шаха и ИИ ишака. Плохо только, что "к 2030 году" про нее никто не вспомнит, никаких выводов сделано опять не будет, появятся новые "амбициозные задачи", от очередных "ведущих инженеров", решивших продвинуться здесь и сейчас по принципу "казаться а не быть".
P.S. Вообще конечно удивительно, что "инженеры" сейчас настолько деградировали, что позволяют себе нести подобную шнягу. Так и представляю себе этого Галена Ханта ближе к 2030 году в поисках новой работы:
- За что вы отвечали в Microsoft?
- За перевод кодовой базы на Rust.
- А-а, так это вы тот идиот, который обещал миллион строк в месяц с ИИ и одним инженером? Пошел нах...
Он не обещал миллион строк
Наша путеводная звезда...
По ссылке на слове "запретил":
Там в оригинале «запретил»:
It announced in 2023 that it would rewrite parts of the Windows kernel using Rust after Azure CTO Mark Russinovich forbid developers from starting new C/C++ projects and required them to use Rust instead.
Что характерно, оригинал ссылается на новость с формулировкой о «прекращении разработки новых проектов на C/C++».
Боюсь такие всегда будут в цене, не смотря на все их косяки.
весь этот переезд с С/С++ напомнил повальное бегство от FLASH-технологии: годами использовали все и вся, было сделано куча самых разных крутых и не очень плагинов, приложений и игр, а потом резко все начали сливать и спрыгивать, рассказывая небылицы про "небезопасность и уязвимости". Вот 1 в 1.
Годами на С/С++ всё работало и работает, лучшие виндовс были на нём написаны - да такие, что Микрософт понадобилось прямо запрещать поддержку старых версий, потому что никто на новые не спешил.
с ассемблера надо все переписать, главное фреймворков побольше и самых безопасных. даешь примитивный блокнот весом в 20гб и требующий nvme sdd
рассказывая небылицы про "небезопасность и уязвимости"
Там реально была куча дыр, позволяющих выполнять код без проверок. И была куча троянов, которая через это заражала компы.
Настроенные политики безопасности + нормальные браузеры. И ничего, жили без вирусов. Самый главный вирус всегда сидел перед монитором..
То есть "пусть у меня будет корявое и с дырами безопасности всё, но давайте наворотим вокруг этого отдельные стены", так вы рассуждаете?
Это похоже на то, как поступили браузеры, кстати. Они не осилили работу без ошибок и падений, поэтому решили, что лучше под каждую вкладку сделать отдельный процесс, который будет падать не унося весь браузер. Это признание некомпетентности и кривой кодовой базы.
Вот как раз Раст это и решает, кстати.
"Нормальный" браузер не поможет, когда эксплойт взламывает виртуальную машину флеша и запускает нативный код в адресном пространстве браузера.
Тогда в Microsoft о безопасности вообще не думали. Например, они сделали автозапуск исполняемых файлов со сменных носителей, что могло пойти не так?
вы так пишете - как будто с уходом FLASH это всё пропало.
Нет, не пропало и до сих пор в самых разных популярных приложениях и сервисах случают утечки и взломы - да такие, что сливают базы пользователей миллионами.
И до сих пор самый разный софт и фреймворки - если их не обновлять и не выставлять им правильные правила - допускают увзявимости, бекдоры и взломы.
И сейчас вполне себе есть и трояны, и майнеры, и боты-блокировщики - это не ушло никуда ни из ос, ни из браузеров.
"реально была куча дыр" - слава богу, закрыли флеш и с этим попустило. Теперь вот осталось С/С++ выкинуть - и заживём счастливо, без уязвимостей и троянов, наконец-то светлый, безопасный софт восторжествует, хоть бы дожить
Где-то кажется такое уже было, когда программистам платили за количество написанных строк, а не за закрытие тасков и качество кода...
Новость как раз к 25-летию статьи о вреде переписывания ПО: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
Сейчас реалии поменялись очень сильно. Все эти edge-кейсы можно предусмотреть и в новом коде.
Каждое следующее поколение уверено, что оно первое придумало секс, а до этого реалии были сильно другие.
Сам-то понял, что сказал?
Отслеживать ответы на свои комменты в реальном времени и агрессивно испражняться реагировать в карму в течение минуты после публикации - это какой-то очень высокий уровень стресса. Я мог бы пояснить свою мысль, если метафора у тебя ничем не отозвалась, но уровень твоей дискуссии в этой и других ветках не позволяют мне этого сделать.
Он понял, я понял, другие помимо вас тоже поняли. Проблема на вашей стороне.
От создателей "запретим ДВС к 2035"
Заменят на говнокод от ИИ... И будут каждый вторник по 500 патчей выпускать для латания этого кода 😁
А я то думаю: почему после каждого обновления что-нибудь да наровит отвалиться? А это Майкрософт балуются с растом.
Очень странное решение. Чем ведь формально оправдывают переход на Rust? Что он более безопасный и там не будет ошибок. Но тогда получается, при переписывании с C++ - эти ошибки надо обнаружить, чтобы перенести код в Rust. Но если при анализе эти ошибки будет обнаружены - так может просто их из С++ кода убрать, не переписывая на Rust.
Так-то оно так, только обнаружением ошибок будет заниматься растовский borrow checker. А это реально крутая штука, основанная на формальной логике без всяких там ИИ. И пока этот борроу чекер не пропустит, компилятор такой код просто не скомпилит.
Ну так я про это и говорю. Переписали код с C++ на Rust. Он не проходит bc. Дальше-то что?
Надо или переписать код на С++, чтобы при переделке в Rust он проходил bc, либо дальше переписать код на Rust, чтобы он проходил bc. То есть в любом случае дело не переносе кода, а в поиске ошибок.
И где гарантия, что после переделки код хоть и станет проходит bc, но останется эквивалентным по действию старому коду на C++?
И где гарантия, что после переделки код хоть и станет проходит bc, но останется эквивалентным по действию старому коду на C++?
100%. Многие не понимают что мало переписать код.
Он еще должен:
1) работать
2) работать точно также как работал ДО этого.
И вот тут возникает вопрос на миллион - кто это все будет ревьювить и проверять ?
Насколько знаю, для раста нет гуи-фреймворка... Вот когда боров-чекер осилит сложность уровня фреймворка Qt, к примеру, тогда да, rust будет считаться крутой штукой. Очень жду, пока просто изучаю потихоньку, т.к. без гуя задач под него пока нет...
https://areweguiyet.com/ - чтобы освежить свои знания
Можно просто помочь в разработки профилей на С++ и будет вам borrow checker на С++. Пишите proposal
Borrow checker крут и реально отсекает много ошибок. Но он не чинит бизнес-логику, не убирает panic’и и не отменяет тот факт, что при переписывании появляется новый код и новые баги.
Говорю на реальном примере нашего проекта где кучка вот таких вот Rust энтузиастов потратила дофига времени на переписывание и потом фиксинг всего и вся, и так же до сих пор фиксят, так скептицизм должен быть выкручен на максимум, когда кто то собирается переписать, чтобы было безопасно.
Окей, допустим мы их обнаружили и оставили кодовую базу на С/С++. Но когда кто-то вносит туда изменения, опять вероятность около 75%, что внесёт уязвимость. Раст такого не позволит.
Во-первых, не позволит, если всё получится все переписать без unsafe, в чём я сильно сомневаюсь. Во-вторых, как и любой другой язык, Rust так же не застрахован от возможных ошибок, пусть меньше, но они будет, не сомневайтесь. В-третьих, а к тридцатому году будет уже готова армия разработчиков, которые будут дальше туда вносить изменения? Или там уже не будет ни кино, ни театров, а один сплошной ИИ?
ось, вернее то, что ее заместит, будет генериться прям по ходу пользовательского опыта в текущем сеансе работы.
Пользователю больше не придется работать с объемами данных.
Только с намерениями. Возьми эти вот данные и сделай из них другие, объясни мне в максимально игровой форме суть твоей работы как будто я ученик 5го класса.
переписать без unsafe
Почему все, кто не понимает Раст, не понимает и unsafe? Хотя что это я...
unsafe используется чаще всего только для FFI, то есть для работы с API системы, с указателями. Это каких-то 1-3% от программы. И если там не допущено ошибок, то всё остальное уж точно не будет содержать use after free, race condition и тому подобного.
Это каких-то 1-3% от программы
в обычной программе да. В ОС всё-таки больше. Тот же менеджер страниц виртуальной памяти примерно весь будет на арифметике указателей. Работа с DMA и т.д. туда же...
А сколько процентов от ОС менеджер страниц и работа с DMA?
Ну всяко больше, чем в каком-нибудь калькуляторе
В хороших ОС - это и есть ОС! =) Ещё остаётся поддержка потоков/процессов, интер-процессной коммуникации и планировщик. Остальное - можно считать драйверами разной степени интеграции в это ядро. Если бы МС заявил что-то типа "мы перепишем всё, кроме системного ядра" - это можно было бы понять. Но ядро на раст по моему действительно будет выглядеть как большой комок ансэйв и палок ))
Так они как раз и собираются переписывать API системы и её ядро, и там это будет не 1-3%.
Doom перенесли на Раст.
Ознакомьтесь с результатом
проблема в самой концепции исполнения и тех так сказать концепций Раста, кароче если сейчас писать язык, если вы мне не верите, в свободное время советую,
значит чтобы познакомиться с иными концепциями исполнения, нам надо
написать форт с такой ситуацией, вводим понятие владение, вводим понятие ресурс, вводим понятие мета-стек помимо теневого стека и помимо основных стеков, вводим понятие доказательство кода, перед тем как запустить код стоит задача доказать то, что написано на языке это безопасно, именно поэтому всё так идёт, и именно эта концепция убивает фон-Неймана, потомучто потом окажется статико-динамическая концепция такого рода верификации до запуска, единственный выход добавить исключительную верификацию...
В 1-p код для Android было добавлено что-то около 5млн. строк кода на Rust. В 2025 (за первые 9 месяцев) нового кода на Rust впервые стало больше, чем на C++. В среднем коммиты на Rust откатывались в 4 раза реже. В коде на Rust была найдена 1 ошибка доступа к памяти на 5 млн. строк или 0.2 ошибки / млн. строк. В коде на C++ в среднем было под 1000 ошибок доступа к памяти / млн. строк.
https://security.googleblog.com/2025/11/rust-in-android-move-fast-fix-things.html
Так что Rust на масштабах MS / Google / Amazon просто сильно лучше C++. Только нормальный, конечно, а не из под нейронки. И без переписываний модулей оттестированных годами.
В коде на C++ в среднем было под 1000 ошибок доступа к памяти / млн. строк.
В свое время, когда я читал эту статейку, мне эта "статистика" очень глаз-то резанула, это одна ошибка доступа к памяти на 1000 строк. По моему личному опыту это даже не близко - я бы сказал, разница на пару порядков как минимум. Впрочем, пропаганда раста идет весьма оголтело, чего стоит хотя бы обсуждаемый высер от "ведущего инженера микрософт", на фоне которого высер от гугла даже как-то скромно выглядит, бгг.
1 ошибка на млн строк кода кажется куда менее реалистичным. Скорее всего они просто классифицируют это как какие то другие ошибки.
На примере binder, который был переписан в том же Андроиде - всего с 6000 строк была гонка memory corrupt. И это при переписывании протестированого кода.
Так что из статистика врёт - это гарантированно
Причем забавно, что Хартман поспешил заявить, что это якобы "не эксплуатируемая" уязвимость, в чем лично я сильно сомневаюсь. Уязвимости, связанные с гонками, обычно труднее эксплуатировать, это так, но зачастую это все-таки вполне возможно. В любом случае, доверять словам по-любому ангажированного гражданина я бы не спешил.
Пока есть 2 "официальных" ошибки - первая в статье выше, вторая в binder.
Про ОБЕ из них говорят, что ошибка не эксплуатируемая, про обе пытаются принизить саму ошибку - "она не добралась до релиза" или ещё чего-то.
В статье гугла так вообще смешно, оказывается там какой-то системный аллокатор, который не даёт эксплуатировать такую уязвимость. Но этот аллокатор и в С++ такой же! Но про С++ любая ошибка, абсолютно любая - эксплуатируемая и мемори и 3 в 1
Почему резануло? В среднем в продакшен коде, который я видел в последниебыло по одному issue на каждые 100 строк проекта примерно. И четверть из них — реальные баги.
У Хрома на 20млн строк С++/С около 1250 RCE было, если верить Gemini. Со всеми песочницами Хрома, и статусом самого безопасного браузера.
У Хрома на 20млн строк С++/С около 1250 RCE было, если верить Gemini.
Даже если ей верить, то это получается 1 RCE на 16 тысяч строк кода, все-таки сразу уже на порядок разница. Дальше, вот например описание буквально недавней уязвимости, потенциально сводимой к RCE (от вчерашнего числа). Вся суть его в том, что в реализации сборщика мусора была допущена логическая ошибка. Даже если реализацию этого сборщика мусора переписать на расте, это ничего не даст, потому что борроу чекер раста тут будет бесполезен, а такого рода вещи будут написаны unsafe через unsafe погоняет unsafe, иначе никак. Сборщики мусора имеют много дел с разнообразными графами (и GC JS-движка хромиума не исключение), а это как раз одна из ахиллесовых пят раста - см. недавнюю уязвимость в реализации связного списка на расте, кстати. Вообще любая сколько-нибудь сложная структура из объектов со множественными связями - и все, примитивный борроу чекер раста вам не помощник, добро пожаловать в написание unsafe кода.
Где на графике общее число ошибок?) почему там только "memory .." с очередным местом про 70% industry norm (кто не в курсе, это очень давний вброс про 70% ошибок связанных с памятью, который повторяют из раза в раз уже лет 10)
По факту общее число ошибок вероятно такое же или больше, но классификацию изменили и теперь это не "ошибки памяти"
This. Вопрос не в том, как выглядит код в каждый текущий момент времени, а в его динамике.
Если какая-то технология хотя бы чисто статистически уменьшает возможность возникновения ошибок, то начиная с какого-то масштаба становится оправданной даже такая дорогостоящая процедура, как переезд.
Ну надо же чем-то десятки тысяч разрабов занять, и директор разработки премию получит. :)
Что он более безопасный и там не будет ошибок.
Нет. Что там будет гораздо меньше ошибок определённого класса, что судя по массовой миграции бигтеха с С++ на Раст, подтверждается. Правда, зачем всё переписывать, тем более с такой скоростью - непонятно.
Очень странное решение. Чем ведь формально оправдывают переход на Rust?
Microsoft один из учредителей Rust Foundation.
Дальнейшая стратегия разработки Win связана с внедрением ИИ.
Microsoft будет обучать ИИ, для его участия в разработке продукта. Возможно потребуется вносить изменения в стандарты языка, для оптимизации ориентированной именно на использование "ИИ-разработчика". Логично использовать тот язык программирования, в развитии которого сам участвуешь. Язык программирования будет развиваться совместно с "ИИ-программистами" которые его используют.
на первые 2 ваши предложения. если мы смотрим на то что останется то как есть да, если смотрим на верификацию иначе логика определенно появляется, к тому же до конца пока не перепишут на Раст не понятно что это значит, тафталогично, тоесть просто переписать, грубо говоря на поверхности просто перепишут, что это означает не понятно же до конца если бть честным, собственно вы наверно это и спрашиваете
1 инженер, 1 месяц, 1 миллион строк кода
Осталось нанять сотню инженеров, которые будут осмысленно ревьюить по 1000+ строк в день, чтобы поспевать за этим ИИ.
Если же все это планируется в продакшен без ревью, то, это как-то, даже, не смешно, а, скорее, страшно...
а слабо сделать так чтоб комп на 9950х3Д c текущим Вин11 на samsung 990EVO мог открывать директории и запускать простое ПО(блокнот) быстрее чем комп из начала 2000х годов с ХРюшей и со старым диском-шпинделем?
Это слишком сложно! )) Я до сих пор помню ситуацию у себя на работе в 2001-м: сидит мой коллега напротив меня и впихуривает 95-ю винду на новейший на тот момент процессор. Наконец винда запускается и я вижу на лице Леонида радостную улыбку вперемешку с удивлением. Он произносит: "О! Так вот как она оказывается должна была работать! А я 6 лет не мог понять! Ты посмотри, тут же пуск и проводник моментально открываются! " ))
Я это запомнил, и стал наблюдать из версии в версию как открываются пуск и проводник )) Всё просто - если слишком медленно, то просто на этом компьютере рекомендовано ставить выньдоус на две версии ниже, даже если по мнению мягкой конторы он "windows что то там ready" =) Может их там в МС чем то кормят не тем, что у них восприятие замедляется!? , не знаю... ))
А я уж думал, что отказались от подсчета строк кода как показателя в программировании, ан нет.
История идет по спирали......
Так была на той неделе уже новость, что на Rust'е нашли уязвимость в ядре Линукс: https://www.linux.org.ru/news/security/18170738/page7?lastmod=1766324433508
Так что от глупых ошибок ни Rust, ни другой язык не спасёт.
Интересно, а как они планируют WinAPI и COM целиком на Rust переписывать?
"Давайте всё перепишет" -- это классика тупизны из книги "In Search of Stupidity" by Merrill Chapman. Они решили повторить ошибку Netscape, которая его убила в пользу IE. Ирония судьбы.
Нередко интернет-магазины кушают +1 Гб оперативки. Теперь ещё Windows "оптимизируют".
Угу, миграцию через ИИ всего кода они могут, а в новую панель задач внедрить старые функции или сохранить работоспособность старой — нет
Может в Майкрософте решили дать волшебного пинка комитетчикам из WG21? Тема актуальная.
03.03.2025
Бьёрн Страуструп (Bjarne Stroustrup), создатель языка C++, призвал комитет WG21, отвечающий за разработку стандартов для языка C++, предпринять меры для сохранения актуальности C++ в условиях активного продвижения инициатив по переходу на языки, обеспечивающие безопасную работу с памятью. Страуструп считает, что язык С++ уже содержит все возможности, необходимые для безопасной работы с памятью. Остаётся только предоставить средства, гарантирующие, что код написан с использованием только безопасных возможностей.По мнению Страуструпа, времени осталось очень мало и необходимо до 2026 года успеть предпринять какие-то меры, так как Агентство по кибербезопасности и защите инфраструктуры США и ФБР стали более активно продвигать среди производителей ПО идею перехода на языки, безопасно работающие с памятью.
https://www.opennet.ru/opennews/art.shtml?num=62821
а Кобол когда?
исключить из кода Microsoft каждую строку на C и C++
объединении ИИ и алгоритмов для переписывания крупнейших кодовых баз Microsoft
Ахахахах. Это точно не шутка? Я так давно не смеялся XD
Знаете, если выстроить список самых худших возможных решений, которые могли бы принять эффективные менеджеры майкрософт, то это решение было бы однозначно на первом месте. Даже просто закрыть компанию было бы более гуманным решением.
Вроде не 1 апреля ещё. Ну по факту они в 11 Винде столько всего сломали, и ещё при этом системные требования подняли, что пользователи потихоньку перетекают на другие ОС. Банально - сломали переключалку языков, до 11 винды я уже забыл, что на жк мониторах есть cleartype, панель нижняя вообще вся сломана, ничего с ней нельзя сделать
Пришла пора обновить мем
Каждый год кто-то хоронит C и C++. А они всё ещё лежат в основе половины индустрии и никуда не спешат
Нейрослоп добрался наконец-то и до кода Винды. Увы. Помянем.
Вот если им удастся построить AbstractSyntaxTree кодовой базы (средствами интроспекции и рефлексии например). Потом отрефакторить на уровне AST алгоритмически, математическим аппаратом. (Дедупликация, уменьшение связности, алгоритмическая оптимизация) То тогда из валидированного AST можно нагенерить код на любом языке. По мне, выглядело бы победоносно)
Вдруг, они так собираются. А не переводить с языка на язык, построчно, со словарём)
Без шансов. Это может сработать для любого бинарника любого размера. Но единого бинарника. А в условиях когда у них множество модулей и программ которые компилируются раздельно и как-то взаимодействуют разными путями не сработает. Там слишком много неоднозначностей.
Так что помянем.
С рефакторингом на основе AST и верификацией есть проблема. Не существует алгоритмов верификации на данный момент, которые могут за обозримое время верифицировать на корректность произвольный конкурентный (concurrent) код. Там что-то связано с экспонентой в оценке сложности алгоритмов верификации от размера кодовой базы.
Вот если им удастся построить AbstractSyntaxTree кодовой базы (средствами интроспекции и рефлексии например).
Я всегда думал, что AST строится парсером, но что я понимаю в компиляторах.
То тогда из валидированного AST можно нагенерить код на любом языке.
Нет, конечно, нельзя. AST всё ещё ссылается на примитивы и семантику языка, и хотя бы полуразрешимо сохранить семантику при переносе с одного языка на другой — задача не очень тривиальная.
Ну либо у вас очень много запихнуто в «отрефакторить на уровне AST», где-то на уровне консольных кальсонных гномов и их бизнес-плана с (2) ??????? (3) PROFIT.
тут парадокс в том, что модель верификации до запуска исполнения должна доказать корректность кода, это не совсем АСТ стадия, это какая-то хитрая стадия, целью которой проверить следственные связи всего кода, тоесть там что-то наподобии математических теорем верификации кода, код как бы в следствии верификации, после верификации либо пригоден либо нет, это достигается вводом новой модели исполнения которые обсчитываются на стадии верификации
в этом и кроется ситуации по сравнению с прямым исполнением таких как форт в первом приближении и с и асм и с++
в одном случае из дерева генерируется байткод на исполнение сделай 1 + 1
в другом случае генерируется модель кода где результатом будет косвенные прямые связи на владельца владение и валидность ресурсов
Очередные кричащие "прорывные" решения, но не ради клиента, а ради себя самих. Идея уже подвергнута сомнениям - что говорить об её успешности - директор захотел, увы.
индусы добьют майкрософт
Возьмите меня <3
использование "безопасных" языков, как ответ на проблемы с "разнообразными" программистами понятно, но хорошее старое то зачем переписывать? новые приключения шурика прям получаются
всё очень прозаично и ничего нового нету, я даже не спорю с вами, просто инкременты декременты и арифметика указателей это кайф ;) тут пожалуй даже не знаю, что лучше С С++ или Раст, но 2 этих действия(а на деле 4) если добавить еще арифметику указателей, то это целая песня
сразу приведу пример,
int c[2000];
int* a=c;
int* b=c;
*(a++)=11;
*(++a)=15;
*(b++)=20;
*(++b)=30;
int g=*(b--);
*(a++)=g;
b=--a;
printf("%d\n",*b);Нубский вопрос по теме: а что там вообще с системным программированием на Rust? Есть что почитать по темам: как реализованы ассемблерные вставки, доступ к прерываниям и регистрам, стыковка библиотек самого Rust с системными либами (на низком уровне у всех своё управление памятью и свои системные вызовы) и т. п. Пока что смотрел, всё больше про веб-серверы и прочие высокоуровневые темы.
https://share.google/aimode/H3WGmYMQ8sRJjKfq2
Считайте это вместо LMGTFY, вопрос просто действительно странный.
pub fn main() {
let mut x: i64 = 10; // Явно указываем 64-битный тип
let mut y: i64 = 0;
unsafe {
core::arch::asm!(
"mov {tmp:r}, {val:r}",
"add {tmp:r}, 1",
val = inout(reg) x,
tmp = out(reg) y,
);
}
// Читаем xy, чтобы верификатор видел, что запись была не напрасной
println!("Результат x: {} y: {}", x,y);
}
кароче суть в том что надо просто 1 раз понять новую модель не фон_неймана, до запуска верификатор должен доказать что то чо мы используем существует и валидно
мы создали тип i64 c словами let mut это модификаторы времени или изменения, назвали их тоесть превратили в переменные, и дали им значения, далее мы воспользовались тем что существует в библиотеке существует? существует, далее на птичьем языке описали что нам надо(подбор регистров) верификатор проверяет их соответствие и безопасность, далее проверяет связи с val и tmp с x и y, учитывая inout(reg) out(reg), читаем из переменных чтобы верификатор окончательно доказал использование x y
FFI, но чтобы в нем разобраться, нужно прочитать весь Rustonomicon, т.к. модель памяти отличается от С.
Я не знаю, какие именно прерывания вы имеете ввиду. Но на микроконтроллерах прерывания реализуются библиотеками рантайма, например cortex-m-rt.
1 инженер, 1 месяц, 1 миллион строк кода
Всего 2 строчки в секунду, детский уровень
Microsoft планирует к 2030 году исключить весь код на C и C++ из основных баз