Rust 1.34

Вызывает шок. Сложон больно если в голове нет C++ бэкграунда :)

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

Но да, есть задачи, где недостатки Раста меньше чем его преимущества.

Не скажу, что отсутствие модулей в плюсах это основная проблема, но точно очень серьезная. Гуглить по «единица трансляции» или «translation unit». По моему опыту это проявляется в том, что препроцессор все файлы, что включены в исходник по факту смешиваются в один большой файл и получается каша. Причем становится важен порядок включения файлов. Т.е. ваша библиотека может изменить свое поведение только лишь потому, что ее заголовочный файл был включен после/перед каким-то другим заголовочным файлом. А все просто потому что в этом файле переопределяется макрос, который используется в библиотеке, которую использует библиотека, которую используете вы. Или наоборот - ваш код может сломать другой код, напрямую не связанный. Не ясно ничего из моего объяснения? Так вот это прямая иллюстрация, почему отсутствие модулей печалит людей - это приводит к каше, которая в подавляющем большинстве случаев работает, но если не работает, то разобраться сложно. В настоящих модулях, как в том же D все работает изолированно. Ваш код никак не повляет на другой код, если только вы не импортируете его явно.

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

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

На низком уровне rust отличается от С++ только тем что компилятор строго следит за владением, и почти все концепции взяты из плюсов. Если еще кроме С++ с ML семейством (OCaml, F#, StdML) или с haskell хоть немного знаком то rust вообще как родной будет.

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

Да уж, не часто такое приходится слышать.

Да уж, не часто такое приходится слышать.

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

А чем плох такой подход по вашему?

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

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

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

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

О, ну так это как раз хорошая иллюстрация продуманных решений в D. Там же есть ranges. За счет этого API у контейнера, основанного на GC будет практически тот же, что у контейнера на каком-либо другом аллокаторе. Конструктора будут разные и то не факт, но именно доступ и работа с элементами будет одинакова (если ranges одного типа, конечно же). Т.е. задача, озвученная вами может свестись просто к замене в коде одного типа контейнера на другой. Хотя аллокаторы еще нужно будет инициализировать.

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

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

Макросы они уже неизбежны. Они часть языка. Они всегда будут. Точка.

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

Другой проблемой с модулями является то, что translation unit пересобирает весь код каждый раз, даже если он уже был распарсен и скомпилирован для другого TU. Да, придумали precompiled headers, но это то же больше workaround.

У меня есть подозрение, что это какая-то фикс-идея из языка Ди, что можно легко отказаться от сборщика мусора.

У меня есть подозрение, что это какая-то фикс-идея из языка Ди, что можно легко отказаться от сборщика мусора.

Это не идея фикс. Во многих случаях так уже есть и идет планомерная работа по 100% реализации этого подхода. Сборщик мусора в D играет далеко не такую роль как в Java. Он действительно лишь одна из возможностей работать с памятью и не более. Во многих случаях его достаточно. А когда нет - есть реальная возможность от него отказаться.

На низком уровне rust отличается от С++ только тем что компилятор строго следит за владением

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

и почти все концепции взяты из плюсов.

Не взяты, а сворованы. Причины тому просты а) авторы это поделки попросту не может ничего родить, б) эта поделка целиком и полностью импортирует логику llvm в язык. Т.е. по-сути этот недоязычок строился не как все языки «сверху вниз», а «снизу вверх». А под что проектировался(реально) llvm - всем понятно.

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

В итоге все скатывается к большим фреймворкам, которые все равно 100% потребностей не покрывают, более консервативны и накладывают больше ограничений.

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

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

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

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

Но и проблемы в расте тоже есть, да. Например, конфликтующие реализации.

Можно пример?

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

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

Недоразумение, а не язык.

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

Ну не так пишут на крестах, не пишут. Выдуманные проблемы из методички...

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

Решишь задачки анона из соседней темы?

кинь ссылку хотя бы

вот например - https://github.com/rust-lang/rust/issues/51774

тут ничего не менялось кажется еще со времен альфы. «Нет трейта - нет проблемы».

раз

два

три

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

лол что? Ко всем примерам уже через пару постов были даны правильные ответы

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

ааа, ясно. Это не какие-то «растоманы», а ты сам долго тупил и видел ошибку не там, где она была :))) Все 3 примера абсолютно стандартные, если ты пишешь на расте, то с ними не возникнет проблем (что собственно и произошло - см. п. 1)

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

Но не сразу. И многие таки тупили.

ааа, ясно. Это не какие-то «растоманы», а ты сам долго тупил и видел ошибку не там, где она была

Это был не я, а другой анон. Компилятор ошибку показывает в другом месте. Тупил не только анон, но и многие адепты раста в той теме. Один только адекватный был.

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

по ссылке какое-то колдунство, за которое раст, к счастью, дает по рукам

Первые две очень простые

это такая тривиальщина, что любой нормальный растоман просто пройдет мимо

По третьей долго тупили и видели ошибку не там, где она была

долго - это сколько? у меня минут 10 ушло. а у тебя сколько уйдет на исправление аналогичного говнокода на плюсах? и прибавь время между коммитом патча и обнаружением ошибки в рантайме

Компилятор ошибку показывает в другом месте

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

а семантика в любом языке на плечах программиста

псевдокод на плюсах:

int x = 1;
auto y = 1;
string z = string("hello") + y;

в какой строке компилятор покажет ошибку?

почему-то некоторым плюсёрам важнее, чтобы компилятор отлавливал ошибки уровня

int x[] = {1,2,3};
cout << x[4];

а не те, которые реально представляют проблему

ваши ошибки не ошибки

в какой строке компилятор покажет ошибку?

мляя…

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

PS имелось в виду, конечно,

-auto y = 1;
+auto y = x;

но разницы никакой

запустил по приколу. получил вывод:

22081

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

wc -l == 39. При этом на первой строчке все ясно, на других компилятор просто говорит что он пытается проверить.

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

можно полностью?

Это все что мне выдало, лол.

а, я думал, у тебя в этом 39 строк

g++ то же самое в принципе выдает, только включает цепочки инклудов

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

а на самом деле, надо было заинклудить #define int string сделать string x = "1" в первой строке.

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

Почему? Нельзя сложить число и строку! Правильно же написал.

Правильно же написал.

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

Сборка очень долгая.

Да и я шучу: я обычная жабомакака, не запаривайся.

Действительно странно.

Интересно почему такой кейз не вызвал массовых пригораний. Не вижу тонны комментов в том issue.

это такая тривиальщина, что любой нормальный растоман просто пройдет мимо

Но даже в той теме пара человек не проходило мимо, а отвечали неверно.

у меня минут 10 ушло.

Речь не про тебя.

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

На плюсах так не пишут.

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

Так спор был про раст, а не C++.

а на самом деле, надо было заинклудить #define int string сделать string x = «1» в первой строке

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

А в том примере на расте была речь про лайфтаймы, которые раст автоматически «неправильно» проставил, а ругался в другом месте. При чем тут вообще C++?

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

Ну вот, с контейнером уже не срослось. Тогда пойдем дальше: что и как мы будем помещать в контейнер (который так или иначе, но написали)?

И тут выяснится, что нам придется провести водораздел между value types (объекты которых могут размещаться на стеке или же быть частью других объектов) и reference types (которые должны размещаться в хипе и доступ к ним будет осуществлятся через указатели). Так же мы должны будем решить, можно ли нам иметь ссылки на экземпляры value types. И если можем, то как мы будем следить за их валидностью.

За валидностью ссылок на экземпляры reference types так же придется следить. Скажем, поместили мы указатель на экземпляр reference types в контейнер. И когда он теперь должен быть удален? Кто за этим будет следить?

А потом мы придем еще и к вопросу детерминизма в уничтожении объектов (т.е. моменты вызова деструкторов в C++, drop в Rust, finalize или Dispose в Java/C#). И окажется, что этот детерминизм крайне важен. И, в зависимости от того, управляем ли мы памятью вручную (т.е. явно определяем скоуп для объекта) или через GC (т.е. это кто-то делает за нас), обеспечиваться этот самый детерминизм будет по-разному.

Но я не про этот случай.

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

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

Да нет там никаких чудес. Стандартную библиотеку дописывают для работы без GC и, в общем, всё.

Но даже в той теме пара человек не проходило мимо, а отвечали неверно.

и какой вывод мы из этого делаем?

А в том примере на расте была речь про лайфтаймы, которые раст автоматически «неправильно» проставил, а ругался в другом месте. При чем тут вообще C++?

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