Pull to refresh
77
0
Андрей Лесников @ozkriff

Rust сектант и хобби-игродел

Send message

А под разные платформы пробовали собирать? Мобильные/браузер?

Если интересно, у меня есть небольшая опенсорсная поделка на макрокваде - https://github.com/ozkriff/zemeroth. Вот (немного устаревшая) wasm версия на итче. Вот андроид порт и заметки про него. С ios Федя (автор квадов) когда-то экспериментировал, но дальше pov дело пока не долшло.

И вот тут - https://github.com/ozkriff/awesome-quads - я еще всяке макроквадные ссылки старался собирать, может кому пригодится. Если есть какие сложности-вопросы, то можно в дискорде обсудить с автором и другими пользователями.

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

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

А мы какое определение "нестабильности" тут используем? В моем понимании это все, что не входит в стандарт языка.

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

Это разве был интересующий пример нестабильного C++ в стандартной библиотеке C++?

а разве нет? ну хорошо, вот прям ссылка на то как GCC реализация stdc++ использует кучу builtin штук компилятора https://github.com/gcc-mirror/gcc/search?q=path%3Alibstdc%2B%2B-v3%2Fsrc+builtin так убедительней? Или может я вопрос как-то не так понял?

Чем же лучше версия на Rust: `type Int32T = isize;`?

Стоп, откуда тут лучше-хуже взялось и какое отношение этот пример имеет к стандартным библиотекам раста и плюсов? 😵‍💫Разговор же был о том, что стандартные библиотеки языков часто используют платформо-компиляторо-специфичный код в своих реализациях и это нормально.

Выше пример не такой был, суть же в - `typedef signed int __int32_t;` - такое можно писать только в частном случае, когда мы знаем каким компилятором собираемся и на какой архитектуре, иначе это лютое UB и код использующий __int32_t дальше или тупо не соберется, или принесет много веселья в отладке странных ошибок.
Аналогичным образом msvc реализация плюсовой стандартной либы использует дофига компилятор-специфичных интринсиков и предположений.

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

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

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

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

А в чем именно беда и срочность? Новая редакция не так много изменений привносит, что бы они хоть как-то заметно сказывались на процессе обучения для новичка. Тем более что есть же https://doc.rust-lang.org/edition-guide/rust-2021

Какой-то очередной супер шаблонный комментарий к очередной супер шаблонной статье про Rust.

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

Почему не прижился? Это базовый типаж, им все пользуются - в том числе и вышеупомянутый thiserror.

А про текущий статус поисков идеально ржавого способа работать с ошибками можно почитать https://blog.rust-lang.org/inside-rust/2021/07/01/What-the-error-handling-project-group-is-working-towards.html

только стоит помнить, что это уже не такие дешевые ошибки будут

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

Что есть возможность контролировать какие символы допустимы?

Я глубоко в вопрос не лез, но да? Текущая реализация опирается же на https://www.unicode.org/reports/tr39 / https://lib.rs/unicode-security

А вы думаете все эти преобразования будут даром

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

И такие чудеса вас тоже не смущают?

Уф, значит RTL таки решили втащить как есть.

"right-to-left scripts can lead to weird rendering in mixed contexts (depending on the software used), especially when mixed with operators. This is not something that should block stabilization, however we feel it is important to explicitly call out. Future RFCs (preferably put forth by RTL-using communities) may attempt to improve this situation (e.g. by allowing bidi control characters in specific contexts)"

Так себе оно отображается в редакторах без специальной поддержки RTL идентификаторов. В текущем виде не особо приятно, мда :(

Первый наброс совсем скучный. А про второй:

> эмодзи, разное направление письма, неоднозначность представления, не отображаемые символы, модификаторы

Разрешили же только подмножество юникода, в котором всего этого нет.

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

Вон даже в коротком анонсе выше показано, что в таких случаях компилятор предупреждение выдает согласно юникодным таблицам схожести (warning: identifier pair considered confusable between `s` and `s`).

> нормализация строк (привет скорости компиляции)

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

> невозможность набрать на клавиатуре с распечатки

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

> Можно было оставить только латинские буквы, а в IDE заменять пред определенные последовательности на необходимое визуальное представление, но нет нормальные герои любят трудности.

Тоже такое себе - изобретать ide-специфичные велосипеды вместо использования уже готового общепринятого стандарта.

Оно не то что бы очень хорошо обновляется. Я бы скорей посоветовал обзорные статьи вроде https://dev.to/davidedelpapa/rust-gui-introduction-a-k-a-the-state-of-rust-gui-libraries-as-of-january-2021-40gl

Вангую, что недостает setUp/tearDown методов и mock объектов

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity