Rust и двусвязный список

Для протокола: в эпиграфе мемории указано несколько иное мнение об относительной ценности алгоритмов и структур данных.

Тут нет противоречий. Эпиграф Мемории отражает эмпирически тот факт, что основная описательная сложность сосредоточена в «данных». И, соответственно, их правильное структурирование – залог успеха.

Просто мы, в рамках профессионального программирования, изо дня в день решаем одни и те же задачи. Которые уже были давным-давно решены до нас. И под эти задачи уже предложены и алгоритмы, и структуры данных, и всё это упаковано в библиотеки и фреймворки. А мы просто это всё комбинируем под новые требования. Вот и всё наше «программирование».

А вот стоит немного отойти в сторону от протоптанной дорожки, и начинается хардкорная философия вида «что есть что».

И твой слайс с атомиком будет уже неэффективным, если ты делаешь какую-то прикладную параллельную обработку данных.

Давай конкретно, что тут неэффективно.

Если ты там будешь продолжать думать в терминах атомиков, то умрешь в процессе отладки.

С чего бы? Там я буду думать в терминах слайсов.

Справедливости ради, у растодизайнеров за корректностью использования легкого невладеющего слайса следит система типов. И это, всё же, не совсем характеристика дизайна самого языка.

Кстати, я согласен, что паттерн этот сам по себе мощнейший (в умелых руках). На мой взгляд, на пару с View один из самых ценных для дизайна структур данных.

А вот стоит немного отойти в сторону от протоптанной дорожки, и начинается хардкорная философия вида «что есть что».

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

Давай конкретно, что тут неэффективно.

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

Тут, опять же, если у тебя какая-то одна структура данных, то можно всё мощь своего разума сфокусировать на ней, и таки выдать что-то гениальное. Но обычно структур данных нужно много разных. И к каждой будет еще и множество различных паттернов обращения. Распараллеливать всё это по отдельности ты задолбаешься.

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

Отнюдь не всегда. Иногда можно вообще не думать.

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

На синхронизацию читателей с писателями мне плевать — главное чтобы ordered_multimap не теряла полезные вставки и не получить segfault. Все равно потребуются новые проходы по коллекции, пока она не зафиксируется.

UPDATE: s/ordered_map/ordered_multimap/g

Тут один активный участник этой дискуссии любит приводить пример: иерархия классов для геометрических фигур. Проблема тут в том, что если мы хотим какую-то действительно эффективную иерархию, то придется уходить от привычной нам системы типов, возвращаться в теорию вероятностей к кодам, заходить в психофизиологию восприятия (чтобы определить существенную информацию), а потом еще и в железо для аппаратной поддержки новых кодов и структур. И это еще так, всего лишь пена.

У меня генетический алгоритм минимизации не важно чего. Я беру обоих родителей из ordered_multimap

У тебя оно в несколько потоков одновременно обходит и мутирует коллекцию?

У тебя оно в несколько потоков одновременно обходит и мутирует коллекцию?

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

обхожусь одним потоком.

Ну вот о чем и речь. Мы о разных случаях говорим.

Но и там проблема с инвалидацией итераторов, которая тупо решается пока 2-й копией.

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

Мы о разных случаях говорим.

Об одинаковых. У меня 1 поток только потому, что я не умею. А по хорошему надо много потоков.

Отнюдь не всегда. Иногда можно вообще не думать.

Я как раз про это говорю. Если у тебя один поток, то ты можешь не думать, как разносить писателей с читателями. У меня в R9 5950X 32 логических потока (логический поток – это до 50% к физическому на memory-intensive нагрузке). И это – настольная машина. В этом году выходят серверные процессоры с 96-ю физическими ядрами и 12 каналов в память. А через несколько лет у нас будут уже 256 ядер. Так что думать нужно, и думать нужно хорошо))

Блин.

Сколько раз говорить, что ИНОГДА и в МНОГОПОТОЧКЕ можно не думать о синхронизации читателей с писателями — например в моем генетическом алгоритме. И то, что я его сейчас реально делаю в однопоток — не играет роли совсем вообще никак.

Сколько раз говорить, что иногда и в МНОГОПОТОЧКЕ можно не думать о синхронизации читателей с писателями

иногда

Когда? Если у тебя ПСД/ФСД, то, действительно, не надо. Этот вопрос вынесен на этап слияния версий, созданных разными писателями.

Когда?

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

давай мне любую проблему синхронизации читателей с писателями (и даже с итераторами) — и я скажу, почему она у меня НЕ СТОИТ, причем не стоит именно в многопоточке

да, и версии мне тоже не нужны, и сливать (мёржить) мне их не надо

Ну, давай попробуем. Ты обходишь одну и ту же (не копии) коллекцию в несколько потоков и, проходя, мутируешь её элементы по любому принципу.

Нет, я не мутирую ее элементы. Я их вставляю и удаляю пачками с конца (про что я писал).

Я предлагаю тебе найти проблемы именно в описанном мной генетическом алгоритме минимизации, а не вообще.

Правда, ты можешь сказать что «читатель в итоге (eventually) обязан увидеть результат, записанный писателем» — это проблема синхронизации. Я с такой терминологией не согласен. Если это свойство нарушается, то как мы можем писателя и читателя называть писателем и читателем?

щас запощу псевдокод

Нет, я не мутирую ее элементы. Я их вставляю и удаляю пачками с конца (про что я писал).

Но это тоже мутирование коллекции. Как это будет происходить? Ты огораживаешь коллекцию R/W блокировкой?

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

Поразительный ответ! Вопрос - что именно slice позволяет, чего vector НЕ позволяет? Ответ - slice позволяет то, что не позволяет vector…

Папа, где море?… А что это было? - Море! Где?

Не могу вести дискуссию на таком уровне!

Но хорошо ли это получилось у дизайнеров раста? Не знаю. Давай запость сюда свой код, который компилятор не принимает.

Довольно глупо писать сюда код который компилятор НЕ принимает. В этом нет смысла.

Я просто говорил про тип данных, который отсутствует в RUST и который тем не менее является наиболее часто используемым по факту в любой программе! Тот же файл это массив байт в общем случае. Это мать его НЕ вектор, это НЕ список. Это массив!

Размер файла НИКОГДА не известен заранее. Даже имя этого файла не известно. Но при чтении любого файла создаётся буфер куда собственно файл и читается. И для этой классической операции в языке НЕТ типа данных. Читать файл в вектор это как микроскопом забивать гвозди. Т.е. в принципе возможно… Но зачем?

прочитайте последнее предложение моего поста про лисп. и много думайте.

Это плохой ответ. Вы НЕ в состоянии донести свою мысль буквами. Зачем Вам участвовать в дискуссии? Теоретически любого можно отправить в библиотеку. И Вас тоже…

Либо старайтесь лучше, либо не надо писать вообще.

Либо старайтесь лучше, либо не надо писать вообще.

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

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

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

ВСЕ! Говорят, что это проблема и ВСЕ это понимают и тут выступает один, который проблемы НЕ видит и НЕ понимает приводя непонятно к чему ручное управление памятью. Проблема ЕСТЬ И в ручном управлении памяти! Она индифферентна к этому вопросу.

Попробуйте думать… Хотя бы сформулируйте то, что для многих является проблемой и что Вы считаете НЕ проблемой. Скорее всего не выйдет…

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

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

Боже… как все плохо. А Вы в Деда Мороза тоже верите?

Проблема ЕСТЬ И в ручном управлении памяти!

не говорите загадками! выкладывайте же эту проблему немедленно

Но это тоже мутирование коллекции.

Мутация коллекции это совсем не то же, что мутация ее элементов.

Как это будет происходить? Ты огораживаешь коллекцию R/W блокировкой?

Я требую от коллекции определенных свойств.

Пусть для простоты коллекция будет ordered_map (хотя там ordered_multimap может быть лучше).

Мне нужно, чтобы:

1. Любой читатель (точнее: читатель-итератор по коллекции) в итоге (eventually) увидел в orderd_map вставку любого писателя; читателей-итераторов будет 2 шт. для каждой нити

2. ordered_map могла в итоге (eventually) показать отсутствие прогресса (т.е. что писатели в нее вставляют только те элементы, которые в ней и так есть). (Это весьма своеобразное свойство мутабельной коллекции в целом. Понятно, что речь может идти об инстансах, но мне достаточно 1 инстанса на коллекцию).

3. (послабление) несмотря на то, что это ordered_map, элементы имеют право реально быть в нескольких экземплярах, так как там семантика значения. Но при этом в разумных пределах несколько (например, 2*количество_нитей, и только нововставленные)

Вроде больше мне ничего и не надо.

Псевдокод завтра. Там оказывается подумать надо.

У вас есть элемент списка строк (строки могут быть любого размера). В списке N элементов…

Вы НЕ ПОНИМАЕТЕ что пишите!

Вам объясняют на уровне теории, как в высшей математике! Вам это говорит Бьерн Страуструп! А Вы пытаетесь возражать приводя в пример частный случай, который НЕ релевантен.

Давайте Вы окончите высшее учебное заведение. Пройдете минимум 2 курса высшей математики и потом вернётесь к вопросу. Самому будет смешно. Я гарантирую.

Даже здесь Вам это говорят разные люди и Вы отказываетесь от реальности.

Нет. Вы неправы. На этом можно поставить точку.

Вам это говорит Бьерн Страуструп!

а вот теперь настал момент показать скан паспорта, есть подозрение что вы вовсе не Бьерн.

Поразительный ответ! Вопрос - что именно slice позволяет, чего vector НЕ позволяет? Ответ - slice позволяет то, что не позволяет vector…

Чувак! А ты знаешь что в с++ class, нужен только для того, чтобы НЕ ДАВАТЬ программисту обращаться к приватным/защищенным членам? И кроме этого ничего нового по отношению к struct не дает.

И кроме этого ничего нового по отношению к struct не дает.

дает. счас Страуструп покажет паспорт и доложит Вам зачем он все это придумал.

Не дает. Речь идет о классе в С++ по отношению к struct в С++, а не по отношению к struct в С.

И кстати что там с++ может vtable сформировать, а программист — нет, это слабость и недоработка языка. Недостаток рефлексии и метапрограммирования.

Мутация коллекции это совсем не то же, что мутация ее элементов.

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

Я подумаю, но это не совсем про мой случай. Мне реально не нужно мутировать элементы.

счас Страуструп покажет паспорт и доложит Вам зачем он все это придумал.

это все ладно; мне интереснее, где Страуструп по-русски так шпрехать научился

Прихожу сюда и мне начинают объяснять, что список не нужен и что я не понимаю, что такое O(). Исходя из этого, не вникая в дальнейшие детали, можно сразу прийти к выводу, что в Расте ничего особо умного на этот случай нет.

0. У Вас в голове совершеннейшая каша. Вы путаете совершенно разные вещи чуть ли ни в одном предложении. До войны это называлось - в огороде бузина, а в Киеве дядька…

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

Например классический выход за пределы массива в C. Ничто на свете не может запретить добавить 1 к последнему индексу в массиве и попытаться туда писать или читать. И так далее.

2. Вы совершенно правильно указали, что при участии объекта в разных списках ИЛИ когда один и тот же список обрабатывают в 2х и более потоках могут появиться ситуации, когда в одном потоке объект ещё есть, а в другом уже нет. И отладить это почти невозможно.

3. Нужен список или нет это вопрос мнения. Оно у людей разное и это нормально. Мне список НЕ нравится. Другому нравится.

4. Проблемой является исключительно двусвязный список! Он может нравится или нет, но это проблема и RUST эту проблему проявляет за счёт механизма владения. Решить эту проблему можно исключительно тем, чтобы отдать указатель на объект кому-то третьему, а двум объектам которые ссылаются на данный объект как на предыдущий или последующий дать ссылку на этот третий объект БЕЗ механизма владения вообще. Т.е. сам такой объект - массив указателей например будет держать в себе ссылки на все члены списка. Но простого и хорошего решения этой проблемы нет. И по этому проще признать данный тип данных проблемным и НЕ использовать.

5. То что Вы не понимаете ничего про O() это факт, но это снова совершенно другой вопрос НИКАК не связанный с предыдущими.

Вам никто не мешает почитать книги и подумать. Доказывать тут что-то бессмысленно. Вы начисто отказываетесь слушать и слышать.

И кстати что там с++ может vtable сформировать, а программист — нет, это слабость и недоработка языка. Недостаток рефлексии и метапрограммирования.

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

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

Короче завтра уточню, вместе с псевдокодом.

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

Ага, мне только дай в руки... как тебе наследование класса Derived от неограниченного множества классов Base<n>, где n — целое, причем каждый из Base<n> может создаваться прямо в рантайме (а не compile-time)? (Для каждого виртуального метода побеждает последний из Base<n>, если что )

..как тебе наследование класса Derived от неограниченного множества классов Base, где n — целое, причем каждый из Base может создаваться прямо в рантайме (а не compile-time)?

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

Для этого их прошивают 4 интрузивными списками. Получается каждый человек в 4 списках.

Вот я и говорю… кто-то когда-то приведет пример использования списка, где ничего другое работать не будет? Похоже что таки нет. Никто и никогда.

Для справки. Вы только что привели классическую задачу из SQL. Таблицы в SQL представляют собой по сути 2-мерный массив. И все как-то работает и ответы находятся сразу в несколько потоков… И это индустриальный тип данных. Т.е. отработанный на многих петабайтах в миллионах организаций.

Если кто-то начнёт прошивать это какими то списками, то объем полезных данных будет составлять дай Бог если 10% во всей этой куче Д. И о всяких там процессорных кэшах можно будет с лёгкостью забыть. Особенно весело это получается в случае с датами и например китайскими фамилиями типа Ли.

Лучше составлять списки из Исландских вулканов… Хотя бы не так жалко…

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

гы-гы-гы

а если я в Base поставлю 5 скучных методов, которые делают eval lua-шных скриптов, вынутых из БД, то ты спокойно пройдешь мимо, ничего не заметив

хотя результат будет тот же

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

Причём тут массивы???

Я уже писал выше, что современные языки исказили все понятия. У них вектор это массив и так далее.

Я задал очень четкий вопрос - что именно Вам нужно в списке, чего НЕТ в векторе? - Если не можете ответить - зачем лезть в дискуссию? Не ведите себя как еврей. Не отвечайте вопросом на вопрос.

Про массивы я написал лишь то, что их НЕТ в RUST. Статические массивы меня не интересуют вообще.

Как можно на RUST сделать на массивах условный компилятор LISP, если их там нет?

а вот теперь настал момент показать скан паспорта, есть подозрение что вы вовсе не Бьерн.

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

Чувак! А ты знаешь что в с++ class, нужен только для того, чтобы НЕ ДАВАТЬ программисту обращаться к приватным/защищенным членам?

Чувак! Я знаю сколько у тебя пальцев на руке, хотя я тебя никогда не видел и надеюсь не увижу!

P.S. Я надеюсь хотя бы Вы отхлебнули пивасика, прежде чем Выдать такую откровенность? Думаю минимум 3 бутылки.

Вот я и говорю… кто-то когда-то приведет пример использования списка, где ничего другое работать не будет? Похоже что таки нет. Никто и никогда.

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

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

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

Годятся. Никто не мешает мне бегать от 2-го указателя к 1-му, а не так, как решили за меня растодизайнеры.

Твой подход «давайте сломаем всю защиту, а я в ответ пообещаю корректную работу программы» в расте реализуется через unsafe. Дерзай.

Да, кстати — по безопасности ниток замечания есть?

Я выше написал. Работа одновременно с массивом означает возможность частичного обновления. Раст не знает о том, что ты обещаешь позаботиться о корректности сам, через проверку атомика, поэтому даёт тебе отлуп.

Кстати, описанное тобой как бы в принципе работать не будет. Ну вот у тебя есть атомик для границы. Один поток проверил его и работает над своим рейнжем. Второй поток увидел, что ему мало данных и подвинул на единицу, добавив 1 айтем себе. Всё, поломано.

Как же я пропустил-то…

ЕТУ! Это НЕ самостоятельный тип данных. Вы говорите о том, чего не понимаете!

«жопа есть, а слова нет».

У типа есть имя («[T]», а не «[T; n]» ), есть особая реализация (2 указателя вместо одного), есть особый способ при работе (проверка размера в рантайме через второй указатель).

На каком основании вы заявили о его несамостоятельности? Перед тем как отвечать, вспомните о трейте-маркере Sized и о тех ограничениях, которые отсутствие его накладывает.

Боже… Жуть то какая… Человек даже не понял что такое вектор. Нафига делать из вектора slice, если УЖЕ есть вектор? Что мне даёт slice, чего мне НЕ дает вектор?

Я тоже так могу: «Зачем мне иммутабельная ссылка, если уже есть мутабельная?». Видите, не нужно никакого таланта, чтоб задавать идиотские вопросы.

Давайте посмотрим на другие языки с динамическим размером массивов. Не, теоретически есть C с его фишкой вставки в конец структуры массива размером 1 элемент, и аллокацией sizeof(struct) + sizeof(itemtype) * (N - 1)., но это хак. В остальном тип «массив неизвестного размера» - это всегда либо каст из массива статического размера, либо то что существует в виде ссылки на область в куче. Раст реализует этот тип поведения.

Вектор в данном случае используется как билдер для варианта «слайс динамического размера в хипе». Операция заимствования слайса из вектора или конвертации вектора в Box<&[T]> бесплатна.

Если вы пишете какой-то кровавый эмбедд, такой, что вам жалко линковать реализацию всего вектора (хотя нет ничего проще вектора вообще-то), ну напишите свою функцию, выделите память, проинициализируйте, а потом return slice::from_raw_parts(ptr, n)

Создаёте проблему на пустом месте.

списки это удобно. еще удобно носить на болоте сапоги.

«во-первых это красиво» (с)

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

я вот кстати вожусь с маленьким лисп интерпретатором…

Насколько же велико должно быть самомнение и самолюбование, чтоб ради чувства «работаю с языком-прародителем всех парадигм программирования» в 2022 ковыряться в этом копролите? Нет, серьёзно, уже минимум лет 30 прошло с момента понимания, что главное в языке программирования - это читаемость кода человеком, а с момента, когда скобочки начали дублировать отступами чтоб хоть как-то обеспечить читаемость, прошло и того больше. Но дуракам закон не писан, давайте обмазываться лиспом. Не хаскелем, который претендует на математичность. Не каким-нибудь джаваскриптом, который позволяет вот так же колхозить что угодно на лету. Ни даже какой-нибудь современной переделкой, с человеческим синтаксисом. Нет, сектантам подавай тот самый язык, спроектированный в момент, когда IT-мысль была на околонулевом уровне и главным требованием была работа на машинах того времени, с памятью на несколько тысяч байт.

и совершенно не понимаю, куда вы там сможете вставить массивы. их там просто нет. ни одного. а вот списки - там везде.

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

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

На каком основании вы заявили о его несамостоятельности?

На том простом основании, что сначала нужно создать вектор, инициализировать его N кол-вом элементов и только потом можно создать slice на этой основе. Я задал Вам простой вопрос. Зачем мне создавать slice, если у меня УЖЕ есть вектор, который мне НЕ нужен. Вектор делает больше и медленней, чем массив - array. Кстати массив это тоже неверное слово. В оригинальном языке означает совсем НЕ то что понимают под словом array. Я даже не знаю есть ли на русском аналог слову array.

Slice это решение самостоятельно созданной проблемы. Если проблему не создавать на ровном месте, то и slice нафиг никому не нужен.

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

Каак? Указатель это опасно? - Давайте от него откажемся и придумаем ссылку. В С под ссылкой понимали нечто совершенно другое. Но теперь оопс и у нас нет указателей. Т.е. они есть всегда будут пока есть процессоры. В общем бардак.

Зачем мне иммутабельная ссылка, если уже есть мутабельная?

НЕТ. Вы так не можете. Задавать правильные вопросы нужно уметь. Правильный вопрос на эту тему ЕСТЬ. И он звучит так. Зачем мне мутабельные данные или немутабельные, если есть тривиальное слово - константа! которое с каких-то фигов перестало быть константой. И пришлось придумывать новое имя.

В нормальном языке должно быть так:

const int32_t a = 5; int32_t b = 10;

Константные данные НУЖНЫ любого типа. А вот mutable это однозначно изврат. Как я уже написал выше. Люди обделались в одном месте и потом стали исправлять свои же созданные ошибки.

Давайте посмотрим на другие языки с динамическим размером массивов

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

По мимо прочего я писал выше, что динамический размер и динамический размер это 2 разные вещи! Есть время инициализации и время использования. Вы какой имеете ввиду?

«в хипе»

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

хотя нет ничего проще вектора вообще-то

есть. Это просто отсутствие знаний.

Если вы пишете какой-то кровавый эмбедд

Это никак не связано. Я просто хочу, чтобы простые вещи делались просто, а не через одно место!

Если для элементарных вещей надо танцевать с бубном каждый раз, то в итоге любая программа становится сложной и прочесть ее становится трудно. Кол-во ошибок из-за этого растёт.

Прочитайте про язык ZIG и как он решает проблемы созданные на пустом месте RUST-ом. Хотя это не избавило его от проблемы с отсутствием массивов. Это какая-то общая проблема.

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

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

То что Вы предлагаете со slice это голый изврат на пустом месте. Мало того как я уже 10ый раз повторяю бессмысленный изврат. В каждой строчке кода должен быть смысл и логика. Если их нет, то и писать их не нужно.

Linus довольно четко выдал свое мнение и о C++ и о других языках. И ему можно верить. Врядли кто-то писал нечто более стабильное, чем ядро Linux. И когда говорят, что на С писать большой проект нельзя и все будет падать и выходить за пределы массива, то можно только дать ссылку на исходники Linux. Это должно заткнуть любого.

Хотя во многом C элементарно устарел. И точно можно делать вещи гораздо удобнее при той же скорости выполнения. Некоторые концепции в С просто убоги и примитивны и сильно тормозят на этапе компиляции и сборки.

Откровенно говоря RUST хорош НЕ как язык, а наличием CARGO. По сути именно cargo вытаскивает rust на другой уровень. Именно по этому появилось столько копий cargo под с++.

В С++ ситуация ровно обратная. Его убивает ужасный cmake. Вся система сборки C/C++ уродлива на столько, что вообще не лечится. И какой бы С++ не был прогрессивный, но сборка программ на нем это средневековые пытки.

Есть только одна проблема. От С/C++ невозможно отказаться! Можно придумать супер гениальный язык программирования. Но вся кодовая база и все библиотеки идут только под эти 2 языка.

Допустим Вы хотите писать под GPU. И все. У вас по сути НЕТ выбора. И нравится нам это или нет, но GPU это будущее. И если ваши программисты УЖЕ используют С/C++ вынужденно, то какой смысл городить огород на другом языке?

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

Потом С++ быстро развивается. И уже есть C++23, который не факт, что чем-то хуже RUST. По крайней мере его достоинство в том, что он не запрещает создать массив простым malloc() в одну строку. Или использовать любой другой allocator по выбору.