Rust 1.34

Тема с одной «мутабельной»(хотя мутабельность тут ни при чем на самом деле) ссылкой или несколькими не мутабельными «в один момент времени» - чисто растовское ограничение. И это не часть хороших практик плюсов, например

ну-ну.

std::vector<int> v{1, 2, 3, 4, 5};
for (auto x: v) if (x == 1) v.push_back(6);

Конкретно этот нет. Но стоит заменить vector на list и код будет корректным=)

Дело не в количестве ссылок.

Но пока массового увлечения написания на нём прикладных приложений для десктопа не видно.

Это про любой язык можно сказать. Ну кроме C++, ибо только для него есть Qt.

Python (PyQt). Из известных мне приложений с его использованием написаны - Calibre, Veusz

Таких прог 2.5. Что-либо серъезное придётся писать на плюсах.

PS: Calibre это вообще франкенштейн на втором питоне.

Допустим. Но вопрос о том, для написания чего предназначен Rust (не по представлениям его разработчиков, а на деле) и почему его так активно сравнивают с C++, на нишу которого он, получается, не претендует, остаётся открытым.

У вас какая-то странная логика. Сравнивают языки, а не доступные либы. C++ повезло с Qt, не более. Тем более Qt, в его текущем виде, уже легаси. Как минимум QtCore и QtWidgets. Особенно в свете Electron и подобного.

Никому не нужен ещё один Qt на новом ЯП. Нужен полностью новый тулкит для современных реалий. И работа в этом направлении идёт в rust.

Сравнивают языки, а не доступные либы.

Сравнение ради чего? Либы я не сравниваю.

Нужен полностью новый тулкит для современных реалий. И работа в этом направлении идёт в rust.

С этого места подробнее. С чем будет совместим это новый тулкит?

Либы я не сравниваю.

Qt - это либа. Если не сказать больше.

С чем будет совместим это новый тулкит?

Что значит «совместим»?

Забудь ты о Qt. Речь не о нём, а о назначении языка по факту его использования.

Что значит «совместим»?

То и значит. Где его можно будет использовать ещё, кроме как в rust.

Забудь ты о Qt.

Так C++ используют для GUI не потому что это подходящий для этого язык, а из-за того, что для него есть необходимые либы.

То и значит. Где его можно будет использовать ещё, кроме как в rust.

А где можно использовать Qt, кроме как в C++?

как-то в первый раз выпало из поля зрения, но вот есть такая еще вкусняшка: Any::type_id и Error::type_id

Мдеее

fn main() {
    let arr = [1,2,3,4,5,6];
    let index = 1024;
    
    println!("{}!", arr[index]);
}

NonZeroI8 который может быть 0

Ну а это вообще смешно, сделали бы плагин для clang(c/c++) лучше, польза хоть была бы.

thread ‘main’ panicked at ‘index out of bounds: the len is 6 but the index is 1024’, src/main.rs:5:21

что не устраивает-то? что rust на этапе компиляции проблему останова не решает?

Ошибка сегментирования

Что не устраивает-то?

Это же толсто. У тебя run-time значения. А гарантии все в compile-time.

Что-бы числа (usize) можно было ограничить во время компиляции нужны зависимые типы.

Что не устраивает-то?

Тем что это UB и может быть не ошибка сегментирования, а тихая порча памяти и работа далее как ни в чем не бывало.

У тебя run-time значения.

В смысле? Я создал массив (вроде бы с константным размером) и нигде его размер не меняю. В чем проблема отследить?

let index = 1024;

Это иммутабельная переменная, а не константа.

Даже TCC выводить такие же ошибки как раст.

где ты там ошибку сегментирования увидел?

Я ее нигде не меняю.

И не поменяешь. Но это все равно переменная.

UB

паника - это гарантированное поведение

Он спрашивал чем не устраивает ошибка сегментирования, которая случается в аналогичных случаях в программах на С.

gcc же умеет вычислять факториал в момент компиляции, если все числа задать в коде а не брать из scanf, чому раст не может сделать что то подобное?

Да. https://github.com/paholg/typenum

Просто нужно внимательнее писать, да?

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

Для такого же самого эффекта в расте нужна библиотека???

Я еще как то писал функцию которая могла сделать так:

int i = calc("2+2"); // mov [i], 4

а в реальных случаях это трудноуловимая проблема

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

Я не правильно понял вопрос. В раста под капотом llvm значит в константах все как в си.

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

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

они никак не оптимизируют код перед тем как скормить его ассемблеру LLVM

хз (кажется так было до MIR, но уже пару лет как не так), но это не относится к

gcc же умеет вычислять факториал в момент компиляции, если все числа задать в коде а не брать из scanf, чому раст не может сделать что то подобное?

это как в си.

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

А здесь всегда боундчек

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

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

У тебя всегда избирательное чтение? Забудь о Qt.

Много где очень даже возможно.

Это не язык, а компилятор.

Так значит все же UB?

Значит даже в правильной программе есть оверхед!

Это не язык, а компилятор.

Так значит все же UB?

В safe-rust нет UB.

Здесь вот какой компромисс, или кто-то доказывает что в каком-то частном случае не будет выхода за границу и пилит это в компилятор, или будет боундчек. Для часто встречаемых случаев запилили, если использовать итераторы боундчека не будет. В тех случаях для которых нету доказательства в компиляторе будет боундчек. Это нужно что-бы не допустить UB, насчет UB нету компромиссов, но насчет оверхеда есть.

В safe-rust нет UB.

Там есть вещи намного интереснее, NonZero числа со значением Zero например %)

Ну ок, я понял логику с UB.

NonZero числа со значением Zero например %)

таких в safe-rust тоже нет

что rust на этапе компиляции проблему останова не решает?

А статические анализаторы C++ справятся легко.

А статические анализаторы C++ справятся легко.

да я всегда знал, что от статических анализаторов С++ никакой пользы

Ну так вы спрашивали про десктоп проги - я вам ответил.

Если нужны просто прикладные либы/проги, то тут Rust без вариантов. Смысла использовать C++ не вижу.

Нет никаких биндингов

Значит даже в правильной программе есть оверхед!

во-первых, чаще всего очень небольшой, благодаря предсказанию ветвлений в процессоре. во-вторых, компилятор раста уберет проверки, если сможет доказать отсутствие выхода за границы. И в этом ему можно помогать, используя итераторы, правильно расставляя assert-ы и т.п. в-третьих, в unsafe-блоках можно использовать арифметику указателей, тогда никаких проверок не будет (но так никто не делает из-за 1 и 2)

Показать ошибку можно после того как человек озвучит догадку или попросит ошибку.