Comments 4
Очень круто, конечно, но в чём преимущество такого подхода перед использованием unsafe-кода и аллокаций на стеке на C#, если проблема в основном в GC? Впрочем может быть полезно, если есть какая-то библиотека для числодробилок на Rust, которую нужно заиспользовать в проекте на C#.
Этот подход НЕ для одноразовой привязки существующих библиотек, а для написания своего кода, который постоянно меняется у будет компилироваться бесшовно одновременно с МАУИ.
Как мы понимаем, Раст был придуман, чтобы код был безопасным, а не unsafe. И описанный путь для случаев, когда нужна максимальная производительность, GC же упомянут скорее как нюанс. Чем сложнее ваш код, тем меньше шансов оставить все на стеке и "заранее выделить память на всё".
Раст был придуман, чтобы код был безопасным
Вы не поверите, managed код тоже. Поэтому он и не unsafe. Современные анализаторы и наборы флагов просто не дадут вам собрать приложение, где вы забыли что-то в силу человеческого фактора. Это не тоже что в Rust, но сопоставимо
И описанный путь для случаев, когда нужна максимальная производительность
Проблема в том, что акцент вы на этом не сделали. Читатель прочтет статью как
мы нарисовали что-то в maui с помощью магического пакета
RustMaui.. но зачем?
Статья не подводит к проблеме, использует некоторый черный ящик без объяснения его функционала, показывает синтетический не относящийся к делу пример, и оставляет практически ноль выводов.. тут даже бенчмарк некуда вставить ввиду бессмысленности примера. Оговорка в конце о том что вы так и задумывали никак не решает эту проблему, скорее будет сделан вывод, что статья написана тем кто любит Rust потому что он ему хорошо знаком, а C# нет ..
меньше шансов оставить все на стеке и "заранее выделить память на всё"
А маршалинг в нативный код на Rust прям как-то отличается да ? (нет)
Windows, Android, macOS и Mac Catalyst
Кроссплатформенность, ОК. А оно будет работать с AvaloniaMAUI ?
Этот подход НЕ для одноразовой привязки существующих библиотек, а для написания своего кода, который постоянно меняется и будет компилироваться бесшовно одновременно с МАУИ
Не вижу причин лезть в бутылку. В контексте обычного жизненного цикла приложения, наиболее частый сценарий это как раз решение одной какой-то проблемы в виде подключения еще одной библиотеки. Сферический шарпист, это ленивый человек, в гробу он видел синтаксис Rust, гибридный проект, замедление скорости разработки.. и как следствие увеличение стоимости поддержки.
Позиционирование подхода, как повышение производительности такое себе. Шарп не настолько уступает системным языкам, чтобы разбавлять кодовую базу шарпа, кодом на расте. Для числомолотилок есть SIMD, для ручного управления памятью есть unsafe.
Единственное вменяемое применение - уже готовые библиотеки на расте, но с вероятностью 99% для них уже есть враппер на .net и тащить его исходники в проект нет особого смысла.
Но в целом прикольно, респект за статью.
Как использовать Rust внутри приложений на .NET MAUI