Вышел Rust 1.0

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

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

Во-первых, цель такого компилятора только в том, чтобы превратить сложный синтаксис C++ в более простой. Не меняя очень мощной семантики плюсов.

В каком месте у плюсов сложный синтаксис? Как его можно упростить?

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

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

В каком месте у плюсов сложный синтаксис?

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

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

C++

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

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

Лучше используй вектор.

Тогда уж Deque, он по всем параметрам лучше либо не хуже чем вектор (да и перемещение элементов при расширении/сжатии делать не нужно), кроме совместимости с сишным char* по расположению данных в памяти. Ой, тоже нельзя, Он тоже может быть через список реализован...

C++

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

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

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

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

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

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

с++

с++

Новый стандарт С ты тоже в новый язык запишешь?

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

Я ошибаюсь, или таки надо переписывать?

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

Да. А где FFI сделан по-другому?

Да. А где FFI сделан по-другому?

В C++ :]

А где FFI сделан по-другому?

В C++ :]

Си++ - это надмножество Си89, так что там просто нет Cи FFI.

Не хочу спорить по таким вопросам.

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

https://github.com/crabtw/rust-bindgen

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

Какую «такую» - поддержку препроцессора и синтаксиса Си для объявления функций и данных? Да уж, «маленькая фича».

Генератор биндингов - вполне нормальный подход.

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

Тем не менее иногда эта структура бывает очень полезна. Кроме того, rust позиционируется как язык для системного программирования, а в системном программировании двусвязанные списки используются чаще: https://github.com/torvalds/linux/blob/master/include/linux/list.h

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

Вот плюсисты доморощенные и занимаются только тем, что «выжимают из железа всё» (пепси). :-)

Дорогой нонимоус. Не надо сравнивать свой потенциал с потенциалом Гугла. (В части бабла, в первую очередь.) Это раз. А два — одно дело /переписать/ //работающую// систему на C++ или на C с высокоуровневого языка, где программа приняла свой понятный облик, а другое дело зарабатывать геморрой и нервный срыв, ваяя на C++ с самого начала. :-) И я могу понять, когда разработкой занят 1 супер-гениальный и супер-опытный программер, который уже закалён кознями убогого языка с паршивой семантикой, который уже написал кучу этих ваших идиотских фабрик и визиторов, и вот он, будучи 1, имея 1 голову, в которой и будет держать весь свой новый просджект на Цепепе, вот он имеет шанс что-то напЕсать. В командной же разработке всё иначе - люди разной квалификации, разной продуктивности, разной психики, в конце концов, и вот когда эти люди пишут на Цепепе с самого начала, без прототипа, тогда это уже признак сомнительного джедайства, который оканчивается, скорее всего фейлом :-) :-) (терминирующие смайлики).

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

Кстати, если я всё правильно понял, то проблема с двусвязным списком в Rust в следующем.

Списком подразумевается, что управляющими блоками владеет весь контейнер (посредством обязательства вручную освобождать блок, когда все его элементы удаляются из списка), а не левый или правый сосед блока (посредством scoped-ссылки на него, которая при смерти автоматом освобождает объект, на который ссылается).

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

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

«Нормальным» решением (без «тормозящих» счётчиков ссылок и «небезопасного» ручного удаления) по идее будет только статически-выводимый аналог shared_ptr, что вообще может оказаться невычислимой задачей (а значит, не безопасной). Проблема актуальна, по идее, не только для списка, но и для любой другой структуры данных, где контейнер не имеет ссылок на все управляющие блоки (не знаю, является ли это определением связного списка).

Всё правильно понял?

Как раз таки семантика C++ - это ужас из ужасов из ужасов. И как раз этот ужасный ужас и является причиной того, что для Цепепе нет ни одной IDE с возможностью качественного рефакторинга, что, учитывая ООП по Страуструпу, где сначала надо думать о классах и об их общости, вместо того, чтобы сначала думать об алгоритмах, является центральной и необходимой функцией IDE для Цепепе. Но, увы, твой любимый Цепепе награждён ужасом-семантикой :-)

Ага, и этот «тимлид» (хотя бы он) и должен использовать кроме Цепепе более абстрактные языки, чем Цепепе. Иначе это не тимлид, а дугачок :-)

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

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

Ложь. C++ - надмножество C11. Ты немного устарел. :-)

В Rust в принципе нет понятия ручного освобождения объектов (да?),

Нет, есть. https://doc.rust-lang.org/std/mem/fn.drop.html
Суть проблемы куда проще:
* Может существовать только одна владеющая ссылка
* Заимствующие ссылки должны всегда быть корректны, и это проверяется на этапе компиляции
В двусвязного списка две ссылки. Одна из них может быть владеющей, а вот с другой и начинаются проблемы.

Вы немного не правильно поняли суть проблемы, проблема не в том как сделать двусвязный список, проблема в философии самого языка. Язык позиционируется как безопасным (по крайней мере по работе с памятью) - но при этом в нем есть костыль в виде «unsafe», и как оказывается без этого костыля нельзя построить такую простую структуру как двусвязный список (а также зацыкленный список, все возможные linked map, B+ деревья и вообще есть глобальная проблема иметь два долгоживущих указателя на один объект). В результате есть опасность что штатный набор фич раста не достаточный для многих задач, как результат народ будет тыкать unsafe на каждом шагу - в результате получим тотже С/С++ но с другим синтаксисом ....

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

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

C++ - надмножество C11

С++11 - надмножество С11? С++03 его надмножество? Вау.

Ты немного устарел. :-)

Я просто знаю больше тебя. Но да, ты моложе - гордись этим.

В Rust в принципе нет понятия ручного освобождения объектов (да?),

Нет, есть. https://doc.rust-lang.org/std/mem/fn.drop.html

drop - не освобождение памяти, а вызов деструктора.

С++11 - надмножество С11? С++03 его надмножество? Вау.

Как понять это? C++ - это язык, последний стандарт которого принят в 2014 году. C - это язык, последний стандарт которого принят в 2011 году. Для всех адекватных, включая Страуструпа, C++ - надмножество C (C11).

Я просто знаю больше тебя. Но да, ты моложе - гордись этим.

Хехе :-)

Ага... И я так понял, что владеющая ссылка обязана существовать, иначе объект должен быть освобождён как никому не нужный. Поэтому нельзя блоки списка перевязать между собой каким-то невладеющими ссылками и всё делать по-старинке. Правда, не особо понятно, как это сочетается с ручным освобождением в виде Drop.

Покажи мне _Generic в крестах.

sudo - это костыль?

С++11 - надмножество С11? С++03 его надмножество? Вау.

Как понять это?

Пойми это правильно. Если можешь.

C++ - надмножество C (C11).

Про Generic тебя уже спросили; я спрошу о _Complex и flexible array.

И я так понял, что владеющая ссылка обязана существовать, иначе объект должен быть освобождён как никому не нужный.

Да. Владеющая ссылка — объект, по которому оценивается корректность заимствующих ссылок. Пока владеющая ссылка существует и сам объект неизменен, заимствующие ссылки остаются корректными.

use RefCell Luke. В расте можно либо безопасно, через RefCell, либо быстро, но через unsafe {}. Два стула кароч. Этот момент в расте слабоват, но преимуществ у него все равно больше.

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

В самых первых сборах раста так и делали, кстати. Отключаемый сборщик мусора. Но потом, почему-то, отказались от этой затеи.

Ты не меня спрашивай, а Страуструпа, ведь это именно его заявление:

With minor exceptions, C++ is a superset of C (meaning C11; [C11])

Сказано же тебе, with minor exceptions. Поэтому в вопросах, касаемых C++, я склонен доверять Страуструпу, а не людям с форума ЛОРа :-)

Про Generic тебя уже спросили; я спрошу о _Complex и flexible array.

Он даже не надмножество С99, хотя неполная совместимость с этим стандартом есть.

(другой анонимус)

Тебе пропишу читать «Дизайн и эволюция C++».

Сказано же тебе, with minor exceptions

Ну если так рассуждать, то C++ всегда будет надмножеством С с «небольшими исключениями» :)

(другой анонимус)

Ты не меня спрашивай, а Страуструпа

Детский сад как он есть.

With minor exceptions, C++ is a superset of C

Ну да, Си++ - надмножество подмножества Си, какой сюрприз.

Именно так его и задумывал Бьерн (или Бьёрн, или Бьярн, или Бьярне, или Бьёрне).

Он даже не надмножество С99, хотя неполная совместимость с этим стандартом есть.

Ну да. ЕМНИП, последнй стандарт Си, который был подмножеством Си++ - это C89.

Детский сад как он есть.

Не так трактуешь. Я привык подкреплять свои рассуждения ссылками на официальне источники. :-) А без источников придётся свой базар доказывать, а то сочтут за взвяк. Поэтому, насчёт C++ Страуструп - источник авторитетный :-)

Ну да, Си++ - надмножество подмножества Си, какой сюрприз.

Если Вам так будет угодно :-)

Бьерн (или Бьёрн, или Бьярн, или Бьярне, или Бьёрне)

Пиши просто: Страуструп.

А ещё проще - страус :-)