Вышел Rust 1.0

насчёт C++ Страуструп - источник авторитетный :-)

Конечно. Только он не говорил того, что сказал ты.

Гляди какой всезнайка. Читай его книгу A tour of C++, раздел 14.3 C/C++ Compatibility, самое первое предложение. Потом говори тут :-)

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

А зачем предполагать? Возьми любой достаточно большой проект и посмотри, сколько там unsafe-кода в сравнении с остальным кодом. Его будет на порядок меньше. Это значит, что в нём будет на порядок меньше багов и общая стабильность проекта будет выше.

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

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

Языков со сборщиком мусора в мире полно. И Rust среди них не предлагает ничего особенного. У сборщика мусора основная проблема — для эффективной работы он требует памяти в разы больше, чем используется программой. Ну и обычно непредсказуемые паузы при работе программы. И это ограничивает его применимость. Модель управления памятью без накладных расходов на неиспользуемую память гораздо интересней.

А причем здесь sudo ? А так с точки зрения языка который позиционируется как ПОЛНОСТЬЮ безопасный по работе с памятью - unsafe явно костыль, причем весьма грубый и при применении данного костыля о какойто безопасности говорить не приходится. Я бы на месте мозиловцев ограничел бы использование unsafe. Например чтобы компилятор пропускал его только при наличии определенной опции в командной строке, это бы упростило процесс верификации чужого кода на предмет потенциально опасных мест + отбивало желание у некоторых девелоперов пихать unsafe куда не следует. Хотя с их подходом к компиляции это может вызвать кучу дополнительных проблем ...

Да и кстати компилирование это тоже скользкий момент в расте, например есть программа с объемом исходников под 50MB как справится с ней компилятор (при том что полностью все исходники обробатыватся за один проход) ?

А так с точки зрения языка который позиционируется как ПОЛНОСТЬЮ безопасный по работе с памятью

Кем, когда?

полностью все исходники обробатыватся за один проход

ЕМНИП, только исходники крейта.

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

Такие штуки к гиту прикручивают. К примеру, у servo бот автоматически пишет «Warning. These commits modify unsafe code. Please review it carefully!» в комментарии к PR.

Да и кстати компилирование это тоже скользкий момент в расте, например есть программа с объемом исходников под 50MB как справится с ней компилятор (при том что полностью все исходники обробатыватся за один проход) ?

Инкрементальная компиляция будет, просто её ещё пока не запилили.

В Python, например, есть xdress, ну это ладно, простенький говногенератор кода для Cython (есть, кстати, и посерьёзней, но я забыл, как называется), но есть ещё как минимум cppyy, gcc-xml для Boost::Python и много чего другого.

Это то же самое, что Rust + rust-bindgen.

есть ещё как минимум cppyy

А это из другой оперы.

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

(Аноним)

О, порванный аноним-смайлодрочер из треда LispWorks 7.0 сюда прикатился.

Порватке невдомёк, что в первую очередь Rust убьёт его любимый лишп, ибо куча маргиналов оттуда накинутся на этот новый язык, забывая о своих любимых диалектах. Без хипсторов лишпы зачахнут; и даже Naughty Dogs, DSL для своего кино на PS4 будут писать именно на Rust, в будущем.

Но ненависть, направленная на C++ у подобных личностей просто атомная. Они готовы пожертвовать всем, даже убийством своего любимого диалекта, лишь бы отбавить популярности у крестов. Ведь как же так?! Ведь есть же Lisp, пиши на нём красивые (в плане архитектуры) программы и библиотеки, ан нет: эти говноеды всё равно выбирают крестопарашу! Вот ведь твари! Что им стоит выбрать для браузера или виртуальной машины другой язык? Чего они так к этим крестам прицепились?

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

Это в продолжение Вышел новый релиз LispWorks 7.0

По сабжу: долгих лет жизни этому языку и проектам на нём. Очень жаль, что с мигрирующими плюсовиками, которые, несомненно, захотят распробовать новый язык и написать на нём что-то, мигрируют и маргинальные личности вроде смайлофагов из этого треда, которые будут писать только хелловорлды, а кукарекать (разумеется о смерти C/C++) на всю округу будут так, будто написали на Rust'е целое ядро операционной системы и вспомогательные компоненты к нему (включая прикладные GUI-приложения).

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

Кстати, да, это ж видимо тот самый «С++-хейтер» потралливает.

Не бесконечными, а терминирующими :-)

rust-bindgen посмотрю, а чем cppyy из другой оперы? FFI для вызова методов функций реализованных на C++, см. примеры (класс на C++ и его использование из PyPy, например) --- заголовки переписывать не надо, одна магия (c)

а чем cppyy из другой оперы?

Тем, что он для PyPy.

даже Naughty Dogs, DSL для своего кино на PS4 будут писать именно на Rust

Ты реально болен.

А зачем предполагать? Возьми любой достаточно большой проект и посмотри, сколько там unsafe-кода в сравнении с остальным кодом. Его будет на порядок меньше. Это значит, что в нём будет на порядок меньше багов и общая стабильность проекта будет выше.

Ну в больших проектах на томже C++ тоже unsafe code минимум, все остальное реализовано через смартпоинтеры и контейнеры - которые гарантируют безопасносную работу с паматью, причем поскольку смартпоинтеры/контейнеры не являются синтаксическими особенностями языка то их можно велосипедить огромное ко-во с различными особенносятми в виде библиотек (тотже boost).

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

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

А ведь найдутся такие, кто будет писать ядро операционной системы на Rust :-)

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

Это о чем конкретно?

даже Naughty Dogs, DSL для своего кино на PS4 будут писать именно на Rust

Зачем Rust? Ведь если C++ - универсальный язык, то на нём можно и кино писать? :-)

Не понял, какая разница? Нужна поддержка CPython, используй оригинальный PyROOT / PyCintex, или к чему это?

Ты реально болен.

На PS1 уже пишут ) https://github.com/simias/psx-sdk-rs https://svkt.org/~simias/psx-rust.png

rust-bindgen, к сожалению, некоторые вещи делает не так, как следовало бы (enum'ы, например). Так что сгенерированный код приходится допиливать вручную.

На PS1 уже пишут

Я знаю. Но к DSL это отношения не имеет, тем более DSL типа того от Naughty Dog

Я тебе больше скажу — уже пишут.

https://github.com/farcaller/zinc

cast Farcaller

Макросы в качестве DSL?

Не понял, какая разница?

Разница в том, что cppyy - это не для Python вообще (как ctypes или cffi), а конкретно для PyPy.

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

Это о чем конкретно?

Когда у них было 3 способа размещения объектов в памяти: на стеке, в куче с одним овнером, в куче с боксированием (сщетчик ссылок + GC который можно было отключать). В релизе убрали 3й вариант а второй переименовали в боксирование, перекрестные структуры на на старой модели памяти делались элементарно на полностью безопасном коде. Непонятно зачем убрали - возможно испугались мемори ликов.

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

в C# такое было в определённом виде. Геморрою больше чем пользы.

А ведь найдутся такие, кто будет писать ядро операционной системы на Rust :-)

А почему в будущем времени? http://scialex.github.io/reenix.pdf

Сначала сделать Racket из Rust ?

у них было 3 способа размещения объектов в памяти: на стеке, в куче с одним овнером, в куче с боксированием (сщетчик ссылок + GC который можно было отключать)

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

Ну в больших проектах на томже C++ тоже unsafe code минимум, все остальное реализовано через смартпоинтеры и контейнеры - которые гарантируют безопасносную работу с паматью, причем поскольку смартпоинтеры/контейнеры не являются синтаксическими особенностями языка то их можно велосипедить огромное ко-во с различными особенносятми в виде библиотек (тотже boost).

Только в C++ это на уровне договорённостей, а в Rust на уровне синтаксиса. Договорённости надо проверять вручную. Синтаксис проверяется компилятором.

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

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

в куче с боксированием (сщетчик ссылок

Но ведь [A]Rc именно это и делает.

https://twitter.com/joshbloch/status/583813919019573248

А ведь найдутся такие, кто будет писать ядро операционной системы на Rust :-)

Уже как минимум два ядра написали. Модули к линуксу тоже можно писать на нём.

Ну в больших проектах на томже C++ тоже unsafe code минимум, все остальное реализовано через смартпоинтеры и контейнеры - которые гарантируют безопасносную работу с паматью, причем поскольку смартпоинтеры/контейнеры не являются синтаксическими особенностями языка то их можно велосипедить огромное ко-во с различными особенносятми в виде библиотек (тотже boost).

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

Модули к линуксу тоже можно писать на нём.

Линк?

https://github.com/tsgates/rust.ko

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

Хорошо сказано, с этим не поспориш :)

Что-то я не понимаю твою логику, а если cppyy скрестить с PyROOT и будет нечто, работающее одновременно с CPython и PyPy, то это для тебя будет «для Python вообще» или нет? А как, например, с Jython быть, там ни cffi, ни ctypes не работают.

Но ведь [A]Rc именно это и делает.

Да както я его не заметил в либе, и в принципе его можно тоже навелосипедить (через тотже unsafe). Спасибо попробую пересмотреть все есще раз по свободе.

а если cppyy скрестить с PyROOT

Его скрестили? Нет. О чем разговор тогда?

и в принципе его можно тоже навелосипедить (через тотже unsafe)

Box<T>, кстати, также реализован как часть стандартной библиотеки.

Да както я его не заметил в либе, и в принципе его можно тоже навелосипедить (через тотже unsafe)

Оно через unsafe и сделано. Кстати, почему? Даже простой подсчет ссылок - уже слишком сложно для растовской модели управления памятью?

Да просто изначально современный Box был не библиотечным а примитивом компилятора (и записывался через * вродебы), потом получается его перетянулу в либу как Box а видоизмененный Box сделали Arc. В принципе логика в этом есть - такчто я был не прав похоже :)

`~[T]`. Давно же это было.

А я и не в положительном контексте это описывал.

Да, я тебя недопонял.

А как еще в расте полноценно запилить объект в куче и иметь на него несколько ссылок? У box время жизни жестко ограничено.

Подозреваю, что и тут тоже. В смысле, в С++ есть unique_ptr и shared_ptr, в расте - Box и Rc. Раст только чуть больше гарантий даёт, а смысл в плане подсчёта ссылок такой же.

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

Предупреждения всё-таки в стандарте не прописаны. Так что оно может быть, а может и не быть. Имхо, подход с unsafe всё-таки удобнее. Случайно выстрелить в ногу уже не получится.

Даже простой подсчет ссылок - уже слишком сложно для растовской модели управления памятью?

А для какой модели это просто? Вангую, что либо для небезопасной, либо для GC.

Так бы и сказал, что наваяли возможным вызов ф-ии Раста из Си :-) На C++ тоже, как минимум 2 ядра ОС написали. А потом забыли :-)