Pull to refresh
30
0
Станислав Ткач @DarkEld3r

Rust developer

Send message

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


Плюс в "написанные на С/С++" тоже есть передёргивание: ни один из перечисленных языков (разве что в 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.

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

И все же 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. Но развиваются, может со временем станет лучше.

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

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

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

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

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

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

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


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

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

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


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

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


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

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

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

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

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

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

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


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

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


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

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

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

Я бы попробовал "поправить", но не понял сути претензии насчёт "нецелостности". 🙃 С указателями аля unique_ptr (Box) бороу чекер прекрасно работает. И весьма очевидно, что статический анализ (этот самый бороу чекер) не может отследить ситуации когда нам нужно динамическое время жизни и тогда на помощь приходят указатели с подсчётом ссылок (аналог shared_ptr). Мне кажется, неправильно заявлять, что концепция поменялась так как (A)rc были с версии 1.0 (и раньше).

По моему опыту, опыт в других языках, особенно С++, часто идёт в зачёт.

Они отвечают на этот вопрос вот так:


Existing modern languages already provide an excellent developer experience: Go,
Swift, Kotlin, Rust, and many more. Developers that can use one of these
existing languages should.
Unfortunately, the designs of these languages
present significant barriers to adoption and migration from C++. These barriers
range from changes in the idiomatic design of software to performance overhead.

Carbon is fundamentally a successor language approach, rather than an
attempt to incrementally evolve C++. It is designed around interoperability with
C++ as well as large-scale adoption and migration for existing C++ codebases and
developers.

Information

Rating
Does not participate
Date of birth
Registered
Activity