Вхід і реєстрація
Розробка · 2 лютого, 11:30 3198
Pavlo Trepytion, Technical Community Manager в DOU.ua

«Мінус 50000 рядків коду»: Meta переписала частину месенджера WhatsApp з C++ на Rust

Meta вирішили не відставати від тренду сьогодення і повідомили про те, що вони переписали з С++ на Rust свою бібліотеку wamedia, яка відповідає за обробку та перевірку медіафайлів у WhatsApp, що відправляються користувачами.

За словами компанії, «wamedia» обробляє мільярди файлів щомісяця на різних платформах: Android, iOS, Mac, Web, Wearables та браузерах. Функціонал бібліотеки заключається в тому, що вона перевіряє, чи відповідають медіафайли стандартам, і блокує ті, які можуть викликати помилки у вразливих ОС-бібліотеках.

Історія переходу на Rust пов’язана з ще з часів 2015 року, коли стало відомо про вразливість Stagefright, за допомогою якої зловмисники могли атакувати користувачів шкідливими MP4-файлами та заражати їхні Android-пристрої через системні бібліотеки. Тоді WhatsApp і почав захищати користувачів на стороні додатка, перевіряючи файли перед їх обробкою, замість того щоб чекати оновлень ОС.

Переписування на Rust відбувалося паралельно з оригінальною C++ реалізацією. Команда перевіряла нову версію за допомогою спеціальних тестів та порівняння результатів, щоб переконатися, що Rust-бібліотека працює так само, як стара на C++. В результаті замість 160 000 рядків C++ (без тестів) вийшло отримати 90 000 рядків Rust (з тестами). Себто загальна кількість коду зменшилася аж на 50000 рядків

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

WhatsApp також додав додаткові перевірки для ризикових типів файлів, таких як PDF, і файлів з підробленими розширеннями або MIME-типами. Комплекс цих перевірок отримав назву Kaleidoscope.

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

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

Теми: C++, Meta, Rust, whatsapp
👍ПодобаєтьсяСподобалось9
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
макогоненко 04.02.2026 17:36

> 160 000 рядків C++ (без тестів)

все шо нада знать про цей кучерявий бігтек

Відповісти
Підтримати
Andrii Sevastianov Senior Developer в TeamDev 04.02.2026 18:46

Питання чи були тут проблеми. У цілому припустимо що сервіс впав? Ну підуть файли на дзеркало.

Відповісти
Підтримати
макогоненко
макогоненко 04.02.2026 18:53

та впав чи не впав то діло десяте

160 кілорядків коду на спп без тестів — це просто профнепридатність.

хоч на расті тести написати не впало, малацці

Відповісти
Підтримати
Andrii Sevastianov
flyman 05.02.2026 10:39

в С++ тести ішли окремими юнітами компіляції, тому не враховані як LOC, в Rust в тому ж юніті добавляєш код тестування

Відповісти
Підтримати
макогоненко
макогоненко 05.02.2026 14:50

якби вони були — їх би і включили, щоб показати всю міць раст. Чому б не показати?

Відповісти
Підтримати
flyman
flyman 05.02.2026 14:52
In the end, we replaced 160,000 lines of C++ (excluding tests) with 90,000 lines of Rust (including tests).

дислексія?

Відповісти
Підтримати
макогоненко
Artem K 05.02.2026 14:30
все шо нада знать про цей кучерявий бігтек

Все що треба знати про лузерів, які не змогли попасти в біг-тех. Навіть читати не вміють толком.

160к рядків — це сама імплементація, тести — це ще окремо кількадесят тисяч рядків.
Хоча для ясності могли би навести і число рядків самої імплементації на Rust, а не тільки сумарно з тестами.

Відповісти
Підтримати
макогоненко
макогоненко 05.02.2026 14:46

Все що треба знати про лузерів які змогли попасти в біг-тек. Думають що інша частина планети не вміють толком читати

In the end, we replaced 160,000 lines of C++ (excluding tests) with 90,000 lines of Rust (including tests).

Білий пане, я щось не так прочитав?

Відповісти
Підтримати
Artem K
макогоненко 05.02.2026 15:01

схоже в тебе діплом логопєда

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

Відповісти
Підтримати
flyman
макогоненко 05.02.2026 15:04

нє, просто звик порівнювати яблука з яблуками і в мене пріщур чому ж це мета не включила в loc тести. це через арестовіча, нічо лічного

Відповісти
Підтримати
flyman
Artem K 05.02.2026 15:12
чому ж це мета не включила в loc тести

Щоб досягти реакції: «Вау, на С++ навіть без тестів все ще в 2 рази більше коду, ніж на Rust вже з тестами», очевидно ж

Відповісти
Підтримати
макогоненко
Artem K 05.02.2026 15:05
160,000 lines of C++ (excluding tests)
я щось не так прочитав?

Емм... Кагбе да. В оригіналі навіть ще простіше зрозуміти, що для С++ коду були тести, просто їх в 160к рядків не включили

Відповісти
Підтримати
макогоненко
макогоненко 05.02.2026 15:14

ладно, з’їду на нюанси перекладу я зразу оригінал не читав

кучерявий бігтек забирає найкращих з нас :)

Відповісти
Підтримати
Artem K
Імя 03.02.2026 14:26

Схоже на Node.js: ми переписали програму написану 100 років тому на неблокуючий, асинхронно асинхронний, мдно молодіжний, божественний, найкращий в світі JavaScript і отримали приріст в швидкодії. Висновок: JavaScript — супер, всім переходити на JavaScript, це саме JavaScript, а не купа інших факторів, зробив все кращим.

Відповісти
Підтримати
Чорний Список Юджина 03.02.2026 10:18

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

Відповісти
Підтримати
Lev Pa Founder в LevArc™ 02.02.2026 23:28

Ну мені воно пише при інсталяції що «Ви заблоковані з погляду сек’юріті», перевірити не можу )))

Відповісти
Підтримати
NoName 02.02.2026 22:49

даже не знаю недели 3 что бы покрыть все тестами и перевести в раст с помощью ллм ? Чем хвалимся ?

Відповісти
Підтримати
Maksym Strukov 02.02.2026 20:36

то ось чим вони всі ці роки займались.. може тепер нарешті зможуть пофіксити клієнт для макосі

Відповісти
Підтримати
Dmytro Bondarenko 03.02.2026 08:52

не раніше ніж епл навчиться дозволяти кліентам кастомні хоткеї, які не ломають пальці.

Відповісти
Підтримати
Maksym Strukov
Maksym Strukov 03.02.2026 10:32

правильно, так їх. а поки будемо розряджати батарейки своїх клієнтів

Відповісти
Підтримати
Dmytro Bondarenko
Andrei Boiko QA в GlobalLogic 03.02.2026 17:47

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

Відповісти
Підтримати
Maksym Strukov
Дмитро Борисенко 02.02.2026 15:40

Цікаво як вони обґрунтовували необхідність цього менеджменту всередині компанії. На фоні лейофів, необхідності інвестувати в інфраструктуру та таланти пов’язані з AI. Чи це мається на увазі за 10 років саме вразливу частину переписували і було легше знайти аргументацію для використання часу на це.

Відповісти
Підтримати
Vic Programmer 02.02.2026 16:33

Це швидше за усе навпаки запит від керівництва компанії. Фактично усі хто хочуть продавати якісь послуги американскьому уряду в цілому, станом на зараз — мають відмовитись від С та С++. Дедлайн вже сплив станом на 1 січня 2026 року. Код на С та С++ та інших мовах програмування окрім переліку дозволених, визнаний загрозою національній безпеці США.

Відповісти
Підтримати
Дмитро Борисенко
Дмитро Борисенко 02.02.2026 17:40

Гарний жарт. На Pytorch це особливо не вплинуло...

Відповісти
Підтримати
Vic
yvs2014 02.02.2026 17:44
Дедлайн вже сплив станом на 1 січня 2026 року.

Натякаєте на хісторі з Ada (1987-1997)?

Відповісти
Підтримати
Vic
Vic Programmer 02.02.2026 18:34

І на Algol 68 при чому дуже сильно, та факт є факт. Звісно дедлайни успішно провалені. Щодо Rust — то він загрожує швидше більш висококорівневим мовам із якими може конкурувати в сфері бекенд розробки, Desktop, Mobile та Gamdev, як то : Java, C# та Go lang. А от в стандарт С++ з дуже великою долею верогідності будуть втручатись назовні і ламати зворотню сумісність і прибирати аттавізми.
З Ada звісно комерційні результати так собі були, по суті лише її діалект PL/SQL мав успіх разом із базою данних Oracle.
IMHO Пентагону мало сенс вводити необхідність використань санітайзерів і профілювань в процесс розробки. Та по суті те саме, що і в 68-му році коли не послухали Ніклауса Вірта та Чарльза Хоара, тому що обидва були англієць та швейцарець тобто не американцями і не предстваляли інтереси американських компаній, що продавали зокрема і засоби розробки. Так що Algol 68 провалився, як і Ada. Так що Python та Ruby потрапили до списку, Approved — теж прогресс в принципі.

Відповісти
Підтримати
yvs2014
Dmytro Bondarenko 03.02.2026 09:02

У мене до вас питання, як швидко помре зумерський раст, коли\якщо с++ запилить успішні Memory-safe практики розробки коду на С++? Бо саме це є у вимогах, а не бан с++

Підтвердження **є**, але формулювання **не таке жорстке**, як у твоєму переказі. В документах США (CISA/FBI/NSA/Білий дім/OMB) лінія така: **пам’ятко-небезпечні мови (C/C++) системно генерують клас уразливостей**, тож для *продуктів* у критичних сферах очікується **перехід/план переходу** + **обмеження використання C/C++ у новій розробці, де є реальні альтернативи**.

## 1) Звідки взявся дедлайн **1 січня 2026** і що він означає насправді

Найпряміше це прописано в документі **CISA + FBI «Product Security Bad Practices» (жовтень 2024). Там:

* **Для нових продуктових ліній**, що використовуються в *critical infrastructure або National Critical Functions (NCFs)*: розробка на *memory-unsafe* мовах (напр., C/C++) **коли є «readily available» memory-safe альтернативи** названа «dangerous and significantly elevates risk to national security...» ([ic3.gov][1])
* **Для існуючих продуктів**, написаних на memory-unsafe мовах: **відсутність опублікованого «memory safety roadmap» до 1 січня 2026** також названа «dangerous and significantly elevates risk ...». ([ic3.gov][1])
* І прямо сказано: **«software manufacturers should publish a memory safety roadmap by January 1, 2026.»** ([ic3.gov][1])

Ключове: це **не «заборона C/C++ з 01.01.2026»**, а вимога/очікування **мати публічний план** (roadmap) для зменшення/усунення memory-safety вразливостей у пріоритетних компонентах (network-facing, crypto тощо). ([ic3.gov][1])

Окремий «базовий» документ під це — «The Case for Memory Safe Roadmaps» (грудень 2023), який **просуває** ідею публічних roadmap’ів і пояснює, чому лише тренінги/інструменти не закривають проблему.

## 2) Чи це «для всіх, хто продає послуги уряду США»?

У процитованій логіці «Product Security Bad Practices» мова про **software manufacturers** і особливо про продукти для **critical infrastructure / NCFs**. ([ic3.gov][1])
Це сильний сигнал для ринку й закупівель, але **не виглядає як універсальна федеральна «заборона» C/C++ для всіх контракторів/послуг**.

Водночас, **політичний/управлінський напрям** реально є: memo від **Office of Management and Budget** про пріоритети кібербезпеки на FY26 каже, що агентства мають враховувати заходи на кшталт **memory safe programming languages** і навіть підкреслює імплементацію secure software development політик **через procurement**.
Це не «бан», але це те, як подібні речі **потім стають вимогами в RFP/контрактах** (особливо у high-assurance доменах).

## 3) Чи є «перелік дозволених мов»?

У відкритих урядових документах це радше **«memory-safe languages» як клас**, а не один затверджений «allowlist».

Наприклад, у «Software Memory Safety» від **National Security Agency** (оновлення квітень 2023) наведено **приклади** memory-safe мов: Python, Java, C#, Go, Delphi/Object Pascal, Swift, Ruby, Rust, Ada.
Там же прямо сказано, що NSA радить **стратегічно зміщуватись від C/C++** до memory-safe мов, коли можливо.

Також важлива ремарка: навіть «memory-safe» мови можуть «пробиватися» через unsafe/FFI та небезпечні бібліотеки — тобто це не магія, а зниження класу ризиків.

## 4) «C/C++ визнані загрозою нацбезпеці США» — що саме там сказано

Найближче до цього формулювання — знову ж таки «Product Security Bad Practices»: там прямо використано фразу **«dangerous and significantly elevates risk to national security...»** для:

* нових продуктів у critical infrastructure/NCFs на memory-unsafe мовах при наявності альтернатив ([ic3.gov][1])
* і для відсутності roadmap до 01.01.2026 для існуючих memory-unsafe продуктів ([ic3.gov][1])

Тобто так: **в контексті критичних сфер** і **як оцінка ризику/поганої практики**, а не як «криміналізація C/C++».

---

# 5) Чи робляться кроки «у напрямку покращення C та C++»?

Так, але важливий нюанс: **офіційна лінія США — не «вилікувати C/C++», а зменшити клас memory-bugs через memory-safe мови + defense-in-depth**. При цьому паралельно є робота, щоб зробити C/C+±код **менш крихким**.

## 5.1. Те, що визнають самі урядові гіди: інструменти/мітигації для C/C++

NSA прямо описує, що можна «harden» non-memory-safe code через:

* **SAST/DAST** (але підкреслює обмеження/false positives і що це не робить код «totally memory safe»)
* **anti-exploitation** механізми на рівні компіляції/рантайму (ASLR, DEP, CFG тощо), які ускладнюють експлуатацію
* і загалом: комбінувати memory-safe мови + hardening defenses

А «The Case for Memory Safe Roadmaps» теж визнає тренінги/мітигації як історично застосовувані підходи, але підкреслює, що проблема все одно лишається системною.

## 5.2. C++: рух до «профілів безпеки» (стандартизація)

У C+±спільноті реально йде робота над **Profiles framework** та «core safety profiles», щоб дати спосіб **вмикати** перевірювані правила (bounds/type/lifetime) із можливими runtime-checks там, де треба:

* «C++ Profiles: The Framework» прямо позиціонує профілі як механізм для гарантій на кшталт **memory safety**, і що потрібні стандартні профілі, доступні у всіх реалізаціях.
* «Core safety profiles for C++26» формулює ідею стандартних enforceable профілів (bounds/type/lifetime), які компілятор може забезпечувати, інколи інжектячи runtime перевірки.

Це і є «кроки в напрямку зробити C++ безпечнішим», але це **не те саме**, що зробити C++ повністю memory-safe як Rust «за замовчуванням».

## 5.3. Паралельний напрям: «безпечність» через залізо/платформу

Техзвіт Білого дому «Back to the Building Blocks» (ONCD, лютий 2024) прямо згадує:

* **Memory Tagging Extension (MTE)** як приклад техніки перевірки валідності pointer’ів
* **CHERI** як архітектуру, що змінює доступ до пам’яті з метою прибрати типові вразливості memory-unsafe мов

---

## Практичний підсумок (щоб донести керівництву)

1. **Так, є офіційні документи**, де C/C++ у критичних сферах названі high-risk, і є чітка дата **01.01.2026** — але це **дедлайн на «memory safety roadmap»**, а не «заборона C/C++». ([ic3.gov][1])
2. Якщо ви робите **продукт** для critical infrastructure/NCFs або заходите в high-assurance закупівлі США, — очікуй, що **в procurement/аудиті** попросять:

* не плодити новий C/C++ там, де є альтернатива ([ic3.gov][1])
* мати roadmap (і після 01.01.2026 це вже «має бути») ([ic3.gov][1])
3. «Покращення C/C++» відбувається (профілі, hardening, платформа), але **державна рекомендація** все одно зводиться до: **де можливо — memory-safe мови + оборона в глибину**.

[1]: www.ic3.gov/CSA/2024/241016-2.pdf «Product Security Bad Practices»

Відповісти
Підтримати
Vic
Vic Programmer 03.02.2026 12:08

Усе не так просто насправді, є технічні репорти які представлені в комітет по стандартизації С++ і т.д. safecpp.org/draft.html
Те що аттавістичні проблеми, особливо із системою типів і моделлю пам’яті усе ще присутні в modern С++ — ще від «С з классами» це беперечний факт. Та на протязі дуже довгого часу, різні стекхолдери носяться із ABI і не хочуть його ламати через зворотню сумісніть. Ну і головне що закладено ще в С, код по суті платформо залежний і не підлягає переносу на іншу аппаратну платформу без додаткових витрат по портуванню — аля Write once run everywhere як у Java. Тобто якщо потрібно буде швидко замінити десь у винищувачі припустимо Intel на Arm, це буде занадто дорого і довго, а це вже загроза нац безпеці окрім кібр безпеки. В таких штуках отримували статистику і виявлялось, що 70% багів які виникли були пов’язані із не коректним використанням пам’яті.
Тим не менеше станом на зараз доки в стандарт не внесено зміни, уряд США не куплятиме нічого нового зробленого на С та С++, власне і не тільки Zig чи D наприклад теж. По суті бан йде на «мови які не пройшли перевірку», а не просто С чи С++. www.cisa.gov/...​case-memory-safe-roadmaps
Так само припахали і Open Source і т.д. www.cisa.gov/opensource

Відповісти
Підтримати
Dmytro Bondarenko
Andrii Sevastianov Senior Developer в TeamDev 03.02.2026 14:45
Ну і головне що закладено ще в С, код по суті платформо залежний і не підлягає переносу на іншу аппаратну платформу без додаткових витрат по портуванню

С/C++ дуже кросплатформенні, бо вся семантика побудована таким чином, що якщо десь можливі різні варіанти реалізації, то це platform dependent, чи UB та попередження. Тому зазвичай код досить легко портується навіть на контролери, де про Java ніколи й не чули. Нещодавній кейс Apple M1/M2 (ARM) показав реальність, коли величезні бази коду на С++ (Photoshop, Chrome, Unreal Engine) були перенесені простою перекомпіляцією з мінімальними правками SIMD-інструкцій. Так, можна писати платформно-залежний код, але це скоріше навмисна диверсія. Якраз з точки зору практики я більше стикався з помилками кросплатформенної Java, бо хтось захардкодив не той слеш чи взагалі шляхи, спробував додати іконку в трей або «спіймав» різні баги під навантаженням у мережі, бо під капотом epoll або IOCP.

У винищувачі буде якраз верифікований код та авіаційні стандарти безпеки, які ти досі вважаєш такими, що не вистрілили. Тому портувати його як два байти переслати. А Java там взагалі заборонена, бо немає наскрізної верифікації: немає верифікації source-коду, немає верифікації байт-коду, і головне немає верифікованої JVM, яка б гарантувала детермінованість.

По суті бан йде на «мови які не пройшли перевірку»,

По суті, якщо мова не пройшла перевірку як memory safe, це не бан, а вимога compliance. Тобі просто треба окремий пункт у Roadmap для регулятора, де ти пояснюєш, що саме у твоєму випадку гарантує безпеку (наприклад, формальна верифікація).

Відповісти
Підтримати
Vic
Vic Programmer 03.02.2026 16:43

Ну дивісться той же приклад від Саттера, із 

#include <iostream>

void foo() 
{
    char a[7] = "secret";
}

void bar() 
{
    char b[7];
    std::cout << b;
}

int main(int argc, const char **argv)
{
    foo();
    bar();
    return 0;
}
Коли компілятори до стандарту до С++26 із Little Endian виведуть на консоль, secret. А із Big Endian буде креш. Такого в мовах виского рівня не має бути взагалі, це чисто аттавізм ассемблерної природи і потенційна проблема для кібр безпеки (char b[7] по ідеї якщо нема одразу ініціалізуючого запису то має бути те саме що і char b[7] = {’\0′} усі сучасні санітайзери знають про проблему)
Я взяв один і той самий GCC 15.0.2 для x86_64 Linix, x86_64 Windows, ARM64 Linux, та SPARC Linux godbolt.org/z/nredrGzrW
Можна гратись із іншими компіляторами і опціями (вже із -O1 та GCC буде працювати по іншому, звідки баги про які треба лише знати, скажімо із тим що компілятор оптимізує memset і т.д. і т.п. от добре відео із поясненням www.youtube.com/watch?v=tjcU2xDmuFQ).
У Java наприклад, усі проблеми починаються там де якісь платформо специфічні штуки — наприклад із AWT/Swing, і то не з недетермінованностю бо программа працює, але скажімо не красиво виглядає UI і не відповідає User Expirense і design guide lines для данної аппаратної платформи наприклад Mac OS X. Власне і розробляли Java для вбудованих систем SUN. Далі була така JavaME на мобільних телефонах до єри iOS та Android (між іншим тежа на Java/Kotlin) і т.д, Applets а потім JavaFX і т.д. Так плата за це — оперативність безумовно. Ну і у GC є свої суттєві недоліки.
Відповісти
Підтримати
Andrii Sevastianov
Andrii Sevastianov Senior Developer в TeamDev 03.02.2026 17:07

Ще раз, не треба мені доводити, що на C++ можна отримати креш. Я це розумію. Навіщо гратися з кодом, який містить помилки?

Мій пойнт у тому, що якщо код відлагоджений та працює добре, то перенести його на іншу архітектуру в принципі не проблема, якщо тільки розробники навмисно не робили його платформо залежним. Що підтверджує велика кількість C++ застосунків на різних платформах, а от щось кросплатформенної Java якось давно не дуже бачу. А коли бачив, вони настільки здавалися чужими.

Відповісти
Підтримати
Vic
Nikola Utiuzhnikov Кодировщик 03.02.2026 22:32
Коли компілятори до стандарту до С++26 із Little Endian виведуть на консоль, secret. А із Big Endian буде креш. Такого в мовах виского рівня не має бути взагалі, це чисто аттавізм ассемблерної природи і потенційна проблема для кібр безпеки (char b[7] по ідеї якщо нема одразу ініціалізуючого запису то має бути те саме що і char b[7] = {’\0′} усі сучасні санітайзери знають про проблему)
Я взяв один і той самий GCC 15.0.2 для x86_64 Linix, x86_64 Windows, ARM64 Linux, та SPARC Linux godbolt.org/z/nredrGzrW

До чого тут Big/Little Endian? Ви розумієте, що помилка 

Program returned: 255
Program stderr
[F][2026-02-03T14:43:55+0000][1] runChild():486 Launching child process failed
означає, що програму взагалі не вдалося запустити на SPARC? Можете навіть спробувати скомпілювати й запустити найпростішу програму на SPARC, й ви отримаєте ту саму помилку в stderr:
int main(int argc, const char **argv)
{
    return 0;
}
Відповісти
Підтримати
Vic
Vic Programmer 04.02.2026 17:21

Так схоже Gotbolt тут не працює, так чи інакше тут undefined behavior коли cout почне читати стек це може бути як видача «абра кадабри» в консоль, так і креш коли latin 1 буде ковертуватись в повний UNICODE з 32 бітами потрібними для freetype і iconv дасть помилку.
В мовах типу Java гарантується що новий массив, який віділяється лише в статиці або через new [N] буде zeroed, як із calloc. При цьому, в С++ це абсолютно валідний код, він нічого не порушує з точки зору стандартів до С++ 26 youtu.be/kKbT0Vg3ISw?t=497 Так само скажімо опереатор delete не робить зі вказівника nullptr і т.д. і т.п.

Відповісти
Підтримати
Nikola Utiuzhnikov
flyman 03.02.2026 17:29
. Тому зазвичай код досить легко портується навіть на контролери,

І давно пан пробував щось портувати з Распері з Лінуксом хоча б на Ардуіно з ESP32?

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

Аду?

Відповісти
Підтримати
Andrii Sevastianov
flyman 03.02.2026 17:27
зумерський раст

коли сплавлять Дніпром всіх зумерів

Відповісти
Підтримати
Dmytro Bondarenko
Kostyantyn Prokhorov Системний адміністратор 02.02.2026 15:24

Парасолька дяді Сема тепер працюватиме стабільніше)

Відповісти
Підтримати
Stanislav Oles Lead Software Engineer 02.02.2026 15:04

Я зараз скажу шокуючу річ, але коли старий код переписують навіть з C++ на С++, то кількість рядків теж скорочується

Відповісти
Підтримати
Vic Programmer 02.02.2026 15:31

Modern C++ 11 та вище, та скажімо С++ 98 та Visual Studio 6.0 і MFC чи взагалі щось типу Borland C++ 3.11 для MS DOS за сукупністю усього, просто різні мови програмування зі схожим синтаксисом. Звісно мова без: шаблонів, концептів, більшої частини стандартної бібліотеки яка розширена boost, скажімо Сhrono чи коллекцій і т.д. і т.п. це сильно не одне і те саме.
Разом із тим Modern C++ все ще тримають аттавізми, типу std::terminate та відсутність stack trace в еxception-ах, самі ексепшени вже поліпшили через stack unwinding і т.п.. ABI на загал заточеного під однопроцессорні системи і ще там купа усього, дуже погана реалізація локалі — особливо для серверного коду де одна і та сама программа має підтримувати декілька локалей одночасно — коли один корситувач з UK інший з Іспанії, а третій Канади і т.д. Потрібно для того же NATO як приклад. Так само повна чехорда із строками і підтримкою UNICODE до 20 версії стандарта включно, бо мова розробки 1985 року.
В С++ 26 буде дуже довго очікуєма рефлексія, яка в стутності надасть можливість ввести в мову і borrow checker.
З моделлю пам’яті той же Пентагон не валаштовує і Rust, вони хочуть прогнозованість рівня Java чи С#/.NET. Що насправді коштує як пам’яті так і CPU.

Відповісти
Підтримати
Stanislav Oles
Alexander Dyachenko Senior C++ Developer в RingCentral 03.02.2026 12:35
все ще тримають аттавізми, типу std::terminate

а какие проблемы с terminate?

відсутність stack trace в еxception-ах

stack trace уже есть на уровне стандарта языка. не говоря уже о том, что были решения вне его.
ты не должен платить за то, чего не используешь. на нормального размера бинаре у тебя первая подгрузка pdb легко может остановить поток на сотни миллисекунд, что далеко не всех устраивает.
нужен stack trace — ну так заведи себе соотвествующий тип и его используй.

самі ексепшени вже поліпшили через stack unwinding

stack unwinding был всегда. о чем вообще речь?

ABI на загал заточеного під однопроцессорні системи

о чем речь?

Так само повна чехорда із строками і підтримкою UNICODE до 20 версії стандарта включно

не правда.

бо мова розробки 1985 року

не правда. разработка языка началась раньше. первый стандрт это 98-й год.

яка в стутності надасть можливість ввести в мову і borrow checker

как это вообще связано? рефлексия даст программе то, что всегда было известно на этапе компиляции. borrow checker работает на этапе компиляции.

Відповісти
Підтримати
Vic
Vic Programmer 03.02.2026 12:49

Давайте я вам на Герба Саттера просто посилання залишу www.youtube.com/watch?v=kKbT0Vg3ISw
А захищати свою бульбашку нема сенсу. По суті на undefined behavior пішла війна і при чому так, щоби це було на рівні compile time. Та ABI теж буде змінено.

Відповісти
Підтримати
Alexander Dyachenko
Alexander Dyachenko Senior C++ Developer в RingCentral 03.02.2026 13:37

ты правда думаешь, что я не видел это видео Саттера?
может просто когда я смотрю такие видео я понимаю о чем они, а ты не до конца? )

Відповісти
Підтримати
Vic
Vitaliy Kaplenko C++ DataBase Developer 04.02.2026 01:23

Шановний, до вас звертаються на ви, а ви у відповідь тикаєте.

Ідея в тому, що чим більше взаємоповаги, тим більше натхнення на творчість та нові оригінальні ідеї.

І навпаки, чим менше взаємоповаги, тим більше стресів, апатії та депресії, що прямо блокує здатність до інтелектуальної творчості.

То нащо нам таке щастя в нашому інформаційному суспільстві?

А помиляються всі, й прискіпатися можна до будь-якого стовба.

Відповісти
Підтримати
Alexander Dyachenko
Alexander Dyachenko Senior C++ Developer в RingCentral 04.02.2026 07:09

есть в ваших словах здравое зерно.

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

Відповісти
Підтримати
Vitaliy Kaplenko
Donald Trump 04.02.2026 03:09

Можливо. Але це зайняло би х2 більше часу і х2 більше ресурсів.

Відповісти
Підтримати
Stanislav Oles
Paul Savchuck Senior Software Engineer в EPAM 02.02.2026 15:00

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

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

Відповісти
Підтримати
Vic Programmer 02.02.2026 15:45
Але до чого тут саме раст і його «унікальна цінність» — мені не зрозуміло.

Питання в бізнесі і грошах як завжди. Пентагон (NSA), CISA і Карнегі-Меллон які історично надають теоретичну інформацію задля перших, видали рекомендації на припинення використання нового коду в мовах програмування в яких досі є проблеми ше від Algol 60. С, С++ зокрема, але також наприклад Zig або D їх не влаштовує. Делайн сплив на 1 січня 2006 року.
Задля Rust MSL типу зробили допушення до використання, де надано перелік дозволенних мов програмування. Що робить практично Rust єдиною Drop in заміною для нативного коду без Garbage Collector (виключення бо unsafe код простіше локалізувати і зробити code review, ніж в С++ де потрібні складні сторонні санітайзери типу СppCheck чи PVS, разом із Valgrind чи Intel Vtune для перевірки рантайму). Оскільки оборонний ринок, це взагалі самий смачний з ринків історично, бюджет Пентагона на 2026 — це трільйон долларів на рік, тобто потенціний заробіток (ємкість ринку) від ІТ розробок для Дяді Сема перевишує наприклад увесь ринок ІТ послуг для коcметології чи фармацевтики в декілька разів (при усіх оборотах, там не треба так багато інжененрії як для військової справи), то глобально усі замислились і почали приймати міри. З великою долею верогідності С++ наступних стандартів буде підтягнуто повністю під крітерії Пентагону, бо так дешевше так зі зламом зворотної сумісності. З великою долею верогідності оператори delete та new [] будуть забрані з мови, як і std::malloc та std::free з бібліотеки, як і alloca і т.п. Modern код із інтелекутуальними вказівниками, std::array, std::vector, std::string і т.д. і т.п. буде працювати але на compile time рівні.
Зараз в списку Approved NSA/CISA : Java, C#, Python, JavaScript / TypeScript, Ruby, Go lang, Swift та Rust. Для legacy коду дозволені Ada та Object Pascal.

Відповісти
Підтримати
Paul Savchuck
Paul Savchuck Senior Software Engineer в EPAM 02.02.2026 21:45

О, я колись читав про ці нові стандарти, але за потоком новин повністю все випало з голови. Тепер дійсно звучить логічно, дякую )

Відповісти
Підтримати
Vic
Dmytro Bondarenko 02.02.2026 14:22

Таке собі, вигадування ще одної МП замість того, аби впилити це у с++, виглядає як «ще один фреймфорк розробимо бо у попреденьому ми не змогли кнопочкі зробити з ефеектом паралакса».

Чуваки розробили щось, що місцями навіть трохи краще, але, як і з «ще один ефективний парсер JSON» помирає, коли виходить новий .net з покращеним перформансом на 30% у сістемтекст.

Відповісти
Підтримати
Andrey Lapshov 03.02.2026 20:23

В кінці року гугль обіцяє реліз для якогось карбону.
І всі ті чуваки та їх проекти, що останні 10 років на раст переходили, їм начальника скаже — усе, сперделіваем раст, вчимо з 0 нову вундервафлю/вбивцю цпп.

П.С. Особисто проти раста нічого не маю, мова і концепції цікаві.

Відповісти
Підтримати
Dmytro Bondarenko
flyman 05.02.2026 10:42

Карбон одобрило міністерство дефенса ЮеСЕйя?

Відповісти
Підтримати
Andrey Lapshov
Andrey Lapshov 05.02.2026 11:24

Так ще релізу не було, в кінці року тільки 0.1 версія очікуєтся.
До того ж мені ЮС вояки не показник, я за ідею.

Відповісти
Підтримати
flyman
Alex 02.02.2026 13:26
В результаті замість 160 000 рядків C++ (без тестів) вийшло отримати 90 000 рядків Rust (з тестами)

Але розмір скомпільованого бінаря збільшився у 2 рази

Відповісти
Підтримати
Vic Programmer 02.02.2026 13:37

Та як завжди бібліотеки із залежностями лежали десь в діректорії contrib, щоби не використовувати пакетний менеджер і скомпілювати усе із -mtune=native чи взагалі LTO опціями і гарантовано одним розподілювачем пам’яті і усе статично.
А в Rust просто усі залежності підєднали через Cargo і одразу мінус тисячі строк коду.
Ну а бінарного коду, якщо звістно не один загальний unsafe — у Rust буде більше, принаймні на 20%.

Відповісти
Підтримати
Alex
Vitaliy Kaplenko C++ DataBase Developer 02.02.2026 12:54

Так, зменшення кількості рядків wamedia після переписування з С++ на Rust вражає, але чомусь нічого не було сказано про зміну performance wamedia після переписування з С++ на Rust.

Rust дуже гарно себе показує у переписуванні кода написанного на C/C++, але це чомусь не поширюється на проєкти написані на Rust from scratch.

Наприклад, Rust Servo Project:
...
Development of Servo began at the Mozilla Corporation in 2012.
...
In August 2020, Mozilla laid off the Servo team. Governance of the Servo project was thus transferred to Linux Foundation Europe.

Відповісти
Підтримати
Denys Poltorak Embedded | C++ (opentowork) 02.02.2026 13:09
це чомусь не поширюється на проєкти написані на Rust from scratch.

Бо на ньому незручно прототипувати mdwdotla.medium.com/...​tionary-tale-42ab823d9454

Відповісти
Підтримати
Vitaliy Kaplenko
зайшов почитати що тут пише 02.02.2026 13:10

але й нема відповіді на те, чи справді новий «перевірятор» повторював архітектуру колишнього?

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

Цитата «Rather than an incremental rewrite, we developed the Rust version of wamedia in parallel with the original C++ version.», тобто це може бути продукт з тією ж назвою й що робить то само, але іншим (ефективнішим) способом, відповідно й рядків й поменшало...

Відповісти
Підтримати
Vitaliy Kaplenko
Andrii Sevastianov Senior Developer в TeamDev 02.02.2026 13:56
Rust дуже гарно себе показує у переписуванні кода написанного на C/C++

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

Відповісти
Підтримати
Vitaliy Kaplenko
зайшов почитати що тут пише 03.02.2026 23:28
second-system effect

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

Відповісти
Підтримати
flyman
yvs2014 04.02.2026 00:16
дуже гарно себе показує у переписуванні кода написанного на C/C++

Відносно сі твердження принаймні дискусійне. Наприклад coreutils-uutils, який більш напевно ніж з десяток років переписують і ще досі в процесі. А які наявні приклади з сі малися на увазі? (плюси поза скобками бо то мп яка достатньо відрізняється щоб не скидати все в одну купу)

Відповісти
Підтримати
Vitaliy Kaplenko
yvs2014 04.02.2026 01:06

І що це має сказати? У ядра своя унікальна специфіка, і що раст починають потрохи там юзати — не каже нічого про «дуже гарно себе показує у переписуванні кода», навіть і без специфіки, і без того як впровадження там якось не дуже легко виглядає.

Взагалі кажучи з таким інтенсивним промошен н̶ь̶ю̶-̶д̶ж̶а̶в̶а̶ раст вже повинен був бути everywhere значно більше ніж є. І ті варіанти звичайного сі софту які зустрічалися — то точніше мабуть щось ближче до «зі скрипом» ніж «дуже гарно».

Відповісти
Підтримати
Vitaliy Kaplenko
flyman 05.02.2026 10:44

навіщо переписувати, якщо можна нове додавати, а щось старе «пожовкне і само відпаде»

Відповісти
Підтримати
yvs2014
yvs2014 05.02.2026 14:55
навіщо ...

яка глибина, яка широта, конгеніально, — одним словом ще якась одна рандомна ретро фраза в стилі к-тм -ня

пожовкне і само відпаде

генератору одноречень:
по раст контексту читається як — поржавіє)

Відповісти
Підтримати
flyman

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.