Microsoft готується замінити C і C++ у своїх найважливіших сервісах на Rust (UPD)

Microsoft планує до 2030 року повністю відмовитися від C та C++ у своїх продуктах. Компанія хоче переписати критично важливі системи на Rust — мову, яку вважають безпечнішою та стабільнішою для роботи з пам’яттю. Насамперед ідеться про компоненти Windows та інші низькорівневі рішення.

Для реалізації цього плану в Microsoft уже створили масштабну інфраструктуру обробки коду. Орієнтир ініціативи — «1 інженер, 1 місяць, 1 мільйон рядків коду». За словами представників компанії, створена інфраструктура дозволяє аналізувати великі кодові бази, будувати зв’язки між компонентами та застосовувати AI-агентів для внесення змін у код. Частина цих інструментів уже використовується на практиці, зокрема для задач аналізу й розуміння коду.

Поворот у бік Rust у Microsoft почався ще у 2023 році, коли компанія оголосила про плани переписувати окремі частини ядра Windows після рішення CTO Azure Марка Руссіновича заборонити запуск нових проєктів на C/C++ і перевести команди на Rust. На початку 2025 року він підтвердив, що Microsoft повністю робить ставку на цю мову та активно розширює її використання.

Окремий напрям цієї ініціативи — автоматизований переклад C і C++ у Rust із застосуванням LLM`ок. Над цим працює команда під керівництвом Ґейлена Ганта, яка входить до групи Future of Scalable Software Engineering у підрозділі Microsoft CoreAI. Її завдання — створити інструменти для зменшення технічного боргу в масштабах компанії та згодом поширити ці підходи за межі Microsoft.

Нагадаємо, що Rust раніше вже інтегрували в ядро Linux, де його використання перейшло зі стадії експерименту в повноцінний продакшн.

UPD

Після широкого обговорення в спільноті Microsoft окремо прокоментувала ситуацію. У компанії запевнили, що наразі немає планів переписувати Windows 11 або інші ключові продукти на Rust за допомогою AI. Це підтвердив і керівник комунікацій Microsoft Френк Шоу.

Свою позицію додатково пояснив і Ґейлен Гант. За його словами, допис у LinkedIn привернув значно більше уваги, ніж він очікував, і що його зрозуміли не так. Насправді команда Ганта працює над дослідницьким проєктом, мета якого — створити інструменти для безпечної та масштабованої міграції коду між мовами програмування. Йдеться про зменшення технічного боргу та експерименти з поєднанням AI й алгоритмічних підходів, а не про нову стратегію розвитку Windows.

При цьому орієнтир «1 інженер, 1 місяць, 1 мільйон рядків коду» залишається радше амбітною дослідницькою ціллю, ніж обіцянкою масового переписування існуючих продуктів. Також Гант окремо наголосив, що Rust не є фінальним або обов’язковим результатом цієї роботи, а лише один із можливих напрямів.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

👍ПодобаєтьсяСподобалось8
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

а потом они лепят повсюду unsafe и получают самый банальный race condition, как недавно случилось в ядре Linux.
но кто-то уже освоил бюджет и получил медальку за георически сделанную тонную совершенно дурной работы.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Оскільки у цій темі всього 4 згадування «користу» то я додам п’яте.
Хто проплатить це любє хотєніє — користувачі? Тоді взагалі нічого надзвичайного — просто капіталістичний бізнес.

Хто проплатить це любє хотєніє — користувачі? Тоді взагалі нічого надзвичайного — просто капіталістичний бізнес.

ключова проблема бізнесу якраз саме у цьому користувачі готові платити і купити ок а ти готовий їм продати?

(потім ще допишу деталі)

Деякі цитати з інтернету:

«C++ was designed with systems programming and embedded, resource-constrained software and large systems in mind, with performance, flexibility, and reliability of use as its design highlights.»

«What is C++? Uncompromised performance. Achieved by: living with UB, accepting a safety trade-off.»

Safety and security ніколи не були і не будуть метою дизайну C++, оскільки головною спеціалізацією C++ є performance і зручність та ефективність написання великих і складних систем.

Але correctness, usability, safety and security можуть і мають бути метою дизайну прикладних систем, що розробляються на C++.

Для цього в світі C++ постійно створюються і вдосконалюються допоміжні інструменти.

Тому безглуздо висувати претензії C++ за відсутність того, що ніколи не було метою його створення або еволюції.

Що стосується Rust, то наявність ключового слова unsafe у Rust семантично означає: «Welcome to the club».

Прикинь, на Rust ж можна писати код без unsafe

приплюснуті вже навіть на Лінкедіні запітушились що С++ ансейф як ліпіздрічєство для тіпа джуніорів що колупаються салатними вилками в резетці під напругом двіштідваціть

Я в свое время все эти сейф заморочки считал идиотоориентированым программированием — типа если человек может допустить такую ошибку, то зачем он на проекте, тут место для тех кто знает что делает. А потом как понял — и топор и десертная ложка должны быть максимально стандартизированы и унифицированы по процессу создания.

Особливості є вони очевидні, там де переваги там же і недоліки. Інсрумент гострий як бритва — за допомгою якого робиться як шедевр так і кроваве місиво. І по Страуструпу — багато способів відстрелити собі ногу, при чому на С++ способів менше ніж на С та якщо це відбувається — то нога відстрелюється цілком.
Коли програмний продукт дуже великий, як то пошуковик Google чи браузер FireFox — задіяні купа людей, воно починає проявлятись при чому мати наслідки для бізнесу. Потрібні спеціальні інсрументи — санітайзери, а заодно і адміністративно технічні мероприємства задля підтримки наукового методу. В мовах програмування по новіше, типу Rust — там багато такого вбудовано одразу в екоситему. Той же пакетний менеджер Сargo — наприклад, чи розширені можливості компілятора — по суті вбудований санітайзер, система зборки (ніяких зоопарків там Cmake, там AutoConfig/GnuMake, там Visual Studio Build і т.д. і т.п.). Відсутність архаічних конструкцій типу оператора goto, кращій оператор match а не switch і т.д. і т.п.
Інша справа чи вирішує Rust саме ту проблеми на які притендує — ні, вони так в принципі не вирішуються, тільки зменшується верогідність — а за це є відповідна плата unsafe, та потрібно писати чи генерувати обгортки над системним чи іншим С API. Чи можна покрити в modern C++ — ті проблеми які вирішує Rust, додатковими інсрументами — так, проблема в тому що їх величезний зоппарк. Взяти тільки пакетний менеджмент : Conan, pkg-config/Cmake/native OS package management, vcpkg і т.д. і т.п.

pkg-config/Cmake/native OS package management

То різні частини зв’язані з пакетуванням, і сам по собі нічого не говорять.

А відносно — ще один вбудований чи інтегрований менеджмент з якою-небудь окремою мовою програмування — то практично мало що вирішує, а зачасту навіть погіршує і ще більш все заплутує. Зоопарк в стилі perl/python/node/dart/rust/etc. — пряме тому підтвердження, а не пряме — розповсюдження різного типу контейнеризацій-віртуалізацій зі збереженням відповідного environment щоб то все хоч-якось працювало не тільки на компі розробника.

багато способів відстрелити собі ногу, при чому на С++ способів менше ніж на С

Я не згоден, що на С++ менше способів «відстрілити ногу». Лінус напевно також :-)

Проблема С++ це те, що більшість способів приховані в коді та доволі неочевидні. Також STL та інвалідація ітераторів, чого в принципі немає в Сі. Ну і взагалі, якщо користуватися стандартними паттернами Сі розробки (двозв’язні циклічні списки, інтруїзивні контейнери), то передбачуваність коду більша.

Проблема Сі скоріше у тому, що ці паттерни з часом втрачаються, бо вивчення зараз починається з ООП. Також в Сі дуже дрібні шматочки Lego, та багато boilerplate коду, що лякає та відштовхує більшість розробників.

А так вся історія розвитку С++ це відкриття нових способів відстрілити собі ногу, та потім додавання фічей щоб цього уникнути.

Також STL та інвалідація ітераторів, чого в принципі немає в Сі.

Якби була така ж бібліотека за функціональністю — були б такі ж ітератори, і вони так само б інвалідувались. Від мови не залежить.

Ну і взагалі, якщо користуватися стандартними паттернами Сі розробки (двозв’язні циклічні списки, інтруїзивні контейнери), то передбачуваність коду більша.

Якщо потрібна хеш-мапа, до чого тут ці «стандартні паттерни», які просто недоречні до задачі?

А так вся історія розвитку С++ це відкриття нових способів відстрілити собі ногу, та потім додавання фічей щоб цього уникнути.

В історії C++ важливо те, що кожний крок сам по собі був повністю розумним, але в сумі вони дають щось схоже на шлях абсолютно пʼяної людини.

В історії C++ важливо те, що кожний крок сам по собі був повністю розумним, але в сумі вони дають щось схоже на шлях абсолютно пʼяної людини.

імхо я так не думаю тобто я думаю інакше як пояснити оце

але в сумі вони дають щось схоже на шлях абсолютно пʼяної людини.

імхо проблема в тім що по переході сі++ до повного керування саме committee цей процес і став «нагадувати» роботу саме committee як вона саме є як то зокрема як саме робота committee як лише виключно метою та ціллю власне сама робота committee хоча звісно і не явно (досі здається явно то є так не називали принаймні)

Той же пакетний менеджер Сargo

А я чув що його критикують як щось стороннє, але безальтернативне, і тому це руйнує прайвасі. На сішечці можна качати бібліотеки звідки завгодно абсолютно анонімно.

А я чув що його критикують як щось стороннє, але безальтернативне

github.com/...​ki/Third-party-registries

doc.rust-lang.org/...​ies-from-git-repositories

На сішечці можна качати бібліотеки звідки завгодно абсолютно анонімно.

Literally noone: “I wish I could download my dependencies from some random websites rather than just running `cargo add dependency_name`”

Который раз уже пророчат что сейчас то от С++ откажутся. Ответ нет.

Я от просто чекав, коли напишуть, що це черговий хайп. Там як виявилось ще злили інсайти, що більша частина ядра написана на С, а не С++ — бо С++ для цього занадто високорівнева мова.
У Rust ціла купа особливостей, які роблять його прикладною мовою яка не зовсім підходить для системної робки, з відповідним костилем unsafe.
С від початку так і створювався в Bell Labs, як компромісний варіант. А з оновленним стандартом 23, це вже дуже сильно не та сама мова програмування що KR&R, різниця як із древнеруською мовою або строанглійською і сучасними слов’янськими мовами і cучасними діалектами англіської. Водлрозділ С99. C++ 11 і подальше — теж в сутності modern C++. А от компілятори і інструментами як то санітайзери проробили такий шлях, що Rust ще дуже сирий.
В свою чергу Rust — гібрид із сімейства ML і в певних випадках має переваги. Скажімо високо навантажений мікросервіс із REST API — на чистому С++ писати дорого і муторно, а от на Rust — прийнятно. Можна комбінувати, і мати переваги в порівнянні із з’язкою Node+C++, Python+C++, Java чи C#. Та навіть із Go Lang або D, бо в обох є збірка сміття, що оверхед.

їжаку зрозуміло, що то все рептилоїди, а не дух часу

Числа є у вас про «дух часу». Перехід на будь яку технологію, це інвестиції — а їх треба робити на базі раціональних прогнозів і калькулятора. І взагалі дух часу зараз — ШІ. При усій повазі Rust не є мовою над високого рівня, де можна програмувати описом юзер сторів наприклад і доробляти промптами, що має трошки ще пришвидшити виробничість праці ІТ-шників і знизити собівартість виробництва ПЗ. А саме це є головним прагненням будь якого капіталістичного бізнесу — збільшити норми прибутку.
А переписувати відтестований і робочий в продакшені код — просто щоби переписати, ну таке. Витрати мільярди долларів і мати купу потенційних проблем.
Уся движуха на вколо Rust — маркетинг Mozilla Foundation з просуненням свого засобу розробки. Лобізм напевно має місце.

Якщо ти пам’ятаєш в сусідньому треді даної теми мова ішла про «не для нових проектів».
На сесюріті і не тільки в нових проектів оцього нема

Витрати мільярди долларів і мати купу потенційних проблем.

інфа 146%

Уся движуха на вколо Rust — маркетинг Mozilla Foundation з просуненням свого засобу розробки. Лобізм напевно має місце.

Мені ліньки лізти шукати спонсорів гниляшки, але я чомусь впевнений що Мразіла тут нічого не вирішує. Я думаю що це лобізм мегакорпів чиї менеджери повірили в безпечне використання пам’яті ціною більшої купи коду. Не розуміють ті піджаки, що штуки які приживаються часто це найпростіші рішення. Пройде епоха і про Rust забудуть зате буде 30 якихось нових JavaRust, ще більш рожевих і ще більш інклюзивних. А вся реальна робота буде так і продовжувати робитися на Сішечці.

Приклад про навантажений мікросервіс був цікавим.

Це сильно не той випадок, станом на 2025 інакше в США вже тоді катастрофічна втрата компетенцій. Та команда Трампа і Маска виграла вибори з цим, що грощі платників податків відверто митаряться і т.д. Лобізм в США завжди мав місце, в оборонній сфері це нормально. В Україні так само просували низку оборонних систем власного виробництва, тоді як військові просто хотіли закупити іноземні зразки як то Dana чи AR-15. А тиск на ШІ розробників і відповідно : NVidea, Linux Foundation, IBM, Microsoft, Google і т.д. по розробці «не на С», якраз пов’язаний із дуже суттєвими обронними замовленнями на ШІ за які йде тендер просто зараз. Там видідили величезну сумму грошей під це. Так само стали рятувати Intel, вже влили 9 мільярдів. Ті випустять відеокарти які не було грошей довести до серії, вже презентували. І разом із IBM — ШІ специфічні ASIC чіпи.

це різновид індусячого скаму та корпоративних перегонів

Ну... не думаю що це хайп. Людина займається R&D: переклад з однієї мови програмування на іншу за допомогую LLM. Переклад з С++ на Rust це просто приклад того, де це буде якщо не корисно, то хайпово та пригорне увагу. І як я розумів, мова не йшла про ядро, а більше про сервіси, яких у Windows over 9000+

А з оновленним стандартом 23, це вже дуже сильно не та сама мова програмування що KR&R,

Не думаю, що різниця настільки велика. Змінилося оголошення сігнатур функцій, можливість описувати змінні локально де хочеш, const, inline, але не сказав би що це дуже принципово:

int old_foo(a, b)
int a, b;
{
  return a + b;
}

int new_foo(int a, int b)
{
  return a + b;
}

Якщо не брати синтаксичні зміни (що можна привести автоматично), то практичний C код 2024 можна з мінімальними змінами скомпілювати K&R компілятором (якби такий був). Так, з’явилися stdint.h типи, restrict, atomics, але хто це реально використовує в масовому коді? Основна різниця це tooling (sanitizers, static analyzers, компілятори), а не сама мова.

Rust — гібрид із сімейства ML

Гібрид це сильно сказано. З ML там тільки ADT через enum + pattern matching. Все інше це imperative системна мова з С-подібною семантикою. Borrow checker взагалі не ML концепція.

Go Lang або D, бо в обох є збірка сміття, що оверхед

Для більшості задач GC overhead неважливий. Go чудово працює під навантаженням. Перевага C/C++ тут скоріше прямий memory layout, в простоті роботи з C ABI FFI, інтеграція з legacy code і системними бібліотеками без танців.

Щодо GC — який насправді як бібліотеку можна викорасти і в С/С++, то алгоритм Mark & Swip — насправді має дуже суттєвий оверхед. Якщо не використовуются методи по зниженню фрагментації пам’яті — як то G1 GC чи ZGC в сучасній Java наприклад, то оверхед зовсім суттєвий. І виходить що на пракиці Java із JIT на бенчмарк задачах із оптимізацями може показати результати близькі до С++ і навіть кращі за Rust. А на ділі із реальними задачами і суттєвим навантаженням в СPU Bound задачах і використанню великого обь’єму пам’яті GC стає на заваді і доводиться тюнити, а подекуди займатись JNI. В Node тюнити і взагалі складно, а C++ модулі розрекламована справа. Python — те саме, особливо Tensorflow, PyTorch, Caffe, Pandas і т.д.

А ще спробуйте створювати та знищувати купу об’єктів в пам’яті, і побачите як GC «зупиняє час»

Там якщо просто купа маленьких, або дуже великі обьєкти — то усе буде ок вже років із 20 як. А от коли в разнобой і маленькі і великі — виникає фрагментація. Коли ніби загально пам’ять є, але суцільного шматка пам’яті нема. В С/С++ з цим теж не так вже і давно навчились якісно боротись в розподілювачах пам’яті в стандарних бібліотеках, і усеодно часто міняють на Jemalloc бо ще є питання багатопоточності.
Те що managed — мови програмування убезпечують від утічок пам’яті, це міф нав’язаний маркетингом. Так само треба профілювати і робити усі роботи. В свою чергу від не ефективного програмування не захищає навіть ассемблер. З функціональним погамуванням теж були досліди і часто виявлялось, що ПЗ виходить краще зовсім не через мову програмування — а тому що адепти функціонального підходу мали суттєво вищу каваліфікацію, за тих хто програмував в імперативному стилі.

Такі вислови як «GC зупиняє час» дуже залежать від конкретної екосистеми. У Python одні проблеми, у C# інші, у Haskell треті. Для кожної мови (та налаштувань) треба складати окремий штучний тест, щоб показати слабке місце саме її реалізації збирача сміття. І зазвичай це виключення, які виникають при специфічних патернах використання пам’яті. Наприколад, в Go паузи ~1-10мс, не побачиш.

тобто щоб один раз нажати конкретно на гальмо, Go GC буде довго і нудно «тупити» роблячи вигляд що програма щось робить, тіпа ти не бачиш що вона «заторможена» бо вона «тормозить» «по трошки», але часто, замість один раз конкретно, рішення так собі, збільшує «гальмівний шлях»

По-перше, самі задачі зі суттєвим навантаженням процесора та використанням великого обсягу пам’яті трапляються досить рідко. Так, є рушії комп’ютерних ігор, можливо якісь складні обчислення. Але переважна більшість таких задач давно винесена в окремі бібліотеки, питання лише в біндінгах.

По-друге, якщо я правильно пам’ятаю цифри, у задачах з автоматичним збирачем сміття потрібно приблизно вдвічі більше пам’яті для ефективної роботи. Але чи справді це велика ціна? Це досить вузький проміжок між «пам’яті цілком вистачає» та «потрібно розподіляти навантаження між серверами», бо вимоги до пам’яті з часом ростуть.

Іншими словами, це проблема лише для вузького кола задач, з якими більшість розробників не стикається. Для переважної більшості розробників це не є вузьким місцем. Подавати це як загальну проблему «реальних задач» оманливо. Spark використовують ~100,000 компаній, але навіть серед них лише невелика частка стикається з проблемами налаштування збирача сміття.

А хіба тормоза Андроїд (Java) в порівнянні зі швидкодією Апле (ObjC) не доводять що GC — тормоз? Прекрасний приклад задач з навантаженням процессора в десятки % та використанням великої купи (heap).

Apple багато років на Swift із ARC, як у modern C++ із ітелектуальними вказівниками типу boost::intrusive_prt. В Android теж починаючи із версії 5 з 2013 рік ART із AOT, profile guided optimization і т.д. працює все сильно не так як в Oracle Hot Spot або Node. Хоча так оверхед безумовно є.

boost::intrusive_prt

о да, буст уже знову стандард плюсів

Взагалі йшлось про тип підрахунку посилань в Swift, в стандартній білбліотеці С++ з коробки не завезли вбудований в об’єкт підрахунок посилань, бо були баталії за std::make_shared. Потім з ним пішло маса проблем, наприклад ігнорування перекритих new/delete, витоками пам’яті в ряді компіляторів при оптимізаціях і т.д. і т.п.

boost::intrusive_prt

Так традиційно комітет перевіряє ідеї саме з Boost. Заявка є www.open-std.org/...​/papers/2016/p0468r0.html
А сама smart_ptr бібліотека перекочувала в стандартну бібліотеку саме з Boost. Так само як i відвертий костиль і work around — std::atomic. Аналогічно слабий std::thread де багато років на відміну від оновлень в boost thread з якої зроблено стандарт нема thread poll і т.д. і т.п.
Через те що процес довго був схожим на Algol 68, то і ряд компаній почали створювати D, Go lang та Rust. Битва за злам ABI між Google та Microsoft вже років 10 йде, бо в компаній були протилежні бізнес інтереси. Зараз із : Azure, Bing та ChatGPT усе не так вже і сильно розходься.

те що мігрує щось із буста в std:: це джунам розказуй, а наразі виходить що потрібно клеїти ще буст в білд

Вже з ШІ різними, виходе що не так — софт де треба виділяти пам’ять під нейронні сіті великими шматками, далеко не така вже і рідкість.
Скажімо є якісь бізнес сервіси по генерації зображень чи музики. І під кожну сессію клієнта, виділяється як великі шматки пам’яті під тензори і матриці із векторами, так і купа дрібних типу під JSON і т.п..
З класичними CRUD для автоматизації якихось звичайних бізнес процессів дійсно, проблеми масштабування здебільшого пов’язані із IO bound навантаженнями і відповідно, GC і інтерпретація навіть без JIT — може бути окупна. Пам’ять розходиться зазвичай під велику кількість дрібних об’єктів. Софт для аналізу медичних данних із масс спектрометрів із Web інтерфейсом і SAS бізнес моделлю, справді рідка штука (колись у вашого поточного роботодавця був замовник який цим займався і його викупив один Big Tech теж з Сієтла і закрив в 2009, звідти і походять ленінка продуктів і напрямок нативної інтеграції). А переваги типу write once run everywhere — мали більші бізнес пріоритет.
Та тут теж є проблеми масштабування з рішенням в асинхронних сокетах, реактивне програмування і т.д. І теж гібридні рішення часто, типу Netty — і усе що с гори типу Spring Reactive WebFlux, чи JBoss Whild Fly і т.п.
Ігрові движки і сервера мультплеєрів — ви самі вже зачепили.
Треба ще зазначити, що GC має і дуже велику перевагу — можливість дефрагментувати пам’ять. В розподілювачах пам’яті типу jemalloc, pdmalloc і т.д. — там якраз часто боротьба через розширені методи сегментації об’єктів по розміру.

Типовий сервіс генерації зображень виглядає так:

import torch 
from diffusers import StableDiffusionPipeline

pipe = StableDiffusionPipeline.from_pretrained("path/to/model")
request = {"prompt": "квадратний трьохчлен", "steps": 50, "seed": 12345}
image = pipe(
    request["prompt"], 
    num_inference_steps=request["steps"],
    generator=torch.Generator().manual_seed(request["seed"])
).images[0]

У цьому практичному сценарії модель (гігабайти) виділить PyTorch (CUDA) де їй треба, це може бути звичайна пам’ять, відеопам’ять, може бути спеціальна алокація з меппінгом для GPU. Розробник про це навіть й не здогадається. А в самому Python буде мізерна частка, навіть можливе копіювання зображення в результаті це мізер.

В цьому сенс скрипта. Скрипт — як відомо відрізняється від застосунку тим, що користується можиловостями базової платформи, наприклад браузера, Node або c cpython чи pypy яким pip пакетним менеджером доданий Tensorflow або PyTorch модулі. Є ще проміжковий варіант як то Java чи C# із байт кодом, або WebAssembly, WebGPU і т.д. і т.п.

«По мощам и елей», если вы в курсе этой истории.

оригінал не кацапською мовою

якщо такий мовнюк, то зроби мовою

колись у 2006-7у, коли студію можна було купити на ринку у вигляді диску, у комплекті з мсдн, усе було русіфіковано, а я, учень 11 класу, знав англійську мову на рівні май нейм із та лондон кепітал, я знайшов можливість пізнавати мову програмування через призму російського перекладу. За кілька місяців до мене попали уроки програмування від ка шаг, які були заточені під більш стару версію (здається vs 6+) студії і плюсов у комплекті, на шо мені пішло десь з тиждень зрозуміти, що проблема у тому, що хелло ворлд не працює у тому, що потрібно написати use namespace std;
Потім я пішов вчитись, і хвороба прогресувала — під кожну нову русіфіковану студію я шукав русіфікований мсдн, який обов’язково ставився. Бо часи страшні були, інтернет якщо і був, то через модем у вигляді телефону з кількома гігабайтами на місяць.
З часом, і покращенням доступу до інтернету, відповіді шукались на таких сайтах, як sql.ru, бо дибілятко не вміло у англійську і було обмежено запитами мовою росіян. З часом складність запитів зростала, і росіянофікований сегемент гуглу вже перестав задовільняти кількістю відповідей, а саме головне — швидкістю та якістю відповідей. І от у цей момент вийшла нова студія, яку, я, чомусь не міг завантажити російською мовою. Чи то МСДН до неї не було російською мовою. Чи то попало на той момент, коли торрентс.ру забанили. Давно було. Щось трапилось під час чого я вирішив (колегіальне рішення було), що вже час спробувати мову оригіналу.
І, о дивний новий світ, виявилось, що не потрібно тримати у голові переклад, а стаковерфлоу кишить відповідями, не потрібно чекати поки софт русіфікують :)

ти згенерив сторіз про те що надавав перевагу одній імперській мові а потім завоукерився і перемкнувся на іншу імперську мову, замість того, щоб просто взяти і накатати версію солов’їною, як справжній, а не фейковий мовнюк

Не плутай оригінали та lingua franca з переспівами, ще один любитель Карузо в болотній трансляції)

ше одни мовнюк підтягнувся, ім"я вам легіон, які тільки мелють язиками а ніц не роблять про те що кажуть

А набхуа умовно Карузо переспівувати?) Що настільки все запущено там у вас що без переспіву нічого не дається?

якщо ти не нового господара посіпака, то зробив би те, що мав би зробити труъ мовнюк, а не перевдітий вишиватник

Такщо дійсно оригінали та lingua franca ніяк, ріал ойтішник?)

можеш назвати як хочеш, аби виправдати колоніальну залежність від заморських панів

Зрозуміло що скрепні фантазії приписувати щось комусь настількиж оригінальні як і болотний свист.

Алеж повернемося до суті
— такщо дійсно оригінали та lingua franca ніяк?

мова не про лінгву франку, а про дії справнього мовнюка, а не посіпаку заморського пана, чи змінив господара і вже вільнонезалежний

Крутись-крутись...) суть не розболотиш

— такщо дійсно оригінали та lingua franca ніяк?

ще раз, справжній мовнюк генерить контент солов"їною, а не клацає посилання на креатив з іншою імерською лінгва франкою,
інакше це виглядає посіпацтвом тільки іншому панові

про болотний свист вище хоч хнадцять раз накарузь свої фантазії

а суть залишається -
— такщо дійсно оригінали та lingua franca ніяк?

не перекидай стрілки, а буть справжнім мовнюком, не фейковим

ясно, пиши просто як є — чи скрепи за щось в болоті зачепились і потягнули звідти переспів, і так хнадцять раз очікувати) чи з лінгва франка щось не склалося

якщо незламнику дали зауваження, то в нього опонент

скрепи за щось в болоті зачепились

але на те щоб закреативити мовою, і, навіть, зробити машинний переклад існуючої штуки на солов"їну в нього потужна неспроможність

крутись як хочеш, упонент), якщо так і не знайшов початкову опцію -

— такщо дійсно оригінали та lingua franca ніяк?

так що мовнюк створити солов"їною не годен (крім чайка-креативщини)?

То що перша та остання болотна опція — створити переспів?)

якийсь твердолобий мовнюк попався, геть не розуміє написаного, мабуть, дисклексія

Та не крутись так з тими фантазіями), ось перша опція —

— такщо дійсно оригінали та lingua franca ніяк?

чому не Державною © (тм) ?

Якось мляво вже крутишся любитель переспівів, читай ще раз нагадування

— такщо дійсно оригінали та lingua franca ніяк?

мовнюк вже не торт, якоюсь лінгвою франкою марить заморських імперців

Німець скаже: «Ви моголи».

«Моголи! моголи!»

Золотого Тамерлана

Онучата голі.

Німець скаже: «Ви слав’яне».

«Слав’яне! слав’яне!»

Славних прадідів великих

Правнуки погані!

І Коллара читаєте

З усієї сили,

І Шафарика, і Ганка,

І в слав’янофіли

Так і претесь... І всі мови

Слав’янського люду —

Всі знаєте. А своєї

Дас[т]ьбі... Колись будем

І по-своєму глаголать,

Як німець покаже

Та до того й історію

Нашу нам розкаже, —

Отойді ми заходимось!..

тусування слів туди-сюди нічого і не змінювало і не змінює, суть залишається

— такщо дійсно оригінали та lingua franca ніяк?

цей мовнюк зламався, несіть нового

:) То вже було від когось з болот зі схожою термінологією. В узькомиру так і залишитеся з тими переспівами.

— такщо дійсно оригінали та lingua franca ніяк?

я так зрозумів, що озвучки державною від мовнюків не дочекатись

Крутись заново — для любителів узькобульбашек все так і залишається, що б там у самобесідах не наспівали)

— такщо дійсно оригінали та lingua franca ніяк?

Фундаментальне нерозуміння, епічний бред.

ти згенерив сторіз про те

У тебе глобальна білочка — ти постійно додумуєш щось своє. Ось тут ти взяв і зайнявся підміною понять.
Згенерувати — це синтетично створити текст за шаблоном\алгоритмом, коли першоджерело не є власним досвідом. Я ж описав конкретний особистий спогад і послідовність подій, як я це пам’ятаю.

Не бачу сенсу локалізовувати айтішну тематику від слова зовсім. Якщо ще для навчальної бази сенс є, то перекладати такі суто-технічні топіки для advanced аудіторії — це нонсенс, або марне витрачання ресурсів.

Дореч, зважаючи на мій досвід вище + розповіді очевидців, особливо тих, хто бував на технічних мітінгах у кацапії (приблизно до 12-13й роки включно), залежність від локалізації у них дуже сильна. Власне, що ти і можеш спостерігати по цьому відео.

У мене лише одне питання, ти не думав підтягнути англійську що б не залежати від кацапо-ресурсів, які ти сюди тягнеш, ти що, залежний?

поведінка мовнюків агресивно деструктивна, на творення сил в них не залишається

поведінка мовнюків агресивно деструктивна, на творення

ггг... ага, хтось аж перегрівся від неагресивної недеструктивності до того що — відають перевагу оригінальним джерелам інформації, і не падають зразу ниць на коліна перед мудрістю творення-варення-переспівів))

— такщо дійсно оригінали та lingua franca ніяк?

мовнюки все ще не угомонилися, коли буде озвучка державною?
як то кажуть «мовнюк гірше воукера»

як то кажуть «мовнюк гірше воукера»

то там в узькомирку чи у його любителів так кажуть відносно варіння-творіння-переспівів?)

— такщо дійсно оригінали та lingua franca ніяк?

Коментар порушує правила спільноти і видалений модераторами.

Гррр.. то loop-скрепи узькомирка не"глючеого"?)

— такщо дійсно оригінали та lingua franca ніяк?

рендомно підставляти фрази у спробі когось переконати у чомусь — як правило, дохла тема.

Цей твій лівацький підходи до спроб переконати когось дегенеративні по своїй природі, а з огляду на сьогоденну політику і те, що відбувається за прикриттям підходу «ми гарні і хороші, а ви агресивні та деструктивні» — а саме прихід терористів до влади або спроб вплинути на масову думку — наслідки ставання на задні лапки доволі показові.

Ти от реально думав, що якщо назвати мою позицію «агресивно дестктруктивною» — я відразу зроблю стійку і прислухаюсь до тебе, любителя споживати і просувати кацапський контент?

на творення сил в них не залишається

Сказав чувак, який притягнув відос з перекладом кацапською мовою англійського оригіналу, і вже N-й день намагається це виправдати\захистити, бггггг.

Назвавсь груздем — полізай в кузов (версія для мовнюків: Обізвався грибом — лізь у кіш ).

давай пограємо у рольову гру, де ти шеф-кухар у київський перепічці, і ти тільки що вигадав новий рецепт перепічки і ти мені його напишеш

ти ще рольову гру в мовнюка не освоїв

С++ хоронят и призывают прям очень давно. По крайней мере я с 2002, это слышу. Это маркетинговая стратегия такая — для вывода средства разработки на рынок. Тоже самое PHP. Однако как средство технологической конкуренции — имеет место.
Даже в эталонном Rust проекте — FireFox, 4e6.github.io/firefox-lang-stats
Rust кода — 12.3%, в два раза меньше чем на С++ и JavaScript по отдельности.
В ядре Linux — использование на уровне статистической погрешности. Однако Пентагон с Кернеги Мелоун и давят уходить с С на все инстанции, впрочем они это делали и с Ada и т.д. Тогда как Bell Labs/AT&T — Google своего времени, разработали хакерские инструменты С и потом С++ клторые развиваются по сегодня. Ada имеет очеь ограниченное применение, в основном ее диалект — PL/SQL.
Rust будет иметь свою нишу, но она там де где и Go Lang и D. В основном десктоп и серверные службы типа Kubernetes, MinIO и т.п.

Плюси скоро будуть із грифом «не для нових проектів»

Зараз нема взривної розробки нових проектів, як в період з 1976 по 2015. Хард перестав розвиватись із тією швидкістю як раніше. Те і що з еконмікою IT — ми усі бачимо.
З точки зору бізнесу і заробітку — С++ дуже довго був поганою ідеєю в Україні, через червоний океан конкуренції. Але AI та Mill Tech змінили ситуацію, щоправда не для аутсорсінгу де Frontend як був в топі вже 20 років тому так і є по нині. Попит є — значно простіше шукати замовника.
В GemeDev — там С++ точно топ.

Нема то буде, тобі ж кажуть, що влданоможці стурбовані сесюрністю. Будуть впіхувать як не миттям так катанням.

AI та Mill Tech змінили ситуацію

це 20..30 вакансій які стабільно висять незакритими на ДОУ?

Те що я бачу — то Mill tech на DOU шукає переважно ленійний менеджмент, що каже лише про те, що це переважно стартапи, а також різних спеціалістів переважно із знанням системного програмування, embedded, computer vision і т.п. Коротше кажучи це усе виглялає пузирною авантюрою якщо чесно. Як і в .СOM 2003 виживуть тільки сталі бізнес моделі як то : Amazon, Ebay, та Google.
Уявіть завтра підписується перемирря чи зовсім мир — як ви оцінете стартап якій хоче робити щось військове в червоному океані конкуренції ? Це при тому що буде попит скажімо на : трактори, комбаїни, будівничу техніку яку можна буде завозити із закордону, зокрема Китаю і банально здіснювати диллерскі продажі — бо чудова маржа. Знову в топі буде e-Commerce.
Буде тут Rust або класичні Java, PHP, Node, C#, чи Python ? Відкрите питання.

Я тут до чого? Судячи із пропонованої винагороди для ардуіно-гуру і стм-нінзів їх зоряний час, якщо поліграф пропусте

Буде тут Rust або класичні Java, PHP, Node, C#, чи Python ? Відкрите питання.

без аутсорса з бодішопами ніц не буде

пентагон не зміг продавити right to repair у своїх проектах.
виробники сказали, що або у них поменьшає іновацій або вони не будуть нічого пентагону продавати.
це на фоні якогось прикладу, коли КТ чи МРТ на якійсь базі був куплений з активацією всього у рік. Рік пройшов, його дістали зі складу — а активувати не змогли (росман\ютуб).

Там зараз республіканській Сенат та Конгрес (хоч із мінімальною більшістю), активно міняє як командуючий склад так і передивляються усі підходи. Особливо нове керівництво дивлячись на війну в Україні задумалось над питаннями еконміки війни, співідношенню ціна-якість. Пентагон витрачає шалені сумми — в 2026 трільон долларів на рік. Тим не менше львина частина грошей, витрачається з точки зору аналізу їх власних служб вкрай не ефективно, стосовно реалій і потреб сучасної війни і війн майбутнього зразку. Звісно принципові системи як то засоби ровідки зокрема космічної, елнктронної, цифрової, ШІ системи і т.д. дуже ефективні. А от скажімо F-35 це провал. Проект вийшов за усі розумні рамки строків та бюджету і дійсно часто через провали у виробництві компьютерних систем літака, як по харду так і по софту. Зриви дедлайнів часто призводили до затримки передачі F-16, бо не було заміни. Ну і в цілому там чомусь при величезному бюджеті виявилось часто хаос, наприкад недостає авіа механіків. Інспекції показали — що проект ставив занадто амбітні цілі. І так по купі программ, де обговорення пішло в закриту частину через секретність.
Те що має місце часто лобізм, вже обговрють американські політики. Там доходило до того, що якийсь болт коштував 38 тисяч долларів, як автомобіль D классу в топовій комплектації. Це може вилитись в проблему — коли перша армія світу, теж може виявитись не такою вже і першою коли дійде до справи.

Учи шаблони і множинне наслідування:
www.youtube.com/watch?v=73MYSgOgawo

Це цікаво.
Бо в ядрі багато зв’зних і двозв’язних листів на сирих вказівниках.

Виявилося, що це з серії «вчені навчилися подорожувати в часі». Windows на Rust не будуть переписувати.

якась фігня несеться останнім часом,
вже й не розбереш у ваших інторнетах хто довб***б, а хто прикалується.
Літають якісь скріни з 6-ю ретвітами без пруфів.

Головне — зробити сенсацію, і щоб щось було про AI.

Rust перепише AI на математично доведений і дедлок і гонко безпечний

Це точно, лютий хайп несеться.
Якийсь бугор написав опінію від свого імені, а хвітер скаженіє кілька днів поспіль. Хоча, нема диму без вогню — rust-и агресивно просувають мову.

якщо що,

1 інженер, 1 місяць, 1 мільйон рядків коду

це тільки і тільки через нейронку. І то щоб за місяць мільйон накидати той інженер навіть не сильно вчитуватися буде.

Тобто епоха віндовз остаточно підійшла к кінцю. У них зараз при «ручній праці» величезні проблеми, а як це все перепише нейронка то стане «ше краще».

Саме гарне в цьому — Сі-реалізація небезпечна, тому вони його перепишуть нейронкою в раст. Тобто навіть якщо вони зможуть зробити так щоб воно працювало, то вони забов’язані зберегти старі дири (окрім додавання нових)

хай воно вже здохне. Не вперше таке трапляється. Динозаври вимерли — птахи залишились.
Перейдемо на Лінукс або Мак, а хтось створить нормальну венду.

Wine ще трохи допилять в плані підтримки дотнет і іншого с#, та і всьо. Враховуючи наявність всяких клаудів, то я не бачу особливо потреби у вєнді у майбутньому. Напевно і майкрософт цього не бачить, тому і намагається всяке лайно до вінь11 в авральному режимі прикрутити.

я трохи сподівавсь, що може виколупають-перепишуть старе гуан0,
а воно щось зовсім якось тойво виглядає.

А чо не на шарп? Спеціально ж робили щоб usb драйвери на шарпі писати можна було, мова майбутнього, з тими самими unsafe. Що могло піти не так?

Бо не існує насправді безпечної мови коли ти Антон Кукоба :)

Код ядра ОС та GC, який вшитий в саму основу МП (С#) - то не сумістні речі.
З цієїж причини і на Голенг не можна ядро ОС писати.

Ну... не думаю що мова йде про ядро. Але була спроба Singulrarity, OS на C# з GC, не є принципова перешкода.

А так він вже пояснив, що це просто R&D з метою зʼясувати чи може адекватно перекладати з мови на мову, це головна мета.

На Lisp (динаміка, GC) писали ОС м’якого реального часу, без мікросекундної точності. Дуже круто для заліза того часу. Та й зараз з uLisp цівкаво погратись.

Так то ж Лісп, а то Сішарп. Лісп це про те як описати весь світ за допомогою 9 (дев’яти) інструкцій. Навіть Господу Богу знадобилося аж 10 заповідей, для мене це результат. Шарп це для того щоб писати гуї на вінапі — по суті некросплатформенна джавка. При чому тут системне програмування.

Єдина причина чому ліспів нема на сучасних компах/шмарфонах — вендорам пропрієтарного ПО буде значно складніше знущатися з користувачів. Відомо, що світ ліспів це світ де працює будь-яка програма написана будь-коли без можливості встромити заплановане застарівання вам на девайс. Так вони грошей не зароблять.

>10 заповідей
Дві, насправді 😀. На них тримається весь Закон і пророки.

Там вище писали, що GC та відро несумісні. Походу, сумісні 😀

Там вище писали, що GC та відро несумісні

Господь святий з вами. Вони не сумісні. Відро це ріал-тайм система, а REPL це не відро а апішка — сутність більш високого рівня. Лішпівський REPL це, власне, перший на світі GC. Завантажуйте в нього ваші задачі — воно як робо-пес із пісні Жадана — задачі виконає, а пам’ять підчисте.

Відро ОС загального призначення то є інторфейс для заклинання святих духів заліза. Регістри, RAM, CISC/RISC система команд — розумієте? Покласти машинне слово слова в регістр ax, ще пів машинного слово в bx, прапорці із бітів в cx, потім кастуєте переривання, потім забираєте результат системного виклику в тому же eax — ну це в двух словах чим займається відерце і будь-яка скомпільована програма. ОС як така потрібна для того щоб рахувати час, девайси, ресурси — і давати можливість працювати більш ніж одній програмі одночасно. GC в цій парадигмі це зона відповідальності программіста і ніяк інакше.

«Відро» лісп-машини то є REPL і всі системні виклики тільки через нього, а якщо REPL запущений на якомусь x86 то краще всього буде зробити як в emacs — написати всі критичні функції, і ті які мають апаратне прискорення на вашому девайсі — в мікровідро на мові низького рівня шоб не робити сам REPL залізо-специфічним. А ще прикіл в тому що все що ви на Лішпах зробите, ну там функція якась або макрос — воно теж стане частиною відра. В цій парадигмі якось саме значення терміну розмивається між тими задачами які в традиційному розумінні абсолютно не відерні. Якщо потрібно 2 одночасно працюючих процеса на лісп-машині — грубо говорячи, потрібно 2 мікровідра.

Це якщо свідомо прибрехати в багатьох нюансах для мети короткого викладення.

Дві, насправді 😀. На них тримається весь Закон і пророки.

Я нарахував три фундаментально- краєкутних: не вбий, не вкради і не лжесвідчи. На двох заповідях жити в мене не виходить — мені потрібно три.

Системи м’якого реального часу. Затримки були не критичними для промислового використання (Gensym G2, Deep Space 1).

а якщо REPL запущений на якомусь x86

Lisp machine

Ваші ссилки нікуди не ведуть чомусь. Та і що я там не бачив? Якщо я десь помилився то мені напишуть, а якщо не помилявся то немає сенсу кудись по ссилкам ходити.

www.geeksforgeeks.org/...​nd-soft-real-time-system
en.wikipedia.org/wiki/Lisp_machine Там багато чого було реалізовано на апаратному рівні, наприклад GC, вивід типів і т.д. і т.п.

На двох заповідях

35І спитався один із них, учитель Закону, Його випробовуючи й кажучи: 36Учителю, котра заповідь найбільша в Законі? 37Він же промовив йому: Люби Господа Бога свого всім серцем своїм, і всією душею своєю, і всією своєю думкою. 38Це найбільша й найперша заповідь. 39А друга однакова з нею: Люби свого ближнього, як самого себе. 40На двох оцих заповідях увесь Закон і Пророки стоять.

Це не закон, а якісь побажання. Можна їх не виконувати і покарання не буде. А от без заборони на вбивство, без заборони на кражу і без заборону на брехню перед судом — не було прецедентів успішних суспільств.

З Цих двох виводиться все інше.

Можна їх не виконувати і покарання не буде

Тут нема звичного нам покарання — прокурор-суддя-тюрма. Головна загроза нерозкаяному грішнику це те, що він не матиме частки в Царстві Божому. Хоча покарання там віддано в руки людей, але воно ніщо в порівнянні з основним наслідком (саме наслідком, а не покаранням).
Якщо ви хочете закону, то такий є: покарання за гріх смерть (Рим 6:23). Смерть тут не зникнення, а стан віддалення від Бога.

а потом они лепят повсюду unsafe и получают самый банальный race condition, как недавно случилось в ядре Linux.
но кто-то уже освоил бюджет и получил медальку за георически сделанную тонную совершенно дурной работы.

це не дурна робота, це вимога багатьох держав у світі. Віндовс повинен це робити, інакше державні контракти їм не дадуть. Потрібно шукати деталі, але подібні вимоги уже давно існують

Аргумент державних регуляцій також зіграв ключову роль коли додавали у лінукс

це вимога багатьох держав у світі

которые не разобрались в сути проблемы и дуют на воду.

Аргумент державних регуляцій також зіграв ключову роль коли додавали у лінукс

и? когда мы получим полностью переписанное на Rust ядро? через 20 лет?
и все оно будет как решето утыкано unsafe. в чем profit?

Досі немає підтримки Rust для написання драйверів під Windows. Тільки експерименти на цю тему.

Ти просто казися, що твою роботу забере ші

Я по-філософські до цього ставлюся, і вірю, що колись в майбутньому людство створить ШІ, який перевершить людину. І це чудово, бо дозволить прогесу рухатися швидше.

Я думаю, тоді таку версію ШІ треба назвати skynet.

потрібне готове рішення, яке б (у мс випадку) працювало у більшості випадків автоматично і було б стабільним.

Окрім того, якщо (у випадку МС) вони не видадуть ніяких автоматичних тулінгів, це буде означати, що усі розробники попросту покладуть на це болт. У подальшому ще і якісь WDM4.0.

Має бути щось таке preview — released (optional) — ...2-3y.. — released (mandatory)
Інакше це не має сенсу. Умовна нвідія дрова перепише, усі інші — ні. Бо це не тільки їх код, це код десятків та тисяч залежностей, який писався десятиліттями. Ніхто його у здравому розумі не піде переписувати ручками.

Хіба що для галочки зробити.

Підписатись на коментарі