Pull to refresh
29
Karma
0.2
Rating
Станислав Ткач @DarkEld3r

Rust developer

Пишем прототип программы для обучения английскому языку с помощью OpenAI API

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

Пишем прототип программы для обучения английскому языку с помощью OpenAI API

Если лень заводить свои ошибки, то проще всего так: https://github.com/evgenyigumnov/openai_api_client/pull/1/files
Там раст-фмт немного дифф раздул, но думаю идея понятна. Вместо anyhow можно завести свой тип, пусть даже обёртку над строкой — главное реализовать для него Trait std::error::Error, тогда вопросики будут работать.


В целом считается, что подход anyhow — это нормально для приложений, где обычно надо просто удобно прокидывать и логировать, а для библиотек принято делать более подробные ошибки (свой enum или через библиотеку thiserror).

Бьёрн Страуструп ответил АНБ США по поводу рекомендации ведомства отказаться от использования языков C и C++

В расте же паника — это unrecoverable error.

Если в контексте приложения (а не библиотеки), то это не совсем так.

Бьёрн Страуструп ответил АНБ США по поводу рекомендации ведомства отказаться от использования языков C и C++

Это малополезное заявление. Если мы возьмём условный "безопасный язык", то в программах на этом языке не будет (некоторых) проблем. Тщательно проверить код компилятора и стандартной библиотеки намного проще, чем если уязвимости могут быть вообще везде.


Плюс в "написанные на С/С++" тоже есть передёргивание: ни один из перечисленных языков (разве что в Ruby я не уверен) не написан целиком на С/С++. В JVM есть сишный код, но его доля далеко нe 100%. А Go даже не полается на LLVM.

Неполная, неточная и наполовину выдуманная история исключений

Уже ответили, но уточню, что стратегия обработки паники указывается на уроне "приложения". То есть если мы пишем не библиотеку, то можем полагаться на выбранную опцию.


Кстати, про стратегию обработки паники всё-таки говорится в книге, хотя возможность перехвата и не упоминается.

Неполная, неточная и наполовину выдуманная история исключений

Это все при том, что в Go есть обработка исключений. Работает почти также как в C++\C#\Java, только ключевые слова panic\defer\recover, чтобы никто не догадался.

Справедливости ради, в расте тоже: panic/catch_unwind/resume_unwind.


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

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

Про gccrs знаю, но пока не выглядит серьезной альтернативой, т.к. этот тот же rustc, но обращающийся к ir gcc, вместо llvm. Поправьте, если не прав.

Всё-таки поправляю — есть два проекта:


  • rustc_codegen_gcc — это как раз GCC бекенд для rustc.
  • gcc-rs — это именно альтернатива rustc.

Прошлогодние покупатели электромобилей Tesla в Китае раскритиковали текущие скидки

Тогда будет обидно тем, кто купил за два месяца. (:

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

И все же rust foundation это организация где есть менеджеры, а есть разработчики, а сверху над все этим один бюджет.

Дык, участники/спонсоры foundation деньги не просто так заносят, а чтобы иметь влияние. Чем это принципиально отличается от плюсового комитета, где тоже участники вынуждены договариваться?


Про gccrs знаю, но пока не выглядит серьезной альтернативой, т.к. этот тот же rustc, но обращающийся к ir gcc, вместо llvm. Поправьте, если не прав.

Вопрос заставил задуматься. До этого воспринимал gccrs именно как альтернативный фронт-энд. Теперь прям интересно действительно ли переиспользуются какие-то части rustc. Ответ пока не знаю. Но даже если и да, но я всё-равно не навал бы это "тем же rustc".


В любом случае, сказать хотел скорее, что движение к "децентрализации" есть. Кстати, ещё есть cranelift/wasmtime.

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

Что можно сказать: разработка Rust ведется гораздо более централизовано чем C++.

Пожалуй, это так, но скорее по историческим причинам. Rust Foundation — это такой же конгломерат, а не единая организация (например, как Microsoft развивающий C# или Swift который разрабатывает Apple).


Насчёт компиляторов: предлагаю посмотреть на gccrs. Пока ещё не готов к использованию, но процесс идёт.


Когда я в последний щупал дизель, то там были определённые сложности с написанием кода не привязанного к конкретной базе. Вроде невозможности использовать UUID с SQLLite. Да, нативной этот тип базой не поддерживается, но библиотека могла бы абстрагировать этот момент, но разработчики принципиально не хотят это делать.
Кстати, вижу, что sqlx набирает популярность. Предлагаю рассмотреть эту библиотеку.


Azul тоже не единственная имеющаяся библиотека для пользовательского интерфейса. К сожалению, все они не совсем (или совсем не) уровня Qt. Но развиваются, может со временем станет лучше.

Зачем писать на C++ в 2022 году?

что уж греха таить, иногда нельзя использовать что то из старого

Разве?.. Конечно, в новых редакциях нельзя, например, писать dyn Trait без dyn, но думаю речь не о таких ограничениях?

«Rust — это язык для изобретательства»: Илья Лахин о том, нужен ли Rust в GameDev

Справедливости ради, есть некоторые костыли помогающие с этим бороться вроде библиотеки fast-floats.

Зачем писать на C++ в 2022 году?

Разве что, вместо unsafe можно было бы выбрать более точное слово и &mut заменить на какой-нибудь &uniqe.

Помню споры на эту тему. Но тогда непонятно, что делать с переменными (let и let mut). Вводить отдельное ключевое слово? Есть некоторая прелесть в однообразии.

Зачем писать на C++ в 2022 году?

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

Всё-таки не могу согласиться. Мне кажется, что такое мнение может сложится разве что у человека, который кое-как освоил один язык. Вероятно, динамический — там код обычно действительно проще выглядит. А если осмотреться по сторонам, то начинаешь гораздо спокойнее к этому относиться. Я вот сложные LINQ выражения с трудом читаю, но C# разработчики, вроде как, весьма довольны этим инструментом. В скале разрешено вводить произвольные операторы, и как-то живут же. И это я ещё не говорю про лисп или хаскель.


У меня вот в прошлом основным языком был С++ и поэтому совсем не могу понять нападок на синтаксис раста. А ведь таковые нападки и от плюсовиков нередко раздаются. Согласиться могу разве что с претензиями к макросам (которые macro_rules). Мне вот приходится каждый раз разбираться, когда возникает необходимость написать макрос. Правда бывает это не то чтобы сильно часто, может поэтому они и забываются каждый раз.

Зачем писать на C++ в 2022 году?

Почему посреди фразы здесь знак "!"?

То, что это макрос объясняется в первой же главе книги по языку. Ну да, с какой-то теорией придётся ознакомится, иначе, в зависимости от предыдущего опыта, можно очень до многого докопаться. Например, зачем в С++ нужно ->? Вон в С# всё через точку. Если что, не надо мне объяснять, а на С++ много писал, это просто пример.


Ок, берём задачку чуть сложнее: посчитать количество символов "_" и "-" в строке.

К "задаче" относится только часть приведённого фрагмента кода, поэтому можно упростить до input.chars().filter(|&c| c == '_' || c == '-').count(). Ну или, по крайней мере, до вот такой функции:


fn num_chars(input: &str) -> usize {
    input.chars().filter(|&c| c == '_' || c == '-').count()
}

Не всё так страшно, не правда ли? Кажется, остаётся только претензия к |&c|. Если амперсанд забыть, то компилятор точно скажет, что не так, ну а различать значения и ссылка вполне нормально для системного языка. Ну и наконец синтаксис лямбд в С++ тоже достаточно страшный/перегруженный и ничего.

Зачем писать на C++ в 2022 году?

Вау, только вот это пожалуй самые непопулярные конструкторы вектора.

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

Зачем писать на C++ в 2022 году?

например нет способа создать вектор без макроса

Создал: Vec::new(). Сейчас будет уточнение, что надо создать вектор с элементами?.. Ну ладно: Vec::from([1, 2, 3]).

Rust 1.64.0: rust-analyzer в rustup, IntoFuture, ffi-типы в core и alloc, улучшения в Cargo

И то правда. (:


Можно ещё порассуждать о кортежах из больше чем двух элементах в публичном апи...

Rust 1.64.0: rust-analyzer в rustup, IntoFuture, ffi-типы в core и alloc, улучшения в Cargo

Теперь дошло, спасибо за объяснение!


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

Rust 1.64.0: rust-analyzer в rustup, IntoFuture, ffi-типы в core и alloc, улучшения в Cargo

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

Кто-нибудь может объяснить мне эту часть? Получается, что если есть кортеж вида (u8, (), u16) и "среднее" поле не используется, то предупреждения не будет?.. Но к чему тут "облегчения миграции существующего кода без изменения индексов кортежа"?

Information

Rating
1,947-th
Date of birth
Registered
Activity