Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Справжні вбивці С++

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

Всім привіт! Я Саша Каленюк. Останні сім років я працюю на компанію Матеріалайз, де ми разом із командою алгоритмістів пишемо крутезну біблотеку для 3D-друку. В цілому, переважно на С++ я пишу вже майже сімнадцять років і майже сімнадцять років намагаюсь позбутися цієї шкідливої звички.

Все почалося у 2005 році з рушія для космічного симулятора. Було в цьому рушієві все, що в 2005 році було в С++. І асемблерні вставки, і тризірковий код, і вісім шарів наслідування. Макроси ще були. Ітератори усюди, як заповідав Степанов, і метакод, як навчав Алекснадреску. Все було. Не було тільки відповіді на найголовніше питання: навіщо туди все це напхали?

Втім, згодом навіть і на це питаня відповідь знайшлася. Виявилось, що код цей до мене писали вже вісім років. І п’ять різних команд. Кожна нова команда заходила на проект, обкладала матюками попередників, брала за основу свіжу моду в світі С++ і загортала попередній код у новий, додаючи при тому не більше ніж 10-20 мілікармаків функціоналу.

Спершу я намагався якось розібратися в усьому тому зоопарку, робив якісь таски, щось правив. В принципі, якось косо-криво, але виходило. А потім мене спитали: «Не хочеш попереписувати шейдерний код з асемблера на GLSL?» Я подумав, чорт його знає, що то за GLSL, але гірше за С++ не буде, і сказав, що хочу. Гірше не стало.

Так і повелося. Щоразу, як треба було щось написати не на плюсах, я казав, що хочу, і писав. Писав на чистому Сі, на MASM32, на C#, на PHP, Delphi, ActionScript, JavaScript, Erlang, Python, Haskell, D, Rust, навіть для InstallShield якісь скрипти писав. I на VisualBasic для екселя, і на bash, а на додачу і ще на декількох пропрієтарних мовах, про які навіть розповідати не можу. Навіть колись було діло, робив власну мову для скриптування 2D-квестів, хоча фактично саму граматику створював гейм-дизайнер, я просто перетворював його забаганки на робочий продукт.

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

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

В двадцятому сторіччі як було? Маєш ідею, загортаєш її у юайку, продаєш як десктопний продукт. Продукт лагає — не страшно, за два роки коп’ютери підростуть, тоді не лагатиме. Головне — якнайшвидше вийти на ринок, наробити фічей і бажано одразу без багів. І отут так, якщо компілятор не дає програмістам наробити багів — то це, очевидно, дуже круто і економічно вигідно, бо інакше ти платиш програмістам за час, який вони витрачають на баги замість фічей.

Тепер не так. Маєш ідею — загортаєш її в апішку і підіймаєш в клауді. Тобі платять не за диск із програмою, а тільки за корисну роботу, яку вона робить. А за те, що в тебе щось лагає, тепер платить не умовний Гордон Мур зі своїм легислативним аппаратом, а ти сам. Буквально сплачуєш рахунки умовному амазону за власну безумовну неефективність.

І раптом виявляється, що жоден вбивця С++, навіть ті, які я щиро люблю і поважаю, на кшалт D, Rust, і Julia, не допомагає вирішити головну проблему двадцать першого сторіччя. Вони не допомагають тобі писати швидкий і економний код. Ну, принаймні код швидший і економніший, ніж на С++. Вони всі занадто однакові, щоб давати якісь суттєві переваги одне перед одним. Rust, Julia, Clang навіть використовують один і той самий бекенд. Не можна виграти автоперегони, якщо їдеш до фінішу тим самим автобусом, що і решта учасників.

А в нашому з вами спільному становищі, економний код — це не тільки менші рахунки, а ще і менші відчислення на російську воєнщину. Бо чиїм газом харчуються станції, що живлять датацентри в Дюсельдорфі і Франкфурті, ми ж всі розуміємо.

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

Вбивця 1. Spiral

Давайте перевіримо, як працює ваша інтуіція. Що працює швидше, стандартна функція сінуса чи його поліноміальна модель?

auto y = std::sin(x);
 
// vs.
 
y = -0.000182690409228785*x*x*x*x*x*x*x
	+0.00830460224186793*x*x*x*x*x
	-0.166651012143690*x*x*x
	+x;

Друге питання, що швидше: використувати стандартні логічні операції для порівняння з однобітним значенням чи піти на переступ і забабахати арифметичну мікрооптимізацію?

if (xs[i] == 1 && xs[i+1] == 1 && xs[i+2] == 1 && xs[i+3] == 1)
 
// vs.
 
inline int sq(int x) {
  return x*x;
}
 
if(sq(xs[i] - 1) + sq(xs[i+1] - 1) + sq(xs[i+2] - 1) + sq(xs[i+3] - 1) == 0)

Ну і наостанок, що краще для сортування триплетів даблів: своп-сорт чи індекс-сорт?

if(s[0] > s[1])
  	swap(s[0], s[1]);
	if(s[1] > s[2])
  	swap(s[1], s[2]);
	if(s[0] > s[1])
  	swap(s[0], s[1]);
 
// vs.
 
	const auto a = s[0];
	const auto b = s[1];
	const auto c = s[2];
	s[int(a > b) + int(a > c)] = a;
	s[int(b >= a) + int(b > c)] = b;
	s[int(c >= a) + int(c >= b)] = c;

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

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

У випадку першого питання, поліноміальна модель працює в три рази швидше за стандартний синус, якщо запускати її на Intel® Core™ i7-9700F CPU @ 3.00GHz; і збирати компілятором clang 11, із флагами -O2 -std=c++14 -march=native.

Але якщо її же запускати на GeForce GTX 1050 Ti Mobile збираючи nvcc з флагом —use_fast_math, то стандартний синус буде в десять разів швидшим за модель! Модель, звісно, можна значно пришвидшити: позбутися даблів і завернути схемою Горнера, але навіть так беззаперечної переваги над стандартним синусом не отримати.

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

І третє — так само. На Інтелі в три рази швидше індекс-сорт, на Джі-форсі — теж в три рази, але своп-сорт.

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

У першому прикладі компілятор не тільки не знає, що вказаний поліном має наближувати синус, а навіть не знає, чи дозволяється нам та втрата точності, яка йде довіском з таким наближенням. У С++ немає способу розслабити вимоги до точності, окрім як флагом на кшалт —use_vsrata_math і то на рівні об’єкту трансляції, і то без жодної конкретики.

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

У третьому прикладі компілятор міг би здогадатися підставити вигідне сортування, так, насправді, std::sort теж знає, коли використовувати мердж-сорт, а коли квік. Але обидва рішення розписані сильно детально, аби компілятор міг розпізнати їх як сортувалки.

І тут ми підходимо до Spiral. Це спільний проєкт університету Карнегі Мелон і Федеральної вищої технічноїї школи Цюріха. Якщо в двох реченнях: спеціалістів з обробки цифрових сигналів задовбало переоптимізовувати вручну свої улюблені алгоритми на кожну нову залізяку, тож вони написали програму, яка робить цю марудну роботу за них. Програма приймає на вхід високорівневий опис алгоритма і, що важливо, детальний опис архітектури залізяки, під яку їй треба оптимізовувати, і оптимізовує.

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

Spiral — проєкт дослідницький, обмежений за бюджетом і за напрямком діяльності. Але результати показує вражаючі. Так, на швидкому перетворені Фур’є, їхнє оптимізоване рішення більш ніж в два рази обганяє і версію MKL, і FFTW. На Інтелі. Щоб було легше сприймати масштаб перемоги MKL — це Math Kernel Library від самого Intel, тобто від компанії, яка найкраще в світі знається на мікрооптимізаціях під власну архітектуру. А FFTW, яку ще часто розшифровують як «Fastest Fourier Transform in the West», — вузкоспеціалізована бібліотека від людей, які найкраще в світі знаються саме на перетворенні Фур’є.

Коли технологію остаточно комерціалізують, постраждає не тільки С++, а і Rust, і Julia. Навіть шановному професорові Фортранові стане непереливки. Навіщо потрібен С++, якщо можна створювати алгоримти мовою високого рівня, а працюватимуть вони в два рази швидше, ніж якби вони були написані на С++?

Вбивця 2. Numba

Найкраща в світі мова — це мова, яку ти вже знаєш. Доволі довго цією мовою для більшості програмістів у всествіті була Сі. Що, до речі, пояснює, чому багато років поспіль Сі очолював індекс TIOBE за популярністю, а разом з ним в п’ятірці лідерів тусувалися сіподібні С#, Java і С++. Але минулого року сталося нечуване! Сі скинули з п’єдестала.

Мовою-вискочкою, мовою-іконокластом став Python, або «Пітон» українською. Він нарощував свою популярність декадами, повільно, але безупинно. Ставав мовою року у 2007, 2010, 2018, 2020 і 2021 роках. Для порівняння: С++ була мовою року за версією TIOBE у 2003 році, і все. Це був її перший і останній раз.

«Але ж Пітон повільний!», — скажете ви, і будете термінологічно неправі. Мова не може бути повільною, як не може бути повільним, наприклад, баян. Як швидкість баяна залежить від того, хто на ньому грає, так і «швидкість мови» залежить від ефективності компілятора.

«Але ж Пітон не компілює!», — заперечите ви, і знову сядете у калюжу. Я і не казав, що компілювати має саме Пітон. Дозвольте проілюструвати.

Був у мене проєкт. Алгоритм симуляції 3D-друку, який ми написали спершу на Пітоні, потім переписали на С++, бо «Пітон же повільний», потім портували на GPU, а потім підключився я і місяць займався тільки тим, що налаштовував білд під Лінукс, валідував непітонівські імплементації пітонівською, мікрооптимізовував код під Tesla M60, бо з того, що надавав клауд-провайдер, саме у цій картці було найліпше співвідношення ціни аренди і швидкодії. Коротше, займався всім чим завгодно, але не власне алгоритмом.

А трохи згодом дзвонить мені студент, якого у нас в Бремені взяли на підробіток, і питає: «Кажуть, ти знаєшся на гетерогенщині, допоможи експериментальний алгоритм на GPU розпаралелити?». Ха! Ну я йому почав розказувати за CUDA, за CMake, за білд на Лінукс, за тести, за оптимізацію, розказував ледь не довше, ніж розбирався. Він вислухав дуже ввічливо всю цю ахінею, німець все-таки, хоча сам з Непалу, але наприкінці спитав: «Це все дуже цікаво, дякую, але я от в Пітоні перед функцією пишу @cuda.jit, а воно мені щось про масиви каже і не заводиться. Що то може бути?».

Я не підказав. Не знав. Втім, він сам розібрався, виявилось, що він замість масивів NumPy передав штатні пітонівські листи, а Numba з ними дійсно не заводиться. Розібрався і за кілька днів розпаралелив свій алгоритм. Під GPU. На Пітоні. Хочеш запускати на Лінуксі — будь ласка! Хочеш валідувати пітонівською імплементацією — так це вона і є! Хочеш оптимізувати під M60 — Numba збере код найоптимальніше саме під ту архітектуру, на якій запускатиметься алгоритм, бо в неї Just-in-time компілятор.

Отакої! Виявляється, що я, старий хрест-хрестоносець, згаяв місяць часу незрозуміло на що, а студент-пітоніст зробив мій обсяг работи за два-три дні. І тільки тому не за півгодини, що в перший раз паралелив із Numba. Та що ж то за Numba така? У чому магія?

Жодної магії. Просто пітонівські декоратори перетворюють будь-який пітонівський код на абстратне синтаксичне дерево. Що хочеш з тим деревом — те і роби. Numba — це така пітонівська бібліотека, яка хоче компілювати твій код будь-яким бекендом і під будь-яку платформу. Хочеш масивного паралелизму на інтелівському CPU — всі принади LLVM в твоєму розпоряджені. Хочеш того самого на нвідійвській GPU — будь-ласка, Numba вміє в CUDA.

@cuda.jit
def matmul(A, B, C):
	"""Perform square matrix multiplication of C = A * B."""
	i, j = cuda.grid(2)
	if i < C.shape[0] and j < C.shape[1]:
    	tmp = 0.
    	for k in range(A.shape[1]):
        	tmp += A[i, k] * B[k, j]
    	C[i, j] = tmp

От саме ця штука і здійснює компіляцію. Так, в теорії обігнати Numbою С++ не вийде, теоретична швидкодія в них однакова. Однаковий же бекенд. Але на практиці переваги JIT-компіляції все-таки себе показують. Був у нас випадок, коли, наприклад, ми переписували алгоритм із Пітона на С++ заради швидкості, а він став в три рази повільнішим, тому що через деяких конкретних клієнтів ми змушені були підтримувати бінарні релізи бібліотеки із допотопним SSE2.

Звісно, добре було б мати гарантовану перевагу, як у випадку Spiral. Але то все-таки ще дослідницький проєкт, його слава ще не настала. А Пітон разом із Numba досить впевнено, хоча і повільно, вбиває С++ прямо зараз, в режимі реального часу. Бо якщо ти можеш писати на Пітоні і мати швидкодію С++, то навіщо тобі С++?

Вбивця 3. ForwardCom

Давайте влаштуємо ще одну вікторину. Перед вами три фрагменти коду. Який з них, чи може які з них, написані на асемблері?

1.

invoke RegisterClassEx, addr wc    	; register our window class
    invoke CreateWindowEx,NULL,
    	ADDR ClassName, ADDR AppName,\
    	WS_OVERLAPPEDWINDOW,\
    	CW_USEDEFAULT, CW_USEDEFAULT,\
    	CW_USEDEFAULT, CW_USEDEFAULT,\
    	NULL, NULL, hInst, NULL
	mov   hwnd,eax
	invoke ShowWindow, hwnd,CmdShow    	; display our window on desktop
    invoke UpdateWindow, hwnd          	; refresh the client area
 
	.while TRUE                        	; Enter message loop
                invoke GetMessage, ADDR msg,NULL,0,0
            	.break .if (!eax)
            	invoke TranslateMessage, ADDR msg
            	invoke DispatchMessage, ADDR msg
   .endw

2.

(module
  (func $add (param $lhs i32) (param $rhs i32) (result i32)
	get_local $lhs
	get_local $rhs
	i32.add)
  (export "add" (func $add))
)

3.

v0 = my_vector          	// we want the horizontal sum of this
int64 r0 = get_len ( v0 )
int64 r0 = round_u2 ( r0 )
float v0 = set_len ( r0 , v0 )
while ( uint64 r0 > 4) {
    	uint64 r0 >>= 1
    	float v1 = shift_reduce ( r0 , v0 )
    	float v0 = v1 + v0
}

Якщо ви відповіли, що всі три, вітаю! Ваша інтуіція значно покращилась!

Перший написаний на MASM32. Це макроасемблер із «іфами» і «вайлами», на якому пишуться нативні програми для Windows. Так, навіть не «писалися», а «пишуться». Micosoft дуже шанобливо ставиться до зворотної сумісності, і програми, написані під Win32 API, прекрасно почуваються на сучасних машинах.

Це навіть дещо іронічно. Сі створювався через потребу переносити код UNIX із PDP-7 на PDP-11. Це була мова, яка мала б стати портабельним асемблером, здатним пережити бурхливий розвиток комп’ютерної архітектури семидесятих. Але в двадцять першому сторіччі цей розвиток настільки сповільнився і видохся, що програми на MASM32, які я писав ще на першій роботі, прекрасно збираються і працюють по сьогодні, а от впевненості, що бібліотека, яка ще в минулому році збиралася із CMake 3.18, збереться без жодної запинки із CMake 3.23, в мене ніколи немає.

Другий фрагмент — це Web Assembly. Це навіть не макроасемблер, себто жодних «іфів» і «вайлів» в ньому немає, а радше людиночитабельний код для віртуалної машини всередині вашого браузера. Або навіть не вашого. Будь-якого бразуера.

Тобто код на Web Assembly в принципі не залежить від архітектури вашої залізяки. Цей код абстракний, універсальний, всеядний, називайте як хочете.

Третій фрагмент — найцікавіший. Це ForwardCom — пропозиція асемблера, яку висунув Агнер Фог, вельмивідомий автор мануалів з оптимізації як програм на С++, так і асемблерного коду.

Як із Wasm, wе теж пропозиція навіть не стільки асемблера, скільки універсального набору інструкцій, створеного, аби уможливити навіть не зворотню, а попередню сумісність. Справжнє ім’я ForwardCom — an open forward-compatible instruction set architecture. Іншими словами, це пропозиція мирного договору.

Всі ми знаємо, що найпоширеніші архітектури: x64, ARM і RISC-V мають різні набори інструкцій. Але ніхто не знає гідної причини, чому це так має лишатися. Бо всі сучасні процесори, за винятком, можливо, найпростіших для мікроконтролерів, виконують не код, який їм дають програмісти, а мікрокод, який вони самі видобувають із запропонованого потоку інструкцій. Іншими словами, не тільки M1, а кожен процесор має транслюючий шар для зворотньої сумісності.

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

От із цим шаром — не застаріє.

Ще розвиток програмування на асемблері стримує міф про те, що це дуже складно і через те — непотрібно. Знову таки, пропозиція Фога адресує і цю проблему. Якщо люди вважають, що на асемблері писати складно, а на Сі чомусь легко, хай асемблер буде схожий на Сі. Жодних проблем. Немає жодної поважної причини, з якої сучасний асебмлер мав би виглядати так само, як його прадід в п’ятидесятих.

Ви тільки що самі бачили три зразка асемблера. Жоден з них на «класичний» асемблер не схожий, і не має бути схожий.

Отже, ForwardCom — це асемблер, на якому можна писати теоретично оптимальний нестаріючий код, і який не змушує програміста вчити асемблер в «класичному» розумінні. Тільки машинну архітектуру. У всіх сенсах, це Сі, такий яким він мав би бути.

Якщо вам не вистачає Сі, і хочеться інкапсуляції, наслідування, поліморфізму, ця свята трійця імплементована на TASM, починаючи з четвертої версії. Статичного поліморфізму хочеться — знову таки, типова задача для макроасемблера. Якщо є набор інструкції, прикрутити туди якусь макросистему — справа не архіскладна.

І якщо все це можна мати без С++, то навіщо тоді С++? Хіба що, щоб було, коли шпілите у футбол, поки проєкт білдиться.

Отже, коли все-таки здохне С++

Ми живемо в постмодернову епоху. Ніщо не вмирає, окрім людей. Як не вмерла латина, або не помер COBOL, так і С++ приречена на довічне існування між життям і смертю. С++ остаточно ніколи не здохне, нові технології просто витискатимуть її із мейнстрима на маргінес. Хоча чому власне «витискатимуть»? «Витискають».

Вже зараз моя робота як програміста на С++ починається з Пітона. Я складаю рівняння в SymPy, він їх символьно розв’язує і перетворює на код. Потім я вставляю нагенерований код в С++ навіть не фоматуючи, бо форматом опікується clang-tidy. Потім компіяція, потім тести, потім профайлінг. Останні оптимізації, як данстист під мікроскопом, я роблю не тільки під тестами, а і під дізасемблером, бо інакше доводиться забагато чого вгадувати, а це шкідливо для фантазії.

Якщо поміняти С++ на «не С++», робота моя на 80% лишиться такою самою. Тож може С++ вже на 80% помер?

👍ПодобаєтьсяСподобалось56
До обраногоВ обраному8
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

усі три різні тули «убивці» намагаються «замістити» різні астекти C++ які вирішуються на самому С++...

Вбивця 1. Spiral

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

Вбивця 2. Numba

ем... і як запустити Numba наприклад на... Ардуінці (так, Ардуінка, це також С++!)

Вбивця 3. ForwardCom

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

-------------------------

в статті нема відповіді «нащо вбивати С++»?
тут, звісно, хтось закине всі оті посилання на «авторитетів», там де матюки Лінуса, та інші приколи, або, навіть на творіння yosefk під назкою «C++ FQA Lite», що було актуально років 10-20 тому (і років 10-20 тому це все вже можна було обійти) але конструктивного обгрунтування «тула X замінить весь C++ та не буде складніше за С++» так і нема... лише «така то тула може замінити такий то аспект С++ в такому то юзкейсі»...

Бачиш сурка ?
Ні.
А він є...

От так і з вашими «вбивцями C++ ».
І одна справп, коли про якийс Раст розповідають, там хоч якийсь відсоток на ринку є. А ось ці всі ваші спірали...

C# справжній вбивця С++. Assembly vs C++ dll це години дні і тижні зеконмленого часу.

Как убить С++? Ответ — никак. Все кандидаты его убить это или кривые клоны С# или не имеют достаточной корпоративной обвязки или кодовой базы или все сразу. Попробуйте написать что-то коммерческое на D-lang, будет или наслоение велосипедов потому что нужна библиотека Х — а на ди ее нет или наслоение импортов в среду ди потому что мы ее таки прицепим и будет проект франкиншейник который и на ди и не на ди.

C++20 — кто уже работает, как он после С++17?

ті ж яйця, а що мало статися?

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

якщо чесно, то навіть не цікавився, там кожних 3 роки новий стандарт — убивця попереднього

Если нужна скорость, то используй float и GPU, управление и ввод-вывод на чем-то низкоуровневом типа C#/Java. Все остальное — это припарки для дедушки в гробу.

на чем-то низкоуровневом типа C#/Java

xixi

Ладно это меня уже глючит, но по сравнению с JavaScript/TypeScript, на которых сейчас пишет большинство новых разработчиков,- C#/Java уже низкоуровневые.

Могу с вами не согласиться по поводу джаваскрипт.https://www.youtube.com/watch?v=i6WKne5Pvao&t=1788s

Если вы по поводу скорости, то перекомпилировав через WebAssembly можно достичь аналогичной производительности, но работать с тем же CUDA или OpenCL проще с C#/Java чем с JavaScript.

Я имел ввиду стек технологий, одна из которых джс, С куда можно еще и с раста работать habr.com/ru/post/447968
Почему проще?

Справжній вбивця С++ — це С— , очевидно ж. :-))

мінус на мінус, виходить плюс

Я исходил из того, что С++ + С— = 0 :-)

тоді анігілятор, якщо вбивця то труп буде, а так нєт тєла, нєт дєла

Хлопцы главное уразуметь, шё многопоточность и многозадачность это разные вещи.Многозадачность (multitasking) — свойство операционной системы или среды выполнения обеспечивать возможность параллельной (или псевдопараллельной) обработки нескольких задач. Многопоточность (multithreading) — свойство платформы (например, операционной системы, виртуальной машины и т. д.) или приложения, состоящее в том, что процесс, порождённый в операционной системе, может состоять из нескольких потоков, выполняющихся «параллельно», то есть как бы без предписанного порядка во их выполнения в единицу времени. При выполнении некоторых задач такое разделение может значительно повысить эффективного использования вычислительных ресурсов системы. По-настоящему параллельное выполнение задач возможно только в многопроцессорной системе, потому что только в них присутствуют несколько системных конвейеров для исполнения команд. Так нам в универе на 122-ой рассказывают. В однопроцессорной многозадачной системе например ноде джс,поддерживается так называемое псевдопараллельное исполнение, при котором создается видимость параллельной работы нескольких процессов. В таких системах, однако, процессы выполняются последовательно, занимая малые кванты процессорного времени. Так ше цешка пока еще какое то время будет держаться...Хотя Раст мне больше нравиться, только на нем не все пока разрешают сдавать, а на цешке принимают все!!!

По-настоящему параллельное выполнение задач возможно только в многопроцессорной системе, потому что только в них присутствуют несколько системных конвейеров для исполнения команд. Так нам в универе на 122-ой рассказывают.

Это в каком именно универе так ограниченно рассказывают?
Во-первых, там ещё есть и расширения в обе стороны (есть кооперативная многозадачность, есть корутины, а есть многоузловые системы), так и промежуточные (многоядерность как мягкий вариант многопроцессорности, или гипертрединг).
А во-вторых, во многих применениях вы в принципе не увидите ни в чём кроме скорости, какой из вариантов применён. Ну разве что на разных узлах не получится на общей памяти работать, потребуется MPI или аналог.

В остальном вы пока что изложили более-менее банальности. Это хорошо, что им учат, но плохо, что слишком ограниченно.

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

С++ вбили вже? Чи ще нє? Руст нада починати вчити, чи можна залишитись тру?

Не вбили
Читати міжна і нужно
Не тільки руст
А будь які інші мови програмування

просто с английского когда переходишь, оно как то автоматом получается писать такое...

На английском, на украинском и на русском оно произносится одинаково.

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

якщо передпенсійного віку, то можна досидіти на цепепе до пенсяшки

Раст це вже не модно.
Автор каже, якийсь чувак з Непалу йому про якийсь спірал розповів, от він новий «вбивця».

Раст, хлопцы,это почти таже цешка, только без богажа обратной совместимости...

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

Ось про який! Большинство изменений, одобренных на сегодня для C2x, — это не новые функции, а уточнения и усовершенствования особенностей поведения Си в различных реализациях. Назначение приоритета доработкам — это уже традиция: аналогичным образом происходило развитие ревизии C11 и последней на сегодня редакции стандарта, C17.Согласно описанию C2x, при дальнейшей разработке Си планируется делать строгий акцент на сохранении совместимости с существующим написанным кодом на этом языке, а также избегать «тихих» изменений — таких, которые меняют поведение программы, написанной на Си прежних версий. Если такое изменение все же необходимо, это должно быть явно указано в стандарте.

cor3ntin.github.io/posts/abi

Касательно самого языка — например, возможность не инициализировать локальные переменные и UB при обращении к ним. Какого, прошу прощения, хрена нам приходится в 2022 году жить с этой проблемой?

Ты согласен с тем, что в корректной программе на C перед тем, как из переменной считывается значение, в нее сначала должно быть записано значение?

Ясно, что если пишется, то норм, но вопрос в том, что если именно считывается.

Вопрос не в том, что кто-то что-то может задетектить, а в том, что в нормальном современном языке не должно быть возможности триггерить UB настолько банально, и в C/C++ эта возможность существует не потому, что это что-то хорошее, а для совместимости со старыми вирусами.

Аргумент про «лишние инструкции» существовал в 80-м году, когда запилить компилятор, который может оптмизировать избыточные записи в переменную было сложнее, чем слетать на Луну, но сейчас утратил свою актуальность.

А если не хочешь лишние инструкции процессора тратить то нафиг инитить

А переменную надо инитить перед завершением скоупа/программы?

не обязательно

Хорошо :-) но иногда обязательно. Совсем редко :-)

Будущее за OOП интерфейсными абстракциями с логическим ядром под функциональное программирование.

Для меня справжним вбивцей С++ стал C#. Помню примерно в 2008 году я считал .net стремной какой-то темой и в споре с одногруппником сказал что это какое-то мутное дерьмо, с виртуальной машиной похожей на говноджаву, которая очень медленно работает. Помню одногрупник предложил для эксперимента чтобы я написал на С++ дексктоп приложение (MFC) которое просто грузит какую-то таблицу из базы данных в Listview и он тоже самое сделал на .Net (win forms). Оно как минимум работало не медленнее С++. Так как я был настроен на такого рода говноприложения, которые грузят какое-то говно из базы данных в формошленутые Listview, в тот момент я понял что С++ для меня вбито.

Еще в те года я писал курсовую на джаве, это было говноприложение (десктоп), которое грузило какое-то говно из базы данных (обычный CRUD). У меня был комп с ОЗУ 256 МБ и это говноприложение на джаве съедало половину этого озу. Потом я переписывал ее на MFC. В то время я еще не знал что на .NET все это говно можно написать за пару недель

говноджаву
говноприложения
говно
говноприложение
говно

Мне кажется, вы выбрали неправильную профессию.

Ну что ж, сделаю такие же поспешные выводы: мне кажется что вы пишете десктоп приложения на говноджаве

Мне кажется, вы выбрали неправильную профессию.

Либо ты сам, из всего текста выцепил слово «говно» :-) я в сообщении увидел только смысл, а говно заметил только изза тебя

я в сообщении увидел только смысл, а говно заметил только изза тебя

Многие люди читают невнимательно и такие вещи не замечают.

забув

в тот момент я понял что Java для меня вбито.

Да, именно. Но вот кстати сейчас прохожу на курсере алгоритмы по Седжвику и опять пришлось возрождать покойника, т.к там все примеры и упражнения на Java. Сама Java почти тот же C#, но весь этот енвайромент, виртуальная машина все какое-то медленное. Консольное приложение на 10 строчек кода в IntelliJ секунд 10 открывается. Не представляю что там будет происходить с проектом на сотни файлов

Не представляю что там будет происходить с проектом на сотни файлов

Будет открываться секунд 15-20. Чем больше проект, тем меньше будет относительное время открытия.
Это цена всей машины анализа проекта, и она имеет смысл.

Сама Java почти тот же C#, но весь этот енвайромент, виртуальная машина все какое-то медленное.

Нет разницы.

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

Помню одногрупник предложил для эксперимента чтобы я написал на С++ дексктоп приложение (MFC) которое просто грузит какую-то таблицу из базы данных в Listview и он тоже самое сделал на .Net (win forms).

Под MFC там что, listview из стандартных вендовых common controls? Ну тогда разница очень хорошо будет заметна в пользу .Net. А если сейчас сравнить дотнетовский listview и какую-нибудь реализацию под html5, то дот нет будет в полном пролёте.

А если сейчас сравнить дотнетовский listview и какую-нибудь реализацию под html5

imgur.com/a/iri2VMA

Если берешь какую-то 3d party реализацию ListView под HTML5 (а встроенного в HTML ничего нет), то сравнивай с 3d-party реализацией ListView под .NET

В любом случае listview написанный под winapi будет в пролёте из-за огромного количества кода, который нужно написать на С++ для любой новой фичи. А MFC и js-фреймвёрки даже сравнивать неуместно по удобству и возможностям для UI.

Winapi это технология 90-х годов, JS UI это технология 2010-х годов. Сравниваешь **й с пальцем, прошу прощения. Сравнивай современные инструменты разработки под Windows, как тот же WPF — там не все так однозначно. Скачай, например, WPF демки Devexpress/Teletik.

Сравнивай современные инструменты разработки под Windows

Когда MS зафейлила платформу Windows Phone вообще в ноль, а мой тим с разработкой под эту платформу в 2015 — разогнали, я решил больше не связываться с подобными авантюрами. Кстати, разработчикам предложили свичнуться на adobe flash, и часть из них так и поступили.

Adobe flash, я думал, его лет 15 как похоронили.

Только пару лет назад, как известно. Там ещё до последнего переходили с AS2 на AS3.

і куди тепер мігрували мігрувальники?
так для інфи, куди не варто

Да, стандартный. Помню что по умолчанию он все данные грузил в сам контрол, но там был еще virtual mode с помощью которого данные можно было хранить в отдельной структуре а чтобы листвью только отображал и так оно работает гораздо быстрей. Идея была сравнить стандартные контролы без каких-то оптимизаций. Вообще со всякими листвью, которые грузят кучу данных много всяких велосипедов можно придумать. Помню как любой уважающий себя начинающий программист, задался я целью написать свою операционную систему свой Тотал Командер на .net (кстати Тотал Командер написан на ДелЬфи и при этом он гораздо быстрей грузит содержимое папок чем быстродействующий эксплорер виндавс написанный скорей всего СиСи ПлюсПлюсе). Помню самый напряг с этими всеми листвью был в том что когда открываешь какую-то большую папку с кучей файлов (а в те времена такой папкой для меня была system32) то просто для того чтобы отрисовать все папки/файлы и значки требовалось около секунды. Вот так заходишь в папку system32 и UI виснет на 1 секунду. Я помню тогда какой-то интересный велосипед придумал, типа в листью грузилось только то что видно на экране +10 строк примерно. При этом скрол нужно было отрисовать такой как-будто бы в списке куча файлов. Для этого отдельно высчитывался размер скролла, а при скролинге высчитывалось что грузить в листвью. Стремная идея но работало все довольно быстро

Люди, котрые помнят такие слова как,
Dos navigator, total commander, far для ит уже динозавры, по vc я уже молчу.

До сих пор использую Total Commander под винду и Midnight Commander под линукс. ЧЯДНТ?

Я тоже до сих пор использую бесплатный аналог Unreal commander на виндавсе, который вроде как на сиси плюсплюс билдере написан. На самом деле спустя столько лет не понимаю как люди пользуются эксплорером. Я вроде не старовер, вот даже на новой работе в первые в жизни на мак перешёл (на котором и прохожу алгоритмы на джаве охуевая как все тормозит на макбуке про 2021 года с м1 процом), но без файлового менеджера жёсткий дискомфорт ощущаю

Midnight Commander

попробуй double commander
github.com/doublecmd/doublecmd
графический интерфейс, как тотал-коммандер, активно развивается
(mc яснопонятно он не отменяет, я обеими пользуюсь)

он гуишный, а mc консольный, можно запустить хоть из-под ссш

Так Артёмке надо гуй
Иначе б он под виндой поставил цигвин

Він у мене за замовчення завжди встановлюється на кожному новому компі ))

GUI под виндой, текстовый режим в консоли.

по vc я уже молчу

бгг
я пользовался nc
кто старше?

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

dos 3.1 з дискет на пошуці,

О так
Завантажитись з 3-4 дискет, що б погратись ))

хіба мавпи так довго живуть, щоб таке пам"ятати?

Так
Мені тоді було лише 8 років приблизно))

То ти вже на F.I.R.E.?
А твій програміст?

То ти вже на F.I.R.E.?

Ні
Тільки йду туди

А твій програміст?

У мене його нема(

Тільки йду туди

куди, в Африку пішки, там банани задармо

У мене його нема(

Вже нема? Ти його пережила? Чи він послав? Як прикро.

куди, в Африку пішки, там банани задармо

А це ідея

Вже нема? Ти його пережила? Чи він послав? Як прикро.

Він пішов мовчки!

от козел

Любофф зла — полюбиш і козла

то ти та мавпа, про яку кажуть:
«пішов ганяти мавпу»

перед тим ще якісь були ПК, але назв не пам"ятаю, ті взагалі із магнітофона протон вантажилися та касет Свєма

Электроника БК
БК — бытовой компьютер

игры грузились с кассет, на кассете было штук 30 игр (типа тетриса, гоночки)
половина правда не грузились потому что пленка была пожеванная магнитофоном

подключалось это все к телеку

А ти, бачу, старше за мавпу програміста.

Звісно
Якщо я мавпа, то у мене є хазяін програміст
А у нього є мати
=> коло замкнулося

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

то ви з одного ІР?

Ти мав на увазі дитячого садка? Так, з одного.

не горшка для пі-пі, ладно проїхали

Хочеш знайти нас по айпі? Що ми тобі зробили поганого?

от нема більше чим зайнятися, шукати мавп по ІР,
як там з мавп"чою віспою, не боїшся?

наверное да
Мавпа, тебе сорокет уже есть?

наверное да

Точно да

Мавпа, тебе сорокет уже есть?

Мне 36
Чувствую себя на 25
Что из этих двух чисел выбрать?

Мне 36
Чувствую себя на 25

поводжуся як в 5

поводжуся як в 5

Я хотів написати про тебе «на 10» спочатку, але ти мене випередив ))

you are welcome
приємно мати справу з мавпами що навчені етикету

you are welcome
приємно мати справу з мавпами що навчені етикету

4.bp.blogspot.com/...​YX54/s1600/like+a+sir.JPG

Что из этих двух чисел выбрать?

эт смотря куда на работу устраиваешься
если на укр. галеру — то 25

эт смотря куда на работу устраиваешься
если на укр. галеру — то 25

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

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

что не только возраст не пишут в резюмехе, а и пол, и не рекомендуют включать даже фотографию

можно и навыки не писать
нафих оно надо глупости какие

любите меня таким, какой я есть уникальный и особенный

можно и навыки не писать
нафих оно надо глупости какие

любите меня таким, какой я есть уникальный и особенный

Я фото не убирал
А пола и возраста всегда не было в моем резюме)

:p

про фото и прочее я такое только здесь на доу слышала

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

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

Ну вот это мне не нравится
Надо сначала по навыкам подбирать
А затем адаптировать под ситуацию нагрузку

Потому что можно меня не рассмотреть изза того что у меня ребенок, и взять другого бездетного, хотя я окажусь более гибким и буду лучше коммитить в репозиторий чисто за счет своего подхода «2ч утром, 5ч днем, 1ч перед сном и 5ч в выходные»

можно меня не рассмотреть изза того что у меня ребенок,

вот как раз тебя детного и возьмут, потому что немецкие HR в курсе что 2ч утром, 2 ч вечером, а ещё Elternzeit скорее всего уже отбыл, а ещё умеешь концентрироваться и ценишь лояльность работодателя, меньше риск зайчизма и переезда за новой любоффью куда нибудь в Тайланд

вот как раз тебя детного и возьмут, потому что немецкие HR в курсе что 2ч утром, 2 ч вечером, а ещё Elternzeit скорее всего уже отбыл, а ещё умеешь концентрироваться и ценишь лояльность работодателя, меньше риск зайчизма и переезда за новой любоффью куда нибудь в Тайланд

Странно! Я сейчас гораздо менее надежный чем до появления детишек.

Раньше я горел и комитил «наперёд», готовил-подстилал соломку в коде (тот самый аджайл), сейчас же намного чаще — как только 8 часов прошло (если цайт конто нулевой) — все, рабочий лаптоп сразу закрывается (строчки только допишу, что б не прерывать мысль и все).

Раньше я горел и комитил «наперёд», готовил-подстилал соломку в коде

идеальный кандидат работает средне, но стабильно и предсказуемо

предсказуемо желательно лет на 10, а
средне чтобы можно было зэпэ ему не повышать

идеальный кандидат работает средне, но стабильно и предсказуемо

предсказуемо желательно лет на 10, а
средне чтобы можно было зэпэ ему не повышать

Понятно, спасибо :)

меньше риск зайчизма

Хз, я и с мелким зайчую. Причем я 2 раза зайчую, ремоут выручает...
С мелким что сложно, уже не получается волонтерить
Я помню, как без семьи — нафакапил в разработке, в стратегии, понял что сделал не так — 1 ночь поволонтерил, переделал всё, изменил архитектуру — и следующие 3 недели лениво вожу мышкой, закрывая таски за 2 часа, потому что внутренний фреймверк теперь правильный API предлагает. А без волонтерства пока что коммитится говнокод ((

та ви що, не з одним і тим програмістом ?

то ти мама програміста на заводі? не на галерах?

то ти мама програміста на заводі? не на галерах?

CLAAS де вона працює це не тільки програмування

та не, я ж в хоум офисе
могу собрать бутерброд с колбасой

обєпєчтє тракторістов тракторамі!

половина правда не грузились потому что пленка была пожеванная магнитофоном

А её можно было пожевать так, что б поломать игру в нужном месте? Сделав чит, например

я пленку перематывала пару раз на другую кассету под натяжением

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

nc страшно гальмував порівняно з vc

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

Пока .net не вышел многие delphi или с++ билдер предпочитали для десктопа.

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

Якби Rust не був таким складним, вбив би C# та Джаву. Плюси не вб’є, там за багато років так звикли копирсатися в лайні, що їм не потрібна краща мова, ІМХО

Rust та C#/Java грають трохи у різних лігах, тому 100% заміни не буде

Можете привести пример «сложности» Rust, от которой можно было бы избавиться, не повредив языку?

С чого ви взяли, що я вважаю, що така є? Раст прекрасна мова, але складна, тому що вимушує думати про такі сценарії, про які у мовах з GC ніхто ніколи не думає

GC

Отож.
Ніяка мова без GC не може бути загрозою мові з GC

тому C#/Java — про Rust нічого не знають. Він — не цікавий як їх заміна.

І.
Ніяка мова з обов’зковою статичною типізацією не може бути загрозою мові з дінамічною типизацією.

Коли, наприклад, кажуть що TS вбивця JS — смішно.
Бо у складних випадках, як виключення, простіше поставити типом any, або // @ts-ignore
чим витрачати час за вмовляння систему типів.

Ну а коли треба множити мартиці на GPU — ну так, GC та дін типизація — не дають переваг у кодуванні, та ще й мають зайвий оверхед.

Ну я б сказав, що єдине, що заважає Расту вбити шарп чи джаву — це складність. Але це моя думка, звісно, а не факт :))

Якщо він не може свого прямого супротивника, С++, вбити, то куди йому до шарпа та джави

А заважає — відсутність GC.
Ну а потім так, складність. Маємо приклад Scala яка не змогла замінити Java

Бо він не супротивник плюсам, про це ж і стаття, бо там важкувато надрачувати мікрооптимізації по тактам, і інтегруватися з мегабайтами легасі хідерів.

А задачі для джава чі шарпу (веб АПІ, наприклад) на нього ложаться чудово, і отримуємо в результаті перформанс плюсів з девелопер екпірієнс шарпу (ну, майже), в чомусь навіть кращий і приємніший, завдяки потужній системі типів

веб АПІ, наприклад

чудово пишеться на PHP, Node js та Python. Та й на Go — коли є проблеми з навантеженням.
Навіть Джави с Шарпом частенько не потрібно, не матимуть переваг для — веб АПІ. Будуть корисні коли вибрається класичний підхід «моноліта» та маємо складну бізнеслогіку і високі вимоги до міцності її реалізації (міціність реалізації — це стійкість кодової бази до змін різними командами, різного проф рівня, в процесі еволюції системи. Самі вразливі до безвідповідальності — проекти на PHP. Він багато дозволяє — і без самодісциплини — тенденція «хуяк, ***к і в продакшн» буде найсильніша їз вказаних мов)

нафуя ж його писати на Rust???
Щоби що?
Які бенефіти для — розробки?

Сьогодні в новинах наприклад
Pros of Node.js
Cross-Platform Functionality
Shorten-Time-To- Market
Scalability

Pros of PHP
It Requires Less Maintenance
Relatively Cheap
User-Friendly

dzone.com/articles/node-js-vs-php

Які переваги по цих пунктах у Rust, коли їх немає навіть у Java/C#? У них звісно є переваги — по пунктах Cons of Node.js/PHP

перформанс плюсів

чат на мілліони активних користувачів?

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

це діло смаку. до об’єктивних властивостей для розробки ПЗ має дуже далеке відношення.

Це приблизно як з звичайними мовами.
Не так давно відомий Сєва Новгородцев «поглузував» з української мови — не уявляє підручника по квантовій фізиці українською — «погана мова!»

А комусь німецька не подобається.
Або чешська — смішна ж, чи не так?

Плюси Раста для веб апі чи подібних проектів:
— Швидкість (а це напряму кошти, якщо хостити у клауді)
— Передбачувано високий перформанс без пауз на джит-компіляцію і збір сміття
— Сама мова більш виразна, ніж Шарп і тим більше Джава, більш потужна система типів
— Макроси

Сьогодні в новинах наприклад
Pros of Node.js
Cross-Platform Functionality
Shorten-Time-To- Market
Scalability

Pros of PHP

Ви ж розумієте, що кількість людей, яка змогла в Ноду, незрівнянно більша, ніж тих, хто зміг в Раст. Ті новини треба читати як «Pros of Node.js — I know Node.JS only»

Швидкість

її і так достатньо для 99% проектів.
а тормозить у веб проектах — робота з БД

Передбачувано високий перформанс

не потрібно.
веб не реалтаймсистеми. 100 мс відповіді чи 500 мс — зазвичай не має значення.

Сама мова більш виразна,

це смаківшина. Читав у С++ яких поважаю — їм Rust виглядає жахливо і нееститчно.

ніж Шарп і тим більше Джава,

веб частіше пишется на Пітоні, PHP, JS та Go
і у всіх є — GC.
У Rust — немає.

більш потужна система типів

це академічна маячня.
Інженерія — не computer science.
А реальна розробка — частенько маэ недостатньо часу на проектування системі типів — а працюючий код повинно здавати вже в перших спрінтах.

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

Ви ж розумієте що переваги які ви навели — просто непотріб щоб переходити в веб проектах на Rust?

Я взагалі давно кажу — найкращі мова і інструменти на проекту ті — якими найкраще володіє команда.
Краще профі у Ноді чим нуби у Rust

Сумуючи ваші пункти — у Rust немає переваг, а от недоліки — чималі.

Ті новини треба читати як «Pros of Node.js — I know Node.JS only»

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

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

Передбачувано високий перформанс
не потрібно.

Потрібно, бо це напряму ті кошти, які платяться за клауд

це смаківшина. Читав у С++ яких поважаю — їм Rust виглядає жахливо і нееститчно.

Дякую, що коментуєте Раст, не знаючи його 😂

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

Ви ПХП розробник, вгадав?

Потрібно, бо це напряму ті кошти, які платяться за клауд

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

Звісно, бувають виключення. На мілліонах одночасних користувачах.
Тоді або Java/C#/Go і парочка сервісів на C++/Rust
FB Hack використовує, замість Java

Дякую, що коментуєте Раст, не знаючи його

Я коментую не Rust — а ваші аргументи. Які вказаують що ваші знання розробки веб апі — вкрай обмеженні.

Ви ПХП розробник, вгадав?

був і на ньмоу.
А також писав професійно — на plain C, асемблері — у геймдеві, 1С, Java(було ПЗ керування клаудною інфраструктурою), C#, PHP і зараз фуллстек на JS. Рулив проектами впровадженням ERP на виробництвах.

За останні роки не бачив і не чув щоб комусь прийшло в голову переписувати бекенд з Ноди, який крутится на AWS на щось інше.
З Пітона на Node.JS — зустрічав . На Go — окремі сервіси — теж чув.

Так що — давайте аргументи для «CTO», раз не маєте для програмістів — про економію. Я майже за 30 років про неї багато знаю, і куди і як розподіляється бюджет — теж. Бо сам розписував його для стейкхолдерів і інших замовників. І різав його — на їх вимоги теж.

Оцю фігню:

ті кошти, які платяться за клауд

залиште для нубів.
Або для блокчейна в клаудах :)

Потрібно, бо це напряму ті кошти, які платяться за клауд

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

Які вказаують що ваші знання розробки веб апі — вкрай обмеженні.

О, ща будемо мірятися. 15 років у бекенду — це вкрай обмежені?

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

Всі ваші аргументи

ви на свої подивиться :)

15 років у бекенду — це вкрай обмежені?

можете й — 150 написати.

я вам надав приклад аргументації, і задав конкретні питання.
і що ви змогли з досвідом у 150 років відповісти? ;)

Потрібно, бо це напряму ті кошти, які платяться за клауд

Наверняка есть кейсы, требующие серьезной вычислительной мощности, и там да, даже перформанс буст в 30% может заметно сэкономить — но таких подавляющее меньшинство.
В 90% проектов, чрезмерные косты за клауд — это в первую, вторую и третью очереди неудачное планирование и использование ресурсов. И, оптимизировав эту область, результат почти всегда намного выше чем просто убрать 5 нод из кластера в 50 )

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

Но, например, я пишу на нем пет проекты и те проекты, где я один бекенд — мне, к примеру, экономия на клауде совсем не лишняя.

экономия на клауде совсем не лишняя.

на всяк случай повторю вопрос:
обозначьте в пару предложений — качественные, НЕ количественные, характеристики проектов, в которых — будет экономия. При наличии реального опыта — это ж несложно.

На всякий случай повторю — процитируйте, где я призывал бросать ПХП или ноду и переходить на Раст? Прекращайте спорить с голосами в голове

а тормозить у веб проектах — робота з БД

Достаточно спорное утверждение, если уж говорить о клауд-сервисах.

100 мс відповіді чи 500 мс — зазвичай не має значення.

В такой размерности имеет. Конечно, совсем уже «дотрахиваться до мышей» не стоит, и в случае 50мс или 70 мс — тут да, неприципиально.

частенько маэ недостатньо часу на проектування системі типів — а працюючий код повинно здавати вже в перших спрінтах.

Вижу старый добрый «бах-бах и в продакшн»

Достаточно спорное утверждение, если уж говорить о клауд-сервисах.

в смысле в них бесконечный цикл — работает быстрее?
или они
SELECT N+1
разруливают?

В такой размерности имеет.

зависит от потребителя ответа.
но если это человек — то разницы он не заметит.
плюс пара спинеров — «и все летает!»

Вижу старый добрый «бах-бах и в продакшн»

Не телепатируйте, не солидно.

А то что на проектирование в эстимейтах времени не закладывается — обычное дело.
Аджайл проектирование — победило. В тех самых 90% что вы выше упомянули.

И от ЯП это не зависит.

то что все важно щеки надувают фразой «бах-бах и в продакшн», мы не такие, «у нас все как в NASA» — это да :)

...а мои проекты проходили внешний технический аудит. без существеных замечаний. Так что я знаю что такое
проектировать быстро, на ходу, и чтобы не было потом самому «мучительно больно». А у новых профи на проекте — не было стонов и рвоты от принятых решений и качества кодовой базы.

зависит от потребителя ответа.
но если это человек — то разницы он не заметит.

Блин, ну классика же, стыдно такого не знать
www.nngroup.com/...​times-3-important-limits

A delay of 0.2–1.0 seconds does mean that users notice the delay and thus feel the computer is «working» on the command, as opposed to having the command be a direct effect of the users’ actions
плюс пара спинеров — «и все летает!»

Типа замели под ковер, ну и ладно

в смысле в них бесконечный цикл — работает быстрее?
или они SELECT N+1 разруливают?.

Не совсем понял к чему это. Поинт был, что безапелляционое утверждение что

тормозить у веб проектах — робота з БД

мягко говоря, далеко не всегда верно.
Если, конечно, под термином «веб-проект» не подразумевается исключительно странички, exposing to the user СRUD-операции, где больше тормозить нечему по дефолту

Блин, ну классика же, стыдно такого не знать

то есть вы решили таки поиграть в телепата — и уверенно заявить о том что я знаю, а чего не знаю :)

в указанной вами статье — указаны — основные причины тормозов между
0.1 second и 1.0 second?

исследований же влияния времени ответа посещаемости — ого сколько.

и, вот понравилось:
if your site loads in 5 seconds, it is faster than approximately 25% of the web
if your site loads in 2.9 seconds, it is faster than approximately 50% of the web
if your site loads in 1.7 seconds, it is faster than approximately 75% of the web
if your site loads in 0.8 seconds, it is faster than approximately 94% of the web

А теперь поясните — какое конкуретное преимущество даст сайт — если вместо 500мс он будет отвечать за 100 мс? см выше о 0.8 seconds
ну чтобы — вкладывать деньги в это достижение?

и на это уже тоже не один год ищут ответ
например:
Indeed, a 2019 study by US digital marketing agency Portent showed «conversion rates drop by an average of 4.42% with each additional second of load time (between seconds 0-5).»

или:
The notable facts they found were :
The first-second delay resulted in a 4.9% drop in the number of articles a visitor read
The three-second delay resulted in a 7.9% drop

4.9% не ждут больше — 1 секунды.
Стыдно такого не знать, чтобы заявлить о ценности пары сотен мс для веб проектов где ожидающим ответа является — человек.

Типа замели под ковер, ну и ладно

если фейсбуки с гуглами так деают — то почему простым смертным нельзя :)

Не совсем понял к чему это.

а был он к
— а тормозить у веб проектах — робота з БД
— Достаточно спорное утверждение, если уж говорить о клауд-сервисах.

не, конечно, если проект такой — в котором нет персистентного хранилища — то да.

мягко говоря, далеко не всегда верно.

я и не говорил — всегда.

Если, конечно, под термином «веб-проект» не подразумевается исключительно странички exposing СRUD-операций

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

ну, или веб сервис который обходится мемори дб (с асинхронным сохранением), Касандрой какой-нибудь. Хотя уже и тогда доля ожидания будет значимой.

но намекать что процент проектов не сохраняющих информацию между сессиями значим, мягко говоря смахивает на классику холиваров:
«Если один считает другого кретином, то один из них точно кретин.
Может и оба.»

в указанной вами статье — указаны — основные причины тормозов между
0.1 second и 1.0 second?

Пользователю на это наплевать. Главный поинт — что эта разница заметна

if your site loads in 2.9 seconds, it is faster than approximately 50% of the web
if your site loads in 1.7 seconds, it is faster than approximately 75% of the web
if your site loads in 0.8 seconds, it is faster than approximately 94% of the web

Почти всегда можно найти худший вариант, но это не повод к этому стремиться.

conversion rates drop by an average of 4.42% with each additional second of load time (between seconds 0-5)
4.9% не ждут больше — 1 секунды.

Ну то есть — и хер с ними, с неженками? Бизнес обычно приходит в восторг от таких подходов.

если вместо 500мс он будет отвечать за 100 мс

... то тогда если вам надо будет сделать 3 api calls последовательно, это займет 1.5 сек а не 0.3, например.

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

Вместо «вычисления» — которое обычно да, встречается не очень часто — просто поставьте «взаимодействие с внешними системами» — и вот тут часто это занимает заметно больше времени чем последующая БД операция.

что эта разница заметна

пользователя в первую очередь интересуют
контент
функционал
удобство работы — UX, интуитивно понятные возможности функционала
и только потом несущественна разница между 50 и 500 первой загрузки. Потому что вторая и последующие — уже обычно гораздо меньше. Я про веб приложения, и даже классические сайты — генерирующие HTML вместе с данными в ответ.

Поэтому и скорость разработки — критически важна, чтобы побыстрее выкатывать
функционал и удобство работы

Бизнес обычно приходит в восторг от таких подходов.

Бизнес приходит в восторг от увеличения прибыли. А не от того от чего технари приходят в восторг.

просто поставьте «взаимодействие с внешними системами»

я и просто поставил
пользователя — человека.

потому что ессно — если внешние системы — это десятки тысяч IoT устройств — то «питоны» не годятся для ответа им.

и вот тут часто это занимает заметно больше времени чем последующая БД операция.

когда внешней системе — не нужен ответ. Вернее достаточен — ОК! Принято!

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

Читав у С++ яких поважаю — їм Rust виглядає жахливо і нееститчно.

пацталом, ті ще естети

і у всіх є — GC.
У Rust — немає.

ти так пишеш, ніби це погано

Краще профі у Ноді чим нуби у Rust

Сумуючи ваші пункти — у Rust немає переваг, а от недоліки — чималі.

лол

ти так пишеш, ніби це погано

це не погано і не добре.

нема GC — аперкот по швидкості розробки.
Він тому й з’явився, і в купі мейнстрім мов є.

лол

вище я навів як приклад — раціональної статті.

у відповідь — лол та всяка фігня від адептів. ну такє — звичайне :)

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

нема GC — аперкот по швидкості розробки.

Ви ж не знаєте Раст і не писали на ньому, як ви можете це стверджувати? Але враховуючи рівень вашої аргументації в цій дискусії — то не дивно

Ви ж не знаєте Раст

зате ви — знаєте.
то скажіть — є там GC чи немає? ;)

і не писали на ньому

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

Количество звезд у этих проектов — Впечатляет!

Фсё, скоро настанет мир тотального Rust — «Вордпресы» в ужасе замерли.

нема GC — аперкот по швидкості розробки.

абаснуй, чи ти з цепепе путаєш?

абаснуй

це було абасновано гослінгами, коли вони джави створювали.

а якщо на Rust швидкість розробки приблизно хоч така ж як на Go(пітони точно не досяжні — стат типізація — ще один хук, під дих) — то ми дуже швидко побачимо купу софта на ньому.

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

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

але лєньки. бо я писав професійно
на plain C, FoxPro, 1C, Java, C#, PHP, JS(front-end), TS і ще по дрібничкав, та щось мацав.

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

наскільке довше його писати та дебажити
наскільке ваще розвивати, сапортити (гівнокод, або ще якого високого когнтивного — теж не залежить від мови)

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

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

Бо міліони мух — таки не помиляються :D
Сноби нехай у холіварах верещать собі, та як голохавстов взірають з вершин на мишей, прастіте крисей там, унизу.

Експеремент над програмістами — не тільки поставлено, а вже й є його результати. Висновкі про прочини так, можуть різнитися
Про:

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

До речі, як на мене, кілер фіча Rust
«Memory safety» та «Memory management»

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

в Rust якщо компілятор пропустив, то 99% що дебажити не потрібно, крешдамп рідко коли побачиш.

Розробка швидко іде, тому що є повно бібліотек, є пакет-менеджер, є елементи функціанальщини.

З.І.
Порівнюю з С та С++, не з Пайтоном.

в Rust якщо компілятор пропустив, то 99% що дебажити не потрібно

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

Штучний інтелект там, чи що?

Розробка швидко іде, тому що є повно бібліотек

тобто з бібліотеками під джави з пітонами проблема.
Ти ба, які новини.

Порівнюю з С та С++

ну з ними, враховуючи кілер фічу Rust — думаю так, на ньому мабуть швидше.
щоб особисто переконатись, треба особисто пет проектик написати. але так, може бути.

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

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

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

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

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

Швидкість розробки така ж, як і на ноді. Типізація прискорює розробку для проектів довше місяця.

І купу софта ми не побачимо, бо Раст складний, і тому залишиться нишовим

— Сама мова більш виразна, ніж Шарп і тим більше Джава, більш потужна система типів

В каком еще языке можно написать

<T: HasAfEnum + Clone + Debug + Default + PartialOrd + HasAfEnum<AbsOutType = T> + HasAfEnum<UnaryOutType = T> + FloatingPoint + ConstGenerator + HasAfEnum<AggregateOutType = T> + ConstGenerator<OutType = T>>

Та це досить простий констрейн, ось якщо потрібно якусь асинхронну штуку обʼявити — от там капець

Бенефітів нема, доки на продакшн не залили — а воно не тримає навантаження. Нажаль таке я бачів, як закортіло написати на nide і та neo4j. Більше за те вимушений був приймати участь, коли вже запізно було. Насправді Rust як і D дуже цікаві мови, фішка в роботі з вказівниками компілятор має вбудований підрахунок посилань і вставляє new та delete в потрібних місцях прямо на етапі компіляції. Тобто можна обійтись без інтелектуальних вказівників і зборки сміття. D почали у себе ту саму ідею імплементувати.

а воно не тримає навантаження.

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

Насправді Rust як і D дуже цікаві мови

звісно що цікаві.
мови які з’являются — завжди чимость цікаві.

Тобто можна обійтись без інтелектуальних вказівників і зборки сміття.

як можно — то й обійдуться.

а переваги JIT компіляції наведені у топіку — Spiral

А то ви не в курсі, що проектують в 70% випадків постфактум. В тому і справа, що техлідів не з початку кликають, коли вони треба — а в кінці, коли вже срака настала і думають, що вони за допомогою чорної магії та срібних куль виправлять усе за два тижні до релізу. За багато років я бачів не так вже і багато техлідів, нажаль, які починають з того, що змушують команди проектувати. Бо за теорією це мають робити самі команди, а техлід леше перевіряє, що те, що вони роблять це по перше взагалі архітектура тобто дискретизація підсистем та компонентів та описана взаємодія між ними, а по друге не є антипатерном. Що стосується цього проекту, то тут менеджмент забив болт на усе, віддав усе керівництво клієнту через, що і отримав технічне рішення на рівні самого клієнта, як і стосунки в команді такі самі як і у клієнта. Іноді у іноземців і поганому вчаться, до того ж поганому і догмам як відомо вчаться швидше навіть якщо цьому навмисно і не навчають.

А то ви не в курсі, що проектують в 70% випадків постфактум. В тому і справа, що техлідів не з початку кликають

в курсі звісно.
випадково — сьогодні вибив собі таскі з «X architecture implementation». Цілих дві. Мені повезло!

бо клеїти шпалери на відсутні стіни — важкувато :)
Доводилось не раз, але — краще уникати такої ситуації.

а в кінці, коли вже срака настала і думають,

от тому я хейчу все що потребує ретельного проектування: бо на це не дадуть часу.
В NASA так, дадуть. Та в ембедеді — бо там архитектурні помилки призведуть до реальних і великіх збитків.

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

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

На зараз которотенько називаю ті практики:
Проектуй на +1 та −1 рівень абстракцій чим треба.
Заборонено!
1. на тому якому треба,
2. більше 1 (верх та вниз)

Починай проект з кінця, а не з початку

У планах робіт
Паралель активності якомога більше — наприклад ізоляцією підсистем.

і т.і.

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

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

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

життя, воно такє, з теорією не збігається. Добре коли хоча б корелює :)

І які це? Програмувати на стеку?

Конкурентний доступ з багатьох потоків (в тому числі в асинхронному коді), статичний (параметричний) поліморфізм замість дінамічної діспетчеризації, використання більш оптимальних по памʼяті структур даних.

чим складна?
складніше за цепепе? точно?

Складніша за ноду та шарп, наприклад

Якби Rust не був таким складним, вбив би C# та Джаву.

якби свинi рога та крила)

Стаття просто вогонь!

C живіше за усіх живих, чому тоді C++ має помирати?

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

Також C та С++ -дуже різні мови, якщо ви не у курсі.

хто ж його винесе, він пам"ятник

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

Спірно, дуже спірно, воно може і працює, але все в артефактах.

Я что-то не понял, автор ещё ничего не писал на Golang? Зря всю жизнь прожил.

Якщо без тролінгу, то гошечка не є заміною плюсам, вона грає на полі, де грають java та .net

Ещё как уделывает плюсы, причём начиная с ключевой фичи — мультипоточность из коробки.

мультипоточность из коробки

Это которая «green threads»? Такая себе мультипоточность...

фу, це ж тупе С

Именно. И не просто «тупе С», а исконный благословенный POSIX.

і де ж тут убивця цепепе?
де синтетичний цукор?
воно не ням-ням

і де ж тут убився цепепе?

Дык, прекрасное портабельное (включая даже ABI-совместимость на конкретной платформе) и прозрачное решение. В отличии от...

Что там за адский трэш, внутри ентого «std::async» под капотом?

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

В стандарте C нет многопоточности

Ты отстал ровно на 11 лет.

Не знаю, что там С, но тут главное не путать с С++11.

Не знаю, что там С

Ну вот именно.
en.cppreference.com/w/c/11

Таки да, похоже что наконец добавили.

В языке С существует библиотека для организации многопоточных программ: POSIX Threads API. Я это точно знаю, потому что хлопцы у нас на 122-ой заставляют все на цехе здавать, только недавно раст разрешили.Там вроде есть кастыли если писать под виндовс, под линуху вроде норм заходит.
Открыл документацию, и вот такое, кто то такое использовал.https://docs.microsoft.com/ru-ru/cpp/parallel/multithreading-with-c-and-win32?view=msvc-170

POSIX Threads API это не часть языка C. Это какая-то левая библиотека, которая может отсутствовать на платформе, которую вы разрабатываете.

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

В С++20 появился новый класс для создания потоков и управления ими std::jthread. Класс jthread представляет собой один поток выполнения. Он имеет то же поведение, что и std::thread, за исключением того, что jthread автоматически join’ится при уничтожении и предлагает интерфейс для остановки потока. В отличие от std::thread, jthread содержит внутренний закрытый член типа std::stop_source, который хранит stop-state. Конструктор jthread принимает функцию, которая принимает std::stop_token в качестве своего первого аргумента. Этот аргумент передаётся в функцию из stop_source, и позволяет функции проверить, была ли запрошена остановка во время ее выполнения, и завершиться при необходимости. en.cppreference.com/w/cpp/thread/jthread
Потоки действительно будут созданы в порядке очереди, и шё?А вот квант процессорного времени хлопцы, они получат тот, который совершенно не согласуется с порядком их создания. Поэтому первым может оказаться запущен любой, хоть второй, хоть двадцать второй поток.

Але ж асинк із FSM нема, це раз,
два: як вбити зовні асинк, напр.,
ти створи фючев та послав хттп запит, а сервер ні кує не меле так секунд 20 і в тебе висить тред, а тобі бажано, якщо 1с і тиша, то вбити тред і вернути «нореспонс фром сервер». А вже мона. Ура! Цепепе це може!

Я би сказав, що С++ відстає від більш модних «вбивць С++» по виразності функціоналу.

Як там з менеджером пакетів? Юніт тестами і подібною ванілою

Выбор текущего потока из нескольких активных потоков, пытающихся получить доступ к процессору называется у нас на 122-ой планированием. Процедура планирования обычно заключатся с выполнением весьма затратной процедурой диспетчеризации т.е переключением процессора на новый поток, поэтому планировщик должен заботиться об эффективном использовании процессора. При этом всем хлопцы поток еще может находиться в одном из трёх состояний: (Executing) — поток, который выполняется в текущий момент на процессоре. (Runnable) — поток ждет получения кванта времени и готов выполнять назначенные ему инструкции. Планировщик выбирает следующий поток для выполнения только из готовых потоков. (Waiting) — работа потока заблокирована в ожидании блокирующей операции. При разработке программ важность потоков разная.Для решения этой задачи с целью контроля этого процесса был придуман приоритет работы. У каждого потока есть такое типо числовое значение приоритета.Чем оно выше тот поток и будет главнее!! Никто никого ждать не будет! Если такое происхдоит значит крынжа. Если у вас есть несколько спящих потоков, которые нужно запустить, то ОС в первую очередь запустит поток с более высоким приоритетом.
На FSM типо конечные автоматы мы только лабы делали на цешке где разбирали строчку. Ясно шё процессы в операционной системе, промисы внутри так и вообще любая асинхронность, event loop ни что иное как автомат, валидная/не валидная форма, логика работы терминала и так далее. Можно абсолютно все что нас окружает описать автоматами! Посмотрите в сторону парадигмы автоматного программирования.

ти ще JK тригер намалював би,
тільки синхронний/асинхронний в програмуванні і RTL трохи різні поняття

і що?
я так не зрозумів, чим ліпше виділення потоку на асинк метод/функцію в С++ ліпше від створення в рантаймі Rust кінцевого автомату без створення нового потоку?

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

Ми ж не про потоки взагалі, а про асинк, нє?

а може братися із пулу потоків (але це не точно: залежить від компілятора, ОС, фази місяця ...), ти про це?

Я про те, що можна явно вказувати не створювати новий потік. У С++ можна асинхронно працювати із або без створення нових потоків. Давно є така ліба як asio. Є корутини у бібліотеці й у стандарті. Питання: що потрібно зробити?

поки що нічого не потрібно робити, мені тільки цікаво, чому в С++ асинк мапиться на потоки, і більш ніяк, і це подається як кілєрфіча у порівнянні із Rust, де zero cost цієї абстракції можна мати

В Rust асинхронные фьючерсы существуют уже более трех лет, но стабильная поддержка async/await появилась не так давно. Вы уверены, что там все хорошё?Кроме того компилятор Rust использует LLVM, это означает хлопцы, что количество поддерживаемых платформ будет меньше, чем у C или C++.

Rust использует LLVM,

точно, чи ОБС?

Кроме того компилятор Rust использует LLVM, это означает хлопцы, что количество поддерживаемых платформ будет меньше, чем у C или C++.

На бумаге меньше. На практике, если под платформу нет официальной или сторонней поддержки LLVM, то она мягко говоря скорее мертва чем жива.

Плюс сейчас активно пилится gcc frontend и этот разрыв существенно сокращается.

Кроме того компилятор Rust использует LLVM, это означает хлопцы, что количество поддерживаемых платформ будет меньше, чем у C или C++.

Єто означает что портировать под платформу его можно при первой необходимости

токіо транслюється в треди, чи в FSM?
std::asynct C++ в треди,
в Русті в FSM, як і в JS

токіо транслюється в треди, чи в FSM?

tokio это async framework под Rust. Сам Rust реализует механизм для конвертации последовательного процедурного года в FSM, но не предоставляет механизма для его выполнения. Механизмы выполнения предоставляются сторонними async executor, tokio это один из них. Под капотом tokio там используется смесь green threads и OS threads. Там сильно много функционала и конфигурации, чтоб ответить на вопрос да/нет.

std::asynct C++ в треди,

Зачем такой async?

я ж казав — без тролінгу
уделывает плюсы, ага... «погнали наши городских — наши спереди, городские сзади»

Твоя «ключова фіча багатопоточність» реалізована жирним куском коду під капотом, який написаний на C чи C++

А RTL в C/C++ реализуется жирным куском кода на ассемблере.

Нет, очень тонким. 99% что сейчас оставляют ассемблеру — это 1) вызов сисколла, в духе «mov r10,rcx; syscall», 2) создание стека в начальной `.start` и 3) аллокацию TLS. Дальше работает C.
Ибо человек ленив.

У меня другой вопрос — а как юзать C с каким-нибудь GC? Smartpointers — это всё не то, и тем более реализация C++, где на грабли наступаешь практически сразу. С мягкими и твёрдыми указателями, кольцевыми ссылками, const и не-const smartpointers, enable_shared_from_this и прочим бредом.

Если у вас возникают проблемы с управлением памяти в c++, то стоит почитать Джеффа Элджера. Но говорить о том, что язык с gc может заменить язык как с gc, так и без него, немного наивно :)

Я понимаю, что возможно какой-то Джефф Элджер очень умный, но всем это пофиг, для управления памятью в Go ничего читать не нужно. И это ключевой аспект, приводящий разработку к строгому соответствию принципу KISS. Если нужно избавиться от GC, то можно писать на чистом C, и тогда ещё в дополнение получите преимущество отсутствия шедуллера горутин.

Если нужно избавиться от GC, то можно писать на чистом C, и тогда ещё в дополнение получите преимущество отсутствия шедуллера горутин.

Своим комментарием вы подтверждаете узкую специализацию go, в отличии от c++. Что же это за язык, для работы с которым надо знать другой язык?

Кроме этого сам универсальность gc в go желает быть лучше — хорош только в задачах, оптимизированных под пропускную способность, например, написание апишечки. К стати, гугл в основном его использует для апишечки.

Я понимаю, что возможно какой-то Джефф Элджер очень умный, но всем это пофиг

Вы сюда пришли умом мерятся или другими частями тела? Нет желания или времени разбираться в c++? Вас устраивает go? Нет вопросов, но не надо говорить, что go может заменить с++ или си.

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

Согласен, но как-то странно говорить о том, что палки и камни могут заменить пулемет.

палки и камни

Це ти руст і го?

Нет, это я о том, что не стоит использовать аналогии для аргументации.

Своим комментарием вы подтверждаете узкую специализацию go, в отличии от c++

На сегодняшний день узкая специализация уже у C++. Широкая у него была лет 20-30 назад. А сейчас обширный спектр задач, который ранее писался на C++ пишется под другие языки и сопутствующие технологии. Свои позиции C++ утратил во время популяризации java, и .Net вслед за этим, когда MS проиграла суд Sun по патентным правам на джаву. И на сегодняшний день энетерпрайз-разработка на C++ под Windows API свёрнута полностью. Ещё частично код на C++ можно было писать под WinRT, но с фейлом WinPhone это направление тоже умерло. На сегодняшний день есть задачи, что старый функционал, написанный на C++ Windows-приложений нужно портировать в облако, в сервисах на Go. Ну а задачи наподобие описанных в статье выше, каким способом лучше вычислять sin или логические операции, меркнут на фоне изменений в архитектурных решениях в целом.

Расскажите про «широкую» специализацию го. Например, на с++ прекрасно пишется межплатформенный толстый клиент под линукс, виндовз, мак ос, пишутся БД (включая no-sql), пишутся MQ брокеры, бигдата системы, геймдев (не мне вам об этом говорить), системы реального времени (от медицинских до космоса), включая встроенные систем. Даже некоторые вещи под мобилки пишется (это исключение, чем правило), операционные системы (как минимум под виндой). Что же пишется на го кроме докера, апишечек и простенкого батчпроцессинга? Серьезно интересно, что уже на не молодом языке было реализовано или еще только пишется сейчас серьезного с долгой поддержкой, а не очередной микросервис, который по сложности хоть на бейсике пиши.

З.Ы. если что мне с++ не заходит, просто реально хочется понять, как го может заменить с++ или другой распространенный язык без gc

операционные системы

Под линукс до сих пор не завезли и не собираются, при том, что Rust уже почти доехал.

При чем тут rust к go? Мы же обсуждаем как go может заменить c++.

межплатформенный толстый клиент под линукс

Чего-чего? Тут требуется разъяснительная бригада.

виндовз, мак ос

Откуда вы знаете, на чём и как они сейчас пишут? MS уже давно заявляла, что .Net у них флагманская платформа, под которую они будут писать всё, включая компоненты ОС.

пишутся БД (включая no-sql), пишутся MQ брокеры

Тут без разницы, на чём их писать. OrientDB например вообще переписан с C++ на java. Что-то ещё под ноду написано, поскольку там всё равно js.

бигдата системы, геймдев (не мне вам об этом говорить), системы реального времени (от медицинских до космоса)

Вот как раз и пишутся на Go, это целевой сегмент разработки на Go. Причём зачастую код переписывается с C++ где нет GC, на Go где есть GC. А всё почему? Потому, что архитектурные решения имеют первичное значение, а код C/C++ занимает сегодня нишу оптимизационных решений.

Чего-чего? Тут требуется разъяснительная бригада.

Есть огромное количество успешных проектов на QT. Например, приложения, написанные на QT, более кроссплатформенные, чем написанные на .net (включая mono).

Откуда вы знаете, на чём и как они сейчас пишут? MS уже давно заявляла, что .Net у них флагманская платформа, под которую они будут писать всё, включая компоненты ОС.

Сам майкрософт писал об этом. Он подумывал о переходе на rust. Замете, не на go. Надеюсь, вы понимаете, что ОС — это не только десктоп оболочка. Если так говорить, то линукс то же написан на с++ (смотрим, что там в KDE).

Тут без разницы, на чём их писать. OrientDB например вообще переписан с C++ на java. Что-то ещё под ноду написано, поскольку там всё равно js.

Вот вы сами говорите, что куча языков используется для написания БД. Хотя бы одно популярное БД есть на go? Или, хотя бы, не популярное.

Вот как раз и пишутся на Go, это целевой сегмент разработки на Go. Причём зачастую код переписывается с C++ где нет GC, на Go где есть GC. А всё почему? Потому, что архитектурные решения имеют первичное значение, а код C/C++ занимает сегодня нишу оптимизационных решений.

Приведите, хотя бы одну подобную систему, которая хотя бы на 30% была написана на go. Это не тролинг, мне реально интересно, как же оно все работает с gc от go.

P.S. могу ошибаться, но, насколько я знаю, OrientDB изначально был написан на java.

Есть огромное количество успешных проектов на QT.

И что это старое говно мамонта делает, запускается на десктопе под убунту, после установки всех примочек? Или для чего оно ещё надо?

приложения, написанные на QT, более кроссплатформенные, чем написанные на .net

А вот Google выпустил flutter, который компилируется под web, под android и ios, ещё собираются сделать фуксию, где приложения будут писаться на том же флаттере, у них походу видиние кроссплатформенности в несколько ином аспекте. Причём кто бы что не делал, там C++ чего-то не фигурирует в качестве ключевого языка разработки.

Сам майкрософт писал об этом. Он подумывал о переходе на rust. Замете, не на go.

То есть, MS терзается в сомнениях, на что бы ему перейти, то ли под .net теперь всё пилить, то ли на rust переходить.

Надеюсь, вы понимаете, что ОС — это не только десктоп оболочка.

Вот вы положили болт на разработку на C++ 10 лет назад, а создаётся такое впечатление, будто бы совсем только что.

Вот вы сами говорите, что куча языков используется для написания БД. Хотя бы одно популярное БД есть на go? Или, хотя бы, не популярное.

Стоп-стоп-стоп. Раз OrientDB переписали с C++ на java, значит что же это такое выходит, что java лучше чем Go подходит для написания БД? Ну раз на Go не переписали? Или может C++ там даже изначально никак не фигурировал?

Хотя бы одно популярное БД есть на go? Или, хотя бы, не популярное.

victoriametrics.com

Хотя бы одно популярное БД есть на go? Или, хотя бы, не популярное.

CockroachDB, InfluxDB

Что же пишется на го кроме докера

перепиши кубернетес на цэпепе, victoria metrics, helm, vault, etcd, linkerd, prometheus та и еще куча софта в CNCF

Если у вас возникают проблемы с управлением памяти в c++, то стоит почитать Джеффа Элджера

А еще лучше Джона Гьенгсета

Ни чего не имею против раста, но как эта книга поможет разобраться в управлении памятью в с++?

повір що так, проливає світло з іншого боку на той же с++

И что, в книге есть конкретные решения, которые можно применять в с++? Например, как в этой — www.amazon.com/...​-Jeff-Alger/dp/0120499428 ? Мы же сейчас не обсуждаем, чем лучше или хуже с++ и rust.

Сори, я не буду покупать за 5 долларов книгу с тремя отзывами. Если не затруднит, можете перечислить несколько «конкретных решений», которые можно применять в С++?

В книге нет решений вашей задачи. В ней описаны концепты. Например, пространства памяти в чем-то похожи на управление памятью в расте. Но, как я понимаю, вам это не надо, т.к. вас вполне устраивает раст. Поэтому мне не понятно, почему у вас такой повышенный интерес к управлении памятью в с++?

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

Можете привести пример «концепта» или «пространства памяти»? Спрашивюа не ради троллинга.

Поэтому мне не понятно, почему у вас такой повышенный интерес к управлении памятью в с++?

Потому что с моей точки зрения управление памятью в C++ мягко говоря хромает по сравнению с тем, что есть в более современных языках программирования (либо с полными управляемыми сборщиками мусора типа C# либо с серьезной статической верификацией типа как в Rust). Если в C++ возможны какие-то более грамотные подходы к управлению памятью чем «ложи все на кучу в смарт поинтеры» и «нанимай программистов, которые хорошо знают все подводные камни C++», очень хотелось бы про них узнать.

Потому что с моей точки зрения управление памятью в C++ мягко говоря хромает

Я понимаю вас. Но мне не понятно, как прочтение книги от Джона Гьенгсета поможет schwarzlichtbezirk разобраться в управлении памятью в с++? В книге от Джеффа Элджера предложены различные концепты, от счетчика ссылок, до gc. Обсуждать rust я не хочу, т.к. у меня нет такой экспертизы в rust, что бы провести глубокое сравнение c++ и rust. Если бы эта ветка обсуждения была бы о rust vs c++, я бы еще понял. Но мы здесь обсуждаем, как go может полностью заменить c++. А может go может заменить rust? И не имеет значение, что rust появился позже go :). У вас есть какие-либо аргументы за go в этих вопросах?

как прочтение книги от Джона Гьенгсета поможет schwarzlichtbezirk разобраться в управлении памятью в с++?

Я ничего не писал о том, что испытываю трудности с разбирательством в управлении памяти в C++, вы похоже видите то, что вам удобнее видеть.

Я понимаю вас. Но мне не понятно, как прочтение книги от Джона Гьенгсета поможет schwarzlichtbezirk разобраться в управлении памятью в с++?

У Гьенгсета описан принцип работы borrow checker и как «различные концепты», в которое, внезапно, входит и счетчик ссылок и смарт поинтеры и GC (про который, он, правда, не говорит), могут быть безопасно реализованы на основе этих механизмов.

Понимание принципов borrow checker позволяет видеть в C++ коде места, где есть возможность накосячить, и избегать их.

Например, дает понимание, что нельзя гарантированно безопасно без borrow checker вернуть из функции ссылку, или держать ссылку внутри структуры/класса, поэтому надо или избегать подобных трюков, или рассматривать все места, где ссылки используются под микроскопом.

Также, когда приходит понимание, сколько механизмов требовалось запилить в Rust, чтоб дать разработчикам безопасную модель памяти, понимаешь наколько близко любая программа на C++ находится к undefined behavior, и вместо хиканек про «C++ неосиляторов», начинается параноидальный анализ своего и чужого кода на предмет лажи.

В книге от Джеффа Элджера предложены различные концепты, от счетчика ссылок, до gc.

Т.е. все, что может предложить язык, стремится в embedded и realtime — это аллоцировать все на куче, а еще лучше юзать GC, это немного убогая ситуация.

Но мы здесь обсуждаем, как go может полностью заменить c++.

Вы спорите с гофером, которые редко отличаются адекватностью. Мы просто перевели дискуссию в продуктивное русло.

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

вроді є там костиляють з
const &
нє?

не так, а так:
«перечислить несколько „конкретных решений“, которые можно применять в Rust»

з.і.
dou.ua/...​rums/topic/38670/#2432930

Я уже более 10 лет не пишу на с++ и не собираюсь возвращаться.
«перечислить несколько „конкретных решений“, которые можно применять в Rust»

Я немного устал писать о том, что сейчас идет обсуждение — как go может заменить с++. В можете посоветовать хотя бы одну книгу по управлению памятью в go, из которой будет понятно, как он может полностью заменить c++?

з.і.
dou.ua/...​rums/topic/38670/#2432930

Я думал, что из контекста понятно, что мы обсуждаем с++, а не все языки мира.

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

просто нове мало хто пише на С++
а для заміни С++ є С і Rust

В этой ветке идет обсуждение, что c++ можно без проблем заменить языком go. Тогда возникает вопрос, зачем вы пишите о rust или си, если есть go? Или это такие странные аргументы за go, что он может без проблем заменить c++ при помощи rust :)?

В этой ветке идет обсуждение, что c++ можно без проблем заменить языком go.

точно?
це в якомусь Законі написано?

Книга Джефа Элджера написана в 98 году, безнадежно устарела на сегодня. Не помню всего материала в ней, но запомнилось, что очень много в ней посвящено всяким умным, мудрым и гениальным указателям. В С++11 уже есть умные указатели, смысла тратить время на эту книгу сегодня не много.

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

Если под многозначительным словосочетанием «концепты управления памятью» подразумевается использование умных указателей, то полезнее почитать Скотта Мейерса, там намного практичнее описано и уже про 11 и 14 стандарты.

Там не только умные указатели. Например, введение транзакционную память, введение в GC (после прочтения понимаешь, почему GC не был введен и никогда не будет введен в стандарт) и многое другое. По мне, так глубина книги где-то рядом с книгами от Александреску. Понятно, что ее не стоит советовать джуну. Хотя, возможно, есть что-то более современное с таким же глубоким рассмотрением поднятых вопросов в книге. Не знаю. Я уже более 10 лет не пишу на с++ и не собираюсь возвращаться.

Я уже более 10 лет не пишу на с++ и не собираюсь возвращаться.

тим більше дивно, якщо така крута супер-пупер мова

Где вы видели, что бы я писал, что c++ — крутой супер-пупер язык? В этой ветке идет сравнение «спуер-пупер» языка go, который без проблем может заменить c++. Я пытаюсь понять, как он может заменить с++? Может быть вы видите, как go может заменить c++, например, в ядре винды или в проектах реального времени или ...?

наскільки я пригадую, ішлося про Rust
C++ не заміняють, а витісняють, і не одне тільки Го

Вообще то я пытаюсь понять

и как юзать вот этот go без gc?

Ссылочка на мой вопрос. А вот это ссылка на корневой комментарий.

Скиньте ссылку, где я могу получить ответ на

и как юзать вот этот go без gc?

Ну а если нельзя Go юзать без GC и GC в Go оптимизирован только под пропускную способность, то выходит, что на Go имеет смысл реализовывать задачи с большой пропускной способностью (и плевать на процессор и память). При этом реализация GC в Go не уплотняет память, что может привести к ее нехватки. Отсюда вывод — Go относительно узкоспециализированный язык/платформа. Да, есть много задач под его специализацию (например, апишечек на порядки больше, чем софта под мед. оборудование). Но ни как нельзя утверждать, что Go может заменить распространенный (пусть и легаси) язык/платформу с очень широким назначением. Rust? Может быть. Я не знаю. Но Go точно не вариант.

При этом реализация GC в Go не уплотняет память, что может привести к ее нехватки. Отсюда вывод — Go относительно узкоспециализированный язык/платформа.

Прошу прощения, а реализация под C++ уплотняет память?

в UE4 есть GC, именно тот самый который mark and sweep

Node.js тоже хорошё интергируеся с цешкой. В чем плюс Го, можно написать интеграцию без цешной прокладки?

Golang — це про веб

залежить від того що називати — веб.
Golang — точно не для написання Web UI

а може для складської системи, ел магазина з Web UI він кращий за пітони з джавами?
на ньому зручніше писати у стилі DDD наприклад?
Тому він що він семантично багатший чим Пітон або C#?

ну ок, а може на ньому зручно писати запити до баз данних?

що таке — веб....

Єдина мова, що хоч якось може потіснити плюси, це Раст, і то з натяжкою. І то, це треба дуже повірити у Раст, і те, що він не загнеться.

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

Решаем с сыном задачки на литкоде, он на c# / python, я на с++. Он все время удивляется, как так, решения на с++ часто в разы быстрее. Но тем неменее, я его отговариваю от с++, ну не надо он ему... слишком сложный язык, и стандарт 20 года вообще не делает его проще (в отличии от c++11, c++17) к сожалению.

Так «какая разніца на каком язикє» ) Але серйозно — мова, навіть с++ це максимум 10% від того що треба знати, тому обирати треба напрям (веб, мобайл, ембедед, ентерпрайз, стартапи, агенції) й відштохуючись від цього обирати мову.

в народі це називається накинути гів...на на вентилятор)

Автор не дивиться в корінь проблеми від слова «зовсім».
C++ досі часто використовується там де є ліба на C/C++ і треба її сапортити/інтегрувати/обв’язку робити.
А ліба саме на C++ тому що треба сапортити Win/Android/iOS/*nix/web і ще-там-щось. А компілятор C++ є практично під будь-що включаючи модерний веб, пульт до телика і кавоварку, на відміну від практично всіх «масових вбивць C++». Плюс купа кейсів коли є С/C++ SDK і немає більш нічого — звісно, можна реалізувати «свій варіант» але це час і гроші, і потім треба сапортити.
Відтак, C/C++ здохне тоді коли він перестане бути мовою по-замовчуванням для крос-платформи і для системної розробки (бо потім ті системні розробники пишуть SDK на тій же мові на якій решта системи написана)

перепрошую, але до чого С++ до С?
чому пишуть «С/С++» і «С++ не помре», коли потрібно писати, що «С не помре»?
С і С++, це як Java та JavaScript

А компілятор C++ є практично під будь-що

під С, а не під С++,
крім компілятора потрібно ще для С++ хоча б STL, чи ми про що, про С++ в стилі С?

Навіть на 8-бітне ардуїно штатний компілятор це вже C++ а не C

«сишные» компиляторы под процы идут всегда. «плюсовые» далеко не всегда (скорее, редко когда).

П.С. Ардуино — не проц.

Так а де я писав що це процесор?)

«Штатные компиляторы» — идут под процы, а не под платы.
И от производителей процов.

Мені здається комусь теж варто перевірити свої знання: «плата», «мікроконтроллер», «мікропроцесор», «ядро», «мікроархітектура», «ABI».
І під що з цього списку таки йде компілятор :)

І під що з цього списку таки йде компілятор

Как правило, лишь под проц.

Тобто, коли я під мікроКОНТРОЛЛЕР XC164CS-32F з ядром C166SV2 збирав код компілятором С++ під мікроАРХІТЕКТУРУ Siemens C166 — я робив щось не так? :)
Ех, зразу видно що я не профік по ембеду.

Тобто, коли я під мікроКОНТРОЛЛЕР XC164CS-32F з ядром C166SV2 збирав код компілятором С++ під мікроАРХІТЕКТУРУ Siemens C166

„XC164CS-32F/32R 16-Bit Single-Chip Microcontroller with C166SV2 Core”
www.infineon.com/...​3136c9a8b01136d9c9f930069

„Supported by a Large Range of Development Tools like C-Compilers, MacroAssembler Packages, Emulators, Evaluation Boards, HLL-Debuggers, Simulators, Logic Analyzer Disassemblers, Programming Boards”

Может, это был таки „сишный” компилятор? Просто, кто-то не понимает разницы между „си” и „плюсами”...

А що, в сішці 2022 вже є конструктори, деструктори, ключові слова new/delete, віртуальні методи і exceptions?
Якщо є — то я вибачаюсь, справді щось не те подумав.

new/delete, віртуальні методи і exceptions?

Ты с этим всем «эмбед-софт» писал? Хм...

Без exceptions, а в решті я нічого поганого не бачу.
Особливо потішно коли ті ж люди хто фиркають на плюсові віртуальні методи починають ліпити власну реалізацію того ж самого на голій сішці (в вигляді сирих вказівників на методи які перекидаються туди-сюди, або вказівників на таблиці методів... oh wait...) і потім з піною з рота доводять що це в 100500 тисяч разів краще ніж таблиця методів в плюсах.

Зрештою я ніде і не кажу що я embedded developer, в мене таких слів і в резюме нема. Відтак, навіть exceptions цілком можна було б використовувати і не соромитись.

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

Таблицы методов и указатели на функции — это всё вещи в эмбеде вполне легитимные. До тех пор, пока всё остаётся статическим.

Но new/delete? Наследование/полиморфизм?? Бгг...

П.С. Впрочем, скоро хипстеры в эмбедах начнут кубернетcы с прочими эластиками крутить.

Так а в чому різниця між malloc + ручна ініціалізація проти new (в старообрядній формі яка не кидає ексепшн а вертає NULL)?

Далі, про «статичність»: з того що я бачив в реальних проектах (писав не я, якщо що) це системи «модулів» які під час ініціалізації збирають call chain на вказівниках в linked list.
По факту, будь там плюси і абстрактні класи з точки зору коду який виконується воно нічим би не відрізнялось.

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

Будь там «плюсы» — к багам от кривых рук разработчиков софта, прибавились бы ещё баги от кривых рук разработчиков «плюсового» компилятора.

Окей, нарешті ми докопуємось до суті — компілятори і справді сумні, по правді навіть деякі сішні конструкції компілювались в такий асемблерний код що диво брало.
Взагалі є надія що по мірі здешевлення ядер на мейнстрімних µArch (кхе-кхе... ARM... кхе...) проблема вирішиться шляхом переходу на мейнстрімні ж компілятори. Ну і більш сучасні ядра на кшталт Xtensa теж йдуть з доволі свіжими GCC/Clang що радує.

C++ досі використовується там, де використовувався десятиріччями до цього. І нічого там не змінити, і нічого з цим не зробити.

. Пробую щось нове, але щоразу повертаюсь до С++,

є просте рішення: «не брати тяжкого в руки, а дурного в голову», тобто на всі непристойні пропозиції щодо С++ відповідати: «сам не курю і вам не совєтую», і ти ба, буде наче сім бабок пошептало, ніякого С++ в межах обозримого горизонту

А ти RUST ще куриш? Як тобi?

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

Але зараз знову набігли рекрутери на С++, прийшлось в джині піднімати планку

А що є яка пристойна пропозиція?

Numba: певно Ви мало з нею, мало працювали, бо Numba компілює не Python, а лише певну його підмножину (схожу на C + numpy). Тобто для неї потрібно спеціально переписувати пітонячий код на свою «під-мову», що досить нетривіально, бо помилка (з точки зору Numba, не Python) у коді може вилетіти й через годину обчислень. Відлагодження немає, що за помилки не зрозуміло, інколи потрібно днями вивчати транслятор Numba, щоб зрозуміти, яка ідіоматична пітоняча конструкція її завалила. Ще буває, що з код з @jit та без, видає різний результат — happy debugging☹. Нажаль, більш схоже, не на вбивцю, а доходягу

C++ вмирає з початку 2000-х, а компанії у 2022 хайрять як скажені на проекти на С++, ще й з нуля розробляють їх.

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

C++ вмирає

таке життя.
воно занадто коротке для плюсiв та ассемблера.

тільки за Руст з 1 рік досвіду платять в 1.5 більше чим С++ 5 років,
а якщо мати досвід з блокчейном то 300Куе в рік + крипта + опціони

то 300Куе в рік + крипта + опціони

Ну то ж у США, так?

замовник США., растамен анівере
а що, в галер місцеві з прозори Автозази і Укпошти?

Як можна 300куе отримувати у неньці?

Ну це трішечки менше ніж 300куо, але все одно можна купити мінімум дві однухи за перший рік!

можна півроку з одного року захопити, і півроку з іншого року,
а до/потім в Грузію

Title: Senior Engineer
Keywords: Rust, Substrate, Polkadot, Blockchain, Smart Contracts....
Base Salary: 150-300’000 USD p/a
Benefits: Equity and Tokens
Location: Californian HQ but the company is remote-first and has Engineers collaborating from all over the world

Blockchain, Smart Contracts....

там і за Web 3 на Ноді платять більше ніж в середньому на Ноді.
мова ні до чого — домен такий. гарячий та з дурними грошима.

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

Spiral, Numba, ForwardCom

Все, вирішено — в понеділок на мітингу пропоную замовнику переписати наші скікісь там мільйонів рядків С++ коду на Spiral. Якщо не погодиться — в вівторок і середу запропоную Numba та ForwardCom :)

Якщо серйозно, то автор, звичайно, правий — С++ помирає, але це відбувається приблизно з тією ж швидкістю, як Земля падає на Сонце. Ну, тобто, через скількісь там мільйонів-мільярдів років це станеться, але на наш вік ще вистачить :)

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

Тулзи цікаві, дякую. Але з посилом і висновками складно погодитись, якось тепле з м’яким у купу намішано.

Жахлива кодова база з купою легасі, провальні архітектурні рішення, відсутність гайдлайнів, недосвідчені розробники і текучка кадрів, відсутність ідеї maintainability коду чи навіть банального код-рев’ю, кастомер, що не бажає витрачатись на рефакторінг? То, звісно, C++ в усьому винен! А написання проєкту будь-якою іншою мовою в таких умовах, звісно, призвело б до протилежного результату і все було б зашибісь.

C++ неоптимально використовувати для якоїсь конкретної задачі? Всьо, воно вже майже мертве! Десь так з 1985 року. А ніяких інших задач, доменів і стрімкого розвинення мови просто не існує.

Вибір мови залежить не тільки від синтаксису, але й інфраструктури (як-от банальної наявності бібліотек чи компіляторів під конкретну залізяку/ОС), доступності (і рейту) розробників, домену, регуляцій в цьому домені. Ніхто вам не дозволить запхати jit-компіляцію в критичну ділянку коду, наприклад. Чи писати скіль-небудь складну кодову базу на асемблері чи брейнфаку, який в усьому світі знають півтора інваліда, якомусь нещасному ж це потім підтримувати. Чи розводити зоопарк технологій там, де краще обійтись однією універсальною. У плюсів є свої ніші і роботи там вистачить на два життя вперед.

Щоб щось померло, потрібно щоб щось народилось. Достойного поки не бачу. Зрушились на 20% вперед, а тішимось ніби в 5 раз краще стало. Що краще? Масиви, об’єкти тепер легко записати в один рядок? А що сталось із швидкодією. В Пайтоні вона в 10 раз знизилась при тому, що ПК в декілька разів швидше працюють. Обсирали Бейсік, а на зміну прийшов Пайтон з схожим синтаксизом. Ще попередню мову досконало не знаєш, а вже цікаво а що там в новій мові? Абсолютно нічого. На 5% цікавіші рішення, але прийдеться вивчати всі нюанси окрім мови. А якщо ще й мова бідна як JS, то прийдеться ще й фреймворки вивчати.

Достойного поки не бачу.

+1 за Rust. Приємно працювати з ним, особливо як для low-level мови.

Раст супер мова, але плюсери звикли страждати в рантаймі, а не в компайл-таймі, тож Раст їм не зайде

Плюсовики страдают и в компайл тайме *cough*template error message*cough*

6 скролів екрану, щоб зрозуміти що в темплейті щось не так

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

Опоную черговiй от такiй роботi тролингу, яку я вже читаю з 2002 як я пересiв з Turbo Pascal на Borland C++ 3.1 та потiм 5.0, дебiлдер i далi. За цей час в таких статтях С++ все помирає, то його С# нищiть, то Scala то, ще що небудть

Spiral

тут взагалi питання не до мови программуваня загалом, а до компiлятора clang i до його оптимiзацiй. Далi типовий синтетичний бенчмарк з замiром абстрактного Чебурашки в галактицi Андромеди, тобто з метою демонстрацi окремого випадку. Так само як з complile time regex було (додано до стандарту С++ 23 ).

Numba

Напищiть драйвер будь якого пристрою, опрерацiйну ситсему на Pyhon i поговоримо. Порiвнювати Python i C не корректно взагалi, це мови рiзного рiвня обстракцiй. Загального призначення i скрiптова прикладного призначення. Тобто Python потрiбен для пришвидшення программування прикладних програм, того, що нема сенсу оптiмiзувати — а треба створити швидко для рiшеня задачi накшталд тренування нейроної ciтки (а сам код мат моделi нейронки написано на С++), чи пакування RPM пакету (сам код LZMA2 пакування написано теж на С++). Так само не корректно порiвнювати С i Assembler

@cuda.jit

не вразило, от вам

      #pragma omp parallel for

Або Boost.Compute, CLBlast, Torch, Caffe, OpenCV тощо. OpenCL i CUDA C — з початку рiдний С API, тобто нульовий еффорд щоб почати щось робити.

ForwardCom

Зробiть на TASM, який ви витягнули з могильнику Borland, принаймi аналог vector з STL, щоб використовував шаблони. Можете навiть спробувати якийсь сучасний FASM, NASM або старий добрий GAS. Ще раз порiвнювати мови рiзного рiвня абстракцiї принципово не корректно.

Я складаю рівняння в SymPy,

Тобто для конкретно вашої роботи треба прикладний рiвень абстракцiй де Python пiдiйде краще, чому через це С++ помре ?

В програмуванні немає «абстракції» це слово украв із математики алгебраїст Стєпанов. Є автоматизація. Якщо не можете написати вектор на асемблері самостійно, покличте компілятор, він напише його за вас. Це не абстракція, це класична автоматизація. Машина робить роботу за людину.

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

За правилом древнiх перед вступом в дискус, треба з’ясування понять. Вiзьмем пояснення поняття вiд Боецiя i Арестотелья:

Абстра́кція (лат. abstractio — «відвернення, виведення»; введено Боецієм як переклад грецького терміна, використаного Аристотелем) — одна з найважливіших дій мислення,[1] теоретичне узагальнення, а також метод наукового дослідження, який полягає у тому, що суб’єкт виокремлює реальні необхідні загальні універсальні властивості чи ознаки об’єкту котрий вивчається, усувається від інших несуттєвих прикмет об’єкту отже не враховує його (об’єкта) неістотні сторони й особливості.

uk.wikipedia.org/wiki/Абстракція
Цей фiлософский термiн в дисциплiнi програмування визначено так:

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

uk.wikipedia.org/...​рагування_(програмування
Тобто assembler це найнижчий з можливих рiвнiв абстрагування, орiнтований на команди обладнання CPU,GPU, АЛУ тощо. Процедурнi ЯВУ типа FORTRAN,С,Pascal,Modula 2 вводять наступний рiвень — опреаторiв та пiдпрограм, потрiбного для складного ситсемного программування, створення операцiйних систем, драйверiв, керуючих програм. Cкриптовi та bytecode iнтерпритатори мови типу — Java та Python на рiвнi абстракцiй прикладних задачь, наукових та iнженерних обчислень, автоматизацiй бiзнес процессiв. С++ по середенi мiж системним i прикладним рiвнями абстракцiй, саме тому i популярний серед розробникiв десяткi рокiв. Створено мiжнародний стандарт, безлiч компiляторiв тощо.

Як ви уявляєте собі плюсера, який п’ятнадцять років вчився метапрограмуванню на плюсових шаблонах, що він це покине і почне щось інше вчити? Та ніколи у житті, замість цього буде сто причин, чому Раст гірший, які традиційно зведуться до пояснення, що unsafe Rust — це все ще Rust

Плюсовики, которые действительно 15 лет учились, переходят с радостью, так как прекрасно понимают уровень п****ца в C++ и качество value proposition раста.

Сто причин находится у тех, кто прочитал C++ за 21 день 15 лет назад и последующие 15 лет занимался манкикодерством. Прочитать им еще одну книгу 15 лет спустя представляется непосильной задачей, зато с поиском причин почему читать не надо проблем обычно нет.

Что за высер...
Если ты проспал, то могу сообщить, что новые версии c++ клепают одна за одной и там есть, что нового поучить и почитать.

в результаті потрібно знати так щоб від зубів відскакувало на співбесідах С++98, С++03, С++11, С++14, С++17, С++20 і ще й С само собою, бо С/С++ рівне нескінченність

При этом в каждой команде есть свой разрешенный список фич С++, которые можно использовать, потому что новые стандарты никто не осилил выучить, а самые одаренные гордятся тем, что используют подмножество C++ 98

В особо крайних случаях зазывают писать со словами «Идите, у нас modern C++», который на проверку оказывается C с классами.

С з класами, це мабуть, на мою скромну думку, самий ліпший варіант використання С++

Лучше свой раст пилите, чем про c++ чушь писать.

Ну я понял ваш подход в изучении раст — тратить 99%времени на обсырание с++, то тогда выучить раст вообще не проблема.

Одни пишут код на С++.
Другие пишут в инетах какой классный Rust.

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

Сделал дофига, конкретно на раст — 4 штуки, еще десяток на ноде, и дофига — на шарпе. В роли от простого разработчика до архитекта. К чему этот вопрос?

. К чему этот вопрос?

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

В вебщине — даже стоимость-время разработки веб апи на питонах лучше чем на Java/C# - какой С++/Rust окупит те расходы от замены ими Ноды?

в каких сценариях? при каких нагрузках?

раз вы архитектом были — то по памяти в пару предложений сможете описать: качественные отличия проектов, их признаки — когда Rust видится предпочительнее.
Я тоже архитектил. и сейчас в частности.

Никакой выгоды от замены Ноды в текущем проекте даже на Джаву не вижу. А стоимость разработки — вырастет в пару раз.
а на расте еще больше выростет.

Давайте аргумент — как архитектор архитектору ;)

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

Вы так говорите, будто веб апи на расте — это что-то типа веб апи на чистом си с ручным разбором хттп протокола. Это высокоуровневый язык, и скорость разработки от ноды не особо отличается.

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

Что и где я вообще оценивал? Вы разговариваете с голосами в голове. Я сказал, что Раст отлично подходит для веб разработки, и я лично на нем делал проекты. Я не призывал «бросайте пхп берите раст». Научитесь читать, что вам пишут, а не проецировать дискуссии из вашего воображения.

Вы так говорите, будто веб апи на расте — это что-то типа веб апи на чистом си с ручным разбором хттп протокола

либ для веб апи думаю нет только только на ассемблере.
кто ж и на чистом Си будет сам парсить?

хотя, может и на нем есть, для сурового ембедеда...

Что и где я вообще оценивал?

Вы заявили что у раста какие-то преимущества перед другими в создании веб апи.

и так и не ответили — какие.
экономия клаудных ресурсов на парсинге библиотекой хттп?
открою секрет — функции этого парсинга в том же презренном PHP — написаны на C, а не на PHP.

Я не призывал

Еще раз — вы сделали заявление без аргументации.
Вот я ее с вас и выпытываю. Вы ж — адепт, значит у вас есть информация, опыт, ..., ... — которого нет у меня

так расскажите.

а то что на любом универсальном ЯП можно написать веб апи — это не откровение.

как и то что вы начали сливаться.
аргументы давайте — на те что были конкретные — уже ответил.

открою секрет — функции этого парсинга в том же презренном PHP — написаны на C, а не на PHP.

Вот честно, лучше б они были написаны на PHP, может не было бы этого зоопарка уязвимостей

www.cvedetails.com/...​d-128/opec-1/PHP-PHP.html

если беспокоит этот зоопарк — есть другие платформы.
тоже с зоопарком
www.cvedetails.com/...​_id-19117/Oracle-JRE.html
Total number of vulnerabilities : 701

а у Пыхи — Total number of vulnerabilities : 155
Есть над чем работать, надо еще трудится Пыхе, догонять суровую Джаву!

и вот честно — «лучше» бы маргиналам не советовать лидерам — как им «лучше» бы.

а то вспоминается анекдот:
Три англичанина играют в преферанс. Вист — 10 фунтов. Один из них играет мизер, получает 4 взятки. Разрыв сердца, похороны, гроб несут его партнеры по последней пуле.
Один другому:
— Сэр Джон, а вы знаете, если бы покойный сэр Вильям тогда зашел бы в пику, а не в бубну, то мы бы ему дали 6 взяток вместо 4.
— И так неплохо получилось.

а у Пыхи — Total number of vulnerabilities : 155

По моей ссылке показаны только уязвимости PHP, позволяющие удаленное выполнение кода. В JRE таковых только 17.

а на даты и версии вы конечно не смотрели ;)
Пыху хейтить надо по умолчанию, да. Это признак глубокого профессионализма, да.

не так давно на одном проекте я прикрыл API самодельным бот чекером.
оказалось боты щупают
неприкрытый, наивно установленный Вордпресс, или дырявые плагины к нему
пробуют POST в ненастроеную от этого Пыху, на включенный eval рассчитывают
и
дергают сервлеты — от парочки известных фреймворков
и MS Exchange на тот момент любили очень.

Вы заявили что у раста какие-то преимущества перед другими в создании веб апи.

Ответил — скорость и потребление ресурсов получившегося приложения. Но вы почему-то начали мне доказывать, что цена разработчиков — это самое главное, и прочие банальности. При этом я нигде не утверждал, что надо всем бросать ПХП и переходить на что-то другое.

экономия клаудных ресурсов на парсинге библиотекой хттп?

Капец, вы даже ответ из трех строчек не можете правильно прочитать и понять. Не побочки ли это от ПХП?

Еще раз — вы сделали заявление без аргументации.

Знаете, я десять раз написал аргументацию, и вы десять раз ее проигнорировали. Наверное, стоит мне заканчивать спорить с вами

как и то что вы начали сливаться.

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

аргументы давайте — на те что были конкретные — уже ответил.

Успокойтесь уже, ПХП самый лучший, вы победили, удаляем раст с гитхаба

Звідки в плюсерів така зверхність до всіх Rust?

З чого ви це взяли.

На мій погляд, раст то дуже цікава мова, зі своїм підходом.
Не зрозуміло просто, чому коли спілкуются 2 розробника на раст, то все зкатуєтся до обсирання с++.

А я бачу, навпаки, як плюсери обсирають раст (найчастіше як «дуже повільний»).

Я, особисто, не маю нічого проти плюсерів, сам писав на ньому колись давно.

«дуже повільний» не найчастіший аргумент.
Найчастіші це:
1. Код на С++ важко переписати на Rust, бо плюсовий меморі менеджмент не мапиться напряму на растівський борров чекер — над кожним створенням/передачею/знищенням об’єкту треба думати заново і в іншій парадигмі
2. Недостатньо розвинена інфраструктура Rust: мало бібліотек, фреймворків, компіляторів, платформ, IDE тощо. Є ризик почати щось робити і не закінчити, бо якогось звичного плюсового інструменту не буде в расті, або його аналог буде не достатньо розвиненим чи стабільним

1. Код на С++ важко переписати на Rust, бо плюсовий меморі менеджмент не мапиться напряму на растівський борров чекер — над кожним створенням/передачею/знищенням об’єкту треба думати заново і в іншій парадигмі

Плюсовый мемори менеджмент здорового человека мапится относительно легко через /s/unique_ptr/Box, /s/shared_ptr/Arc.

Мемори менеджмент курильщика так же легко мапится через alloc:heap::alloc

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

Вы уверены что поняли как работают временные указатели?Ведь они многим упрощают жизнь являясь по сути универсальными уазателями, которые уже имеют возможность указывать на любой тип объекта: стековый, размещенный в локальной или обменной куче. Их поэтому и применяют для написания универсального кода, работающего с данными в функциях, когда тип размещения объекта не важен.
В случае если бы мне пришлось переписывать с цешки на руст я бы полюбому создал еще тонкую прокладку, которая экспортирует функцию Rust с тем же интерфейсом C, не забывая при этом удалить исходную функцию/модуль из сборки, чтобы компоновщик использовал код Rust вместо C.

руст

раст

В случае если бы мне пришлось переписывать с цешки на руст я бы полюбому создал еще тонкую прокладку, которая экспортирует функцию Rust с тем же интерфейсом C, не забывая при этом удалить исходную функцию/модуль из сборки, чтобы компоновщик использовал код Rust вместо C.

Проблема в том, что C ABI это очень маленькое подмножество Rust и C++. Если в C++ используются, например, темплейты, классы, то их через C интерфейс не протянуть, так же как и не протянуть большинство вещей из Rust (дженерики, трейты, енумы и т.п.).

Переписывание приложение с C++ на Rust, протягивая все фукнции одну за другой через C интерфейс потребует большого количества этих «тонких прокладок», которые на самом деле не будут тонкими, и в конце переписывания все эти тонкие прокладки будут удалены из кода, и возникнет вопрос, стоило ли их писать вообще или проще было переписывать большие куски приложения, или все приложение сразу, не заморачиваясь на поддержание прямой/обратной совместимости между кодом Rust и C++.

Кроме того,стабильный ABI позволит загружать библиотеки Rust другими языками (например, Swift) и позволит Rust взаимодействовать с библиотеками, написанные на других языках программирования. Крейты, отличные от Rust, могут быть интегрированы с наборами инструментов Rust; предоставление ABI также может позволить внешнему коду полагаться на Rust для задач, требующих высокой производительности.

При этом в каждой команде есть свой разрешенный список фич С++, которые можно использовать

це не так давно почалось таке, десь з 2004-го.
ранiше ото часи- Стабiльнicть. Джавiстiв стiльки не було.

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

Тому я на Java. І лише інколи читаю cpp, ще рідше пишу.

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

Бо купити машинний ресурс зазвичай дешевше, його легше масштабувати.

В високо нагружених сервiсах, компьютерних iграх, тренажерах, embedded i багато де ще — нi не дешевше. Iнодi дуже сильно не дешевше.

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

Дефект перекладу, маються на увазі Simulators. Наприклад Flight Training Simulation.

Якщо мова про домашніх юзерів які собі літають в новому MSFS — то це звичайна комп’ютерна забавка.
Якщо про професійні Flight Simulation Training Device — то навіть в розгар криптобуму парочка (або й пару десятків) додаткових RTX3090 ніяк не вплинули б на кінцеву ціну.

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

«Переналаштувати на літак нової серії» це і так нова сертифікація. Чи, вірніше, кваліфікація)

Як я чув з софтом усе ніби швидше набагато. Існує документ як робиться така сертифікація www.easa.europa.eu/...​ion-training-devices-fstd і обслуговування.

Дуже сильно впирається в конкретне national authority навіть в рамках Євросоюзу де правила, наче б то, єдині і виставляє їх EASA.
А все тому в кваліфікаційних тестах багато суб’єктивщини — як з інспектором домовишся так і буде, відповідно, конкретна процедура апдейту софту або заліза впирається в те, про яку країну мова.

Embedded це широке поняття, це може бути і 4-бітний проц з мікрохвильовки і лінукс, що крутиться на 2+ ядрах, кожне на 2ГГц з 2 Гб пам’яті.
В першому випадку простіше на С, ассемблері писати, в другому навіть на пітоні. Для С++ тут майже немає місця. Тим більше в критичних ситуаціях я можу викликати С код з пітону або джави.

Embedded це широке поняття

Завдяки HR-ам. Embedded залишився лише там де пишуть дрова, або зовсім лоу-левел програмування якесь з хардваром, навіть soft-realtime ECU у автомобіль це вже не ембеддед, а звичайне прикладне програмування, з деякими «але».

Для С++ тут майже немає місця.

:D

нє, ну є звичайно окремі потуги в інтернеті писати на С++ під стм32, але в цьому немає особливого сенсу

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

та ладно ulibc++ в допомогу і хрести на стм

та ладно, он шукють в сусідні темі читача УАРТ на удаві з малини, труь ембедедед

Серединку пропустили навмисно? Ті ж роутери, на яких для джави чи пітону не вистачить флеша й оперативи, а лінух нормально собі бігає. І торенти усякі запускаються. І оті торенти, та купа роутерної логіки — на С++. Це як приклад ембедеда.

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

Ніщо так не міняє світогляд, як рахунок за AWS.

Я не сказав що така ситуація усюди. Але левова доля софту — саме така. Важливіше щоб він працював, і працював передбачувано. Швидкість — не головний фактор для >99.99% програм.

Але є величезний ринок саме для швидкого софту. І С++ звідти не піде мабуть ще років 50 щонайменше. Бо є такий софт, яким користуються багато. Є такий, який працює безперервно, і має працювати автономно. Є безліч заліза, яке працює від батарей та батарейок.

Основна проблема ринку швидкого софту — відсутність легких у використанні метрик, які були б доступні кінцевим користувачам. Коли це з′явиться, може статися тиха революція, і такий хлам як Вайбер чи Вотцап — підуть на звалище історії попри популярність.

е для швидкого софту. І С++

а є ще «бистра Настя»

Коли це з′явиться, може статися тиха революція, і такий хлам як Вайбер чи Вотцап — підуть на звалище історії попри популярність

А до чого тут ці флуділки?

Автор нагадує школяра — «я ж програміст». Окрім власних вигаданих слів не сказав нічого, що мало б сенс.

Дочитав до слів «поліноміальна модель»

медаль Назару, я навіть 1ше речення ніасіліл, зразу в камєнти ушол

Мені шкода що мої факти ображають ваші переконання.

Ваші факти засновані на припущеннях, що для C++ інших застосувань крім super-high-performance-in-realtime не існує. І що все робиться в клауді, де це супер-важливо, а якщо це не важливо, то і C++ не потрібен. Ви поширюєте свій нішевий досвід на всю галузь, і це типова помилка сприйняття. А між іншим, є ще desktop та embedded, де в першому випадку бажана крос-платформеність із коробки (привіт, Qt), а в другому — ощадливе застосування ресурсів при високих вимогах до UI (знов, привіт Qt). Тому ні, допоки хромбукі не витіснили звичайні PC, а цивілізація не повернулась до вогнищ та печер, C++ точно не помре.

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

Сила Раста не в мікрооптимізаціях і суперефективному суперрозумному компіляторі, а в тому, що він примушує програміста наводити порядок у голові, по можливості виражати інваріанти кодом, а не знаннями у одній-єдиній голові, та ставитись до памʼяті більш-менш уважно.

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

Раст сам по собі дуже крутий. Якщо глянути на результати щорічного опитування С++ програмістів, а саме на частину «що вас фруструє» (isocpp.org/...​cpp-developer-survey-lite), то не важко помітити, що Раст лікує більшість зазначених там проблем.

Але це все ще робота над помилками. Це, в термінах Форда, faster whorses. Це хороший і правильний крок від минулого, але ще не крок у майбутнє.

whorses

Ааа это задумывался такой гибрид или как??

насправді, Rust нічого не лікує....через пару років буде ще одна «кохана мова», ще більш коханіша чим коханий Rust ... але ОПП/ООД головного моску воно не вилікує

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

Або не приходить. Або приходить коли ніхто не чекає.

З пам’яттю взагалі непросто. Наприклад, в Review Guidelines on Software Languages for Use in Nuclear Power Plant Safety Systems (www.nrc.gov/...​ontract/cr6463/index.html) перше правило роботи з динамічною пам’яттю — не використовувати динамічну пам’ять взагалі.

І отримуємо старенький сабсет embedded C++. Без STL але з ООП.

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