Серия видео по Rust для начинающих

Модульность загрузки и выгрузки кода это очень мало, вот в жабе в осги каждый класс сервис может быть отдельным модулем, знает свои зависимости и дёргает методы других сервисов-модулей как-будто это код локального контекста, при этом там нет принуждения всех к одному интерфейсу как в плагинах или хуках

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

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

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

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

OSGi provides an API to “unload” a bundle (ie a jarfile) at runtime. This is possible because each OSGi bundle has its own Classloader (unlike in traditional Java where unloading a jarfile is not possible because all classes are loaded via a single classloader responsible for everything on $CLASSPATH).

У вас плюсы головного мозга.

Это либа плана «черный ящик», которая с таким же успехом могла быть написана на Си.

И? Ты же говорил «lock-free алгоритмы, в которые Rust не умеет совсем никак»? Или всё-таки умеет не хуже, чем си? Справедливости ради, и не лучше, но это и не обещали.

Стандартная же библиотека у раста никак не адаптирована под lock-free — она приколочена гвоздями к доступу через блокировки, вплоть до автоматических трейтов Sync/Send в компиляторе.

Что мешает обеспечивать гарантии с под капотом? В чём «прибитость гвоздями» блокировок?

Ты же говорил «lock-free алгоритмы, в которые Rust не умеет совсем никак»? Или всё-таки умеет не хуже, чем си?

Во-первых, ты придираешься к формулировкам. Во-вторых, я могу с таким же успехом дойти до «питон умеет в lock-free не хуже, чем Си» — тем более, что питон реализован на Си. Но Си находится на уровне абстракций ассемблера, а в случае Rust тебе приходится опускаться на уровень ассемблера, теряя кучу гарантий языка в процессе этого опускания.

Что мешает обеспечивать гарантии с под капотом? В чём «прибитость гвоздями» блокировок?

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

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

Маленькое уточнение.

Все гарантии языка никуда не пропадают в unsafe, но появляется возможность отстрелить себе пятки. :)

Во-вторых, я могу с таким же успехом дойти

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

Растовские ссылки в рантайме - это обычные указатели. Которые, как и сишные указатели, далеки от чтения/записи по адресу в ассемблере. См. например https://www.ralfj.de/blog/2020/12/14/provenance.html

Во-первых, ты придираешься к формулировкам.

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

Во-вторых, я могу с таким же успехом дойти до «питон умеет в lock-free не хуже, чем Си»

Нет, не можешь. В питоне придётся именно сишный код использовать, а в расте ты остаёшься в рамках языка. Unsafe раст - это раст.

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

Что ты называешь «хардкодом в компиляторе»? Само наличие трейтов Send/Sync? Это звучит как «хардкод RAII/деструкторов».

В питоне придётся именно сишный код использовать, а в расте ты остаёшься в рамках языка. Unsafe раст - это раст

std::sync::atomic вообще не требует использования unsafe. Сама же реализация std::sync::atomic использует instrinsics.

Далее, внезапно, питон позволяет дергать произвольную сишную функцию без единой дополнительной строчки на Си. То есть, в винде можно загрузить kernel32.dll и дернуть какой-нибудь InterlockedIncrement.

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

Что ты называешь «хардкодом в компиляторе»? Само наличие трейтов Send/Sync? Это звучит как «хардкод RAII/деструкторов»

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

спс за ссылку

std::sync::atomic вообще не требует использования unsafe.

Если этого хватит, то и замечательно, но речь почему-то шла об «уровне ассемблера».

Далее, внезапно, питон позволяет дергать произвольную сишную функцию без единой дополнительной строчки на Си.

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

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

Нет, не ближе потому что за Send/Sync ничего платить не надо. К слову, atomic-типы Send и Sync, хотя ты говоришь, что эти трейты прибиты гвоздями к блокировкам.

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

Далее, внезапно, питон позволяет дергать произвольную сишную функцию без единой дополнительной строчки на Си

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

Что питон умеет в lock-free погроммирование не сильно меньше, чем Rust. А если мы сделаем шаг еще дальше, то выяснится, что и на баше можно что-то близкое сделать. То есть, Rust не имеет каких-то выдающихся инструментов для lock-free программирования. Да, я понимаю, что тебя смутил оборот «совсем не может в» — но он очень даже уместен, если говорить про сам язык, а не его библиотеки. Тогда выяснится, что и питон не умеет, и баш — и тогда картина становится чуть более привычной нам, но тогда и становится справедливым свойство «совсем не может в».

К слову, atomic-типы Send и Sync, хотя ты говоришь, что эти трейты прибиты гвоздями к блокировкам

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

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

Как я раньше писал — мы приходим к тому, что раст был бы неплох, если бы все операции были на указателях и все функции были бы unsafe. А без этого, как правило, неизбежно возникает необходимость смешивать типы без Sync/Send с типами, имеющими Sync/Send, в том числе с атомарными типами, у которых есть оба трейта, в итоге имеем распространенный результат для растовых библиотек — стройные ряды прокладок, которые ничего не делают, кроме заворачиваний/разворачиваний и преобразований типов. И всё только для того, чтобы устранить семейство ошибок, которые не пересекается с ошибками характерными для lock-free алгоритмов. На всякий случай напомню, что для lock-free алгоритмов характерно использование одной изменяемой ячейки одновременно в нескольких функциях и потоках выполнения, а также они используются без применения блокировок.

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

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

Допустим. Тогда какой язык умеет и благодаря чему?

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

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

Допустим. Тогда какой язык умеет и благодаря чему?

Например, язык с поддержкой STM. Вроде Haskell. Прикол в том, что он ориентировать на неизменяемые структуры данных, а «как бы изменение» переменных происходит атомарным свапом указателя.