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

Rust developer

Send message
Ну такая себе мотивация.

Можно поспорить насчёт того какое будущее у раста, я сам считаю, что язык ещё недостаточно взлетел. Но тоже замечаю, что "молодёжь" считает С++ устаревшим. Знакомый жаловался, что им людей тяжело искать — мол хоть бери и пиши что-то на го или расте, просто потому что так людей проще найти. Понятное дело, это просто один пример и по моему опыту раст-программистов искать тоже не то чтобы прям легко.

Вы тексты лицензий BSD и GPL читали когда-нибудь? Там в обоих отказ от любых гарантий.

Разве в "коммерческих" лицензиях не так?..

А зачем отдельные байтовые строки, если можно использовать вектор байт?

Это (пока?) только для no_std окружения. Ну и только с последней версии. Выше об этом писал, кстати.

Вдогонку: так-то в С++ тоже можно собрать код с -fno-exceptions и он может оказаться к этому не готов.

Понимаю как это звучит, но так-то завести ишью — ничего не стоит. Продумать и предложить RFC — несколько затратнее, но посильно и одному человеку и да, это может сделать любой. Если никто не собрался, то видимо действительно никому не мешает.

О чем и речь — нет никаких гарантий, что на это можно полагаться.

Если мы пишем не библиотеку или внутреннюю библиотеку, то есть.


Но костыли — это решение только наполовину, так сказать.

Я бы наоборот сказал, что раз это до сих пор костыль и нет ни ишью ни рфц, то не сильно оно и востребовано.

A panic in Rust is not always implemented via unwinding, but can be implemented by aborting the process as well.

Так я же об этом сам упомянул. Ну да, стратегия обработки паники задаётся на уровне исполняемого бинаря.

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

Смешно.

А можно раскрыть мысль? Да, в раст (и го) сообществе принято говорить, что мол исключений в языке нет, но так-то паника не особо от них отличается: можно перехватить, узнать тип, пробросить дальше. Да это несколько более многословно, чем в "языках с исключениями", использовать панику для обработки ошибок не принято, плюс в библиотеках не стоит полагаться на выбранную стратегию обработки паники, но принципиальных отличий не вижу.

Паники — те же исключения, так же можно поймать панику на OoM.

Нельзя. Сейчас ООМ — это аборт, а не паника. Вероятно, в будущем ситуация изменится, но пока так.

А вот забыть добавить что-то в switch-case — запросто. И никто не напомнит.

Это смотря где.

Имхо это как раз говорит о недостатках языка.

unsafe — это часть языка. Так-то и в С++ есть подмножество безопасных операций, просто они явно не выделены. Сборка мусора действительно многое упрощает, но для системного языка такие "сложности" — это вполне нормально, как мне кажется.

Tам memcpy, но суть в том, что компилятор не даст использовать "перемещённые" данные. Ну и я ещё раз подчеркну, что перемещение важно для данных вроде строк или векторов, которые состоят из указателя на данные и небольшого числа служебных полей. Для таких типов побитовое копирование дёшево, а глубокое — дорого.

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

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


Ну или более простой пример с сеттерами: хотим заменить значение поля. Можно передать по ссылке и скопировать, а можно переместить (передать владение). Если снаружи объект больше не нужен, то экономим на копировании.

Я что-то упускаю или тут не нужно копировать? Если операторы заимствуют значения, то по идее всё будет работать без изменений.

А вы уверены, что в расте при перемещении не происходит копирование пямяти?

Всё верно, копирование происходит, но тут важна разница между условным "копированием указателя" и глубоким копированием. На примере вектора: мы или перемещаем его (копируя только указатель, размер и capacity) или копируем все данные.

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

Information

Rating
5,063-rd
Date of birth
Registered
Activity