The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск языка программирования Rust 1.55, opennews (??), 09-Сен-21, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


83. "Выпуск языка программирования Rust 1.55"  –2 +/–
Сообщение от лолшто (?), 09-Сен-21, 22:51 
Господа, кто в теме глубоко разбирается: объясните чукче почему нужен именно отдельный язык Rust, а не Memory Safe C Compiler?
Ответить | Правка | Наверх | Cообщить модератору

85. "Выпуск языка программирования Rust 1.55"  +4 +/–
Сообщение от Аноним (113), 09-Сен-21, 22:54 
У си слишком красивый синтаксис
Ответить | Правка | Наверх | Cообщить модератору

198. "Выпуск языка программирования Rust 1.55"  +3 +/–
Сообщение от Аноним (255), 10-Сен-21, 11:36 
Но у Си фатальный недостаток - он придуман не Грэйдоном Хором.
Ответить | Правка | Наверх | Cообщить модератору

88. "Выпуск языка программирования Rust 1.55"  +/–
Сообщение от Аноним (88), 09-Сен-21, 23:08 
https://blog.logrocket.com/introducing-the-rust-borrow-checker/
Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

292. "Выпуск языка программирования Rust 1.55"  +1 +/–
Сообщение от Аноним (292), 10-Сен-21, 21:17 
Прочитал, предполагалась реклама, но для меня оказалась антирекламой.

Цитата:
"The borrow checker can be tricky to understand and work with — so much so that it’s pretty common for newcomers to the Rust community to get stuck fighting the borrow checker. I’ve personally lost many hours of my life to this struggle."

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

Необходимость передачи владения при передаче аргумента в функцию - очень редко возникающая ситуация (в расте она выполняется по-умолчанию, в отличие от С/С++, которые делают копию).
Чаще всего нужно наоборот - вернуть созданный внутри функции объект наружу.
В примере из статьи этот метод не применим, т.к. вектор используется после вызова функции.
Копировать все данные тоже не вариант - не оптимально. Остается только передать по ссылке.

Подозреваю, что из-за этих ограничений при передаче объектов, использование ссылок в расте (ради оптимальности естественно) распространилось как эпидемия. И для поддержания порядка в этом "генераторе ссылок" понадобился borrow checker.

Для сравнения: С++ предлагает множество вариантов передачи аргументов, в том числе все аналоги раста.
Какой именно больше подходит в конкретном случае, определяется архитектурой приложения.
И можно сделать так, чтобы беспокоиться о ручном освобождении памяти/объектов не нужно было.
Аналоги раста:
1) передача владения - явное использование std::move():  void f(std::unique_ptr<T> arg); f(std::move(object))
2) копия - void f(std::vector<T> array); f(objectsWithCopy)
2) ссылка - void f(std::vector<T> const& objectsByRef); f(objectsNoCopy)

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

Еще пример удобного управления временем жизни объектов можно найти в Objective-C: "Autorelease Pool".
Этому механизму уже несколько десятков лет (https://ru.wikipedia.org/wiki/Objective-C#Autorelease-%...).
А набор из нескольких простых правил пользования им вполне сходен с правилами которые налагает раст. Отличие в том, что в Objective-C эти правила должны войти в привычку, но оставляют программисту свободу, а раст просто запрещает всё кроме 3-х перечисленных случаев.


Короче, я вижу, что borrow checker - это не очень нужная мне фича, т.к. я уже научился проектировать управление временем жизни объектов и проблем с этим не возникает. Для тех, кто этому не научился, borrow checker - это ложное обещание того, что компилятор решит эти вопросы за них, а он их не решает. Он налагает ограничения (как по мне, слишком жесткие) на владение и передачу объектов, и пока нубы этому не обучатся, будут выгребать "error[E0382]: borrow of moved value" и "I’ve personally lost many hours of my life to this struggle."

Ответить | Правка | Наверх | Cообщить модератору

359. "Выпуск языка программирования Rust 1.55"  +/–
Сообщение от Ordu (ok), 12-Сен-21, 10:52 
> Необходимость передачи владения при передаче аргумента в функцию - очень редко возникающая ситуация (в расте она выполняется по-умолчанию, в отличие от С/С++, которые делают копию).

Во-первых, не так уж и редко. Не надо судить по опыту C/C++, как часто это оказывается полезным: в C/C++ невозможно передать владение. Там это никто не использует не потому, что не нужно, а потому что нельзя.

Во-вторых, копия по-дефолту -- это нарушение принципа "zero-cost abstraction". Передача копии -- это дорого. Не всегда, но очень часто.

В-третьих, дефолты меняются. Вот для тех случаев, когда удобнее передавать копию, перед декларацией типа можно написать #[derive(Copy)], тогда макрос derive напишет для этого типа реализацию трейта Copy (это пустой трейт, там нету методов, т.н. трейт-маркер), а компилятор, видя что тип -- Copy, будет передавать копию, вызывая метод clone для создания этой копии. Например, если ты напишешь

let x: i32 = 2;
foo(x);
println!("{}", x);

То это сработает. Компилятор не начнёт ругаться на то, что println! использует x, откуда значение было перемещено в foo. Магия? Не, если ты передашь в функцию i32, то туда будет передана копия значения. И всё потому, что для i32 реализован трейт Copy, то есть, как бы, i32-значение при передаче из одного места в другое автоматически вызывает свой метод clone. То есть, тот вызов foo, как бы заменяется на foo(x.clone()) автоматически.

Но это, понятно, хорошо только для небольших типов. Часто для всяких enum'ов используется. Или для векторов длиной с небольшое целое число, например, длины 4. Ну и понятно, что std делает это для всех примитивных численных типов.


То есть, практически, разница лишь в том, что для объектов, которые дорого копировать, тебе придётся явно вызывать clone(), вместо того, чтобы создавать копию неявно передачей по значению. Для объектов, которые копируются легко и непринуждённо, реализован Copy, и они передаются так же, как они передавались бы в C/C++.

Ответить | Правка | Наверх | Cообщить модератору

363. "Выпуск языка программирования Rust 1.55"  +/–
Сообщение от Аноним (363), 12-Сен-21, 15:32 
>> Во-первых, не так уж и редко.

Приведите примеры когда это нужно.

>> в C/C++ невозможно передать владение

Можно, см. std::move().

>> Передача копии -- это дорого.

Согласен, поэтому в С++ для таких случаев можно передавать (константные) указатели, ссылки или смарт-пойнтеры.


>> В-третьих, дефолты меняются.

В С++ тоже можно менять поведение класса при создании копии его объекта. Выполняется это переопределением конструктора копирования (и других методов, там где надо). Если очень нужна эффективность по-дефолту, чаще всего реализуют CopyOnWrite.

Ответить | Правка | Наверх | Cообщить модератору

370. "Выпуск языка программирования Rust 1.55"  +1 +/–
Сообщение от Ordu (ok), 12-Сен-21, 19:23 
>>> Во-первых, не так уж и редко.
> Приведите примеры когда это нужно.

Всё что угодно большое ты не будешь передавать "по-значению" без передачи владения, которая позволит избежать копирования. Если владение не передаётся, то компилятор вынужден создавать копию, дабы не было бы двух одновременных ссылок. Пример, может не очень "необходимого", но очень удобного -- это "типы-конструкторы":

let win = WindowBuilder::new()
    .size(800, 600)
    .title("Хелловорлд")
    .build();

Тут цепочка вызовов после new. new создаёт объект типа WindowBuilder, этот объект затем передаётся в size, где он модифицируется и возвращается, потом передаётся в title, где он модифицируется и возвращается оттуда, после чего он передаётся в build, который на основании значения типа WindowBuilder строит объект типа Window. Понятно, что при желании можно разорвать цепочку вызовов, сохранить промежуточный результат WindowBuilder в переменной, сделать что-нибудь ещё, потом продолжить. Ноль мутабельности, ноль ссылок. Никому не надо связываться со ссылками, потому что... а нахрена? Паттерн с передачей "по значению" с передачей владения моментально виден в документации. Скажем, вижу я в документации метод хештаблички into_values(self)->/*что-тотам*/,  я вижу, что self передаётся по значению, и моментально понимаю, что это _деструктивное_ преобразование хештаблички во что-то там, что судя по имени функции содежит все значения в хеш-табличке. После вызова её у меня не останется на руках исходной хеш-таблички.

Или, допустим, я вижу String::from_utf8(vec: Vec<u8>) -> Result<String, FromUTF8Error>, я моментально знаю, что from_utf8 "съедает" Vec<u8>, и даже не заглядывая в доки и сорцы, я спорить готов, что from_utf8 не выделяет память под новую строку, он повторно использует память Vec<u8>.

Или, скажем, я вижу конструктор BufReader<R>::new(inner: R) -> BufReader<R> where R: Read. Он принимает объект реализующий трейт Read (то есть у объекта есть метод read), употребляет его "насовсем", возвращает BufReader, то есть, в терминах STL/C++ это буферизованный istream. inner был небуферизованным, а BufReader -- буферизованный. Я вижу такое, и я понимаю, что мне не удастся попеременно читать буферизовано или небуферизовано, потому что BufReader хочет владеть низлежащим небуферизованным потоком. Зачем ему это надо, я не уверен навскидку, у меня есть разные предположения, но это другой вопрос.

А ещё у BufReader'а есть метод into_inner(self) -> R, который принимает self "по значению", то есть он употребляется насовсем, и возвращает R по значению, то есть совмещая это с конструктором, мы понимаем, что владением исходным небуферизованным istream'ом можно получить обратно, только BufReader этого не переживёт.

Ни в одном из этих примеров для объектов нет смысла передаваться по-дефолту созданием копии, потому что даже если бы это и было бы возможно, всё равно никто не пользовался бы этой возможностью. Иногда, может быть, в каких-то специальных условиях это имеет смысл, но на тот случай есть clone. А вот передавать владение объектом имеет глубинный смысл, как с точки зрения использования моментально детектируемого паттерна, так и с точки обеспечения безопасности. String сделанный на повторном использовании памяти с Vec появится только тогда, когда Vec прекратит существовать. А это значит, что не будет двух разных указателей на буфер в памяти хранящий char'ы, а значит не случится, например, такого, что один указатель падёт жертвой drop и освободит память, а другой указатель затем будет разадресован.

>>> в C/C++ невозможно передать владение
> Можно, см. std::move().

Нну, это костыль. Что-то типа того, но не то. std::move, как бэ, перемещает объект, но хех, что будет если ты сделаешь:

string s = "хеллоувролд";
foo(std::move(s));
std::cout << s << std::endl;

Будет UB. Я чесслово не знаю, что произойдёт, в силу всех этих оптимизаций, проводимых llvm и gcc, но при том уровне оптимизации который был в 90-х это бы означало, что s нихрена не переместился и остался доступен здесь.

Запрет на такие штуки на уровне ошибок компиляции очень важен, это гарантия того, что как в декларациях API написано его использовать, именно так его и будут использовать. Такие штуки могут приводить к нелокальным багам, после которых бывает очень сложно найти виноватого в рантайм-ошибке. А это значит, что от писателя вызывающего кода надо ждать очень точного понимания тех API, которые он дёргает. А это значит, что а) C++ программисты не любят внешние API, потому что их надо скрупулёзно изучать, прежде чем использовать, проще навелосипедить своё; б) писатели внешних API вынуждены думать, как бы так не разложить граблей, которые сложно заметить.

>>> В-третьих, дефолты меняются.
> В С++ тоже можно менять поведение класса при создании копии его объекта.
> Выполняется это переопределением конструктора копирования (и других методов, там где надо).
> Если очень нужна эффективность по-дефолту, чаще всего реализуют CopyOnWrite.

Когда я последний раз щупал эти конструкторы, они сделаны таким образом, что на них невозможно реализовывать некоторые паттерны безопасно. То есть, ты делаешь что-то эдакое, но чтобы оно работало, надо чтобы вызывающий код понимал как и что надо делать, чтобы не наступить на грабли. А это значит, что внутри реализации класса нет уверенности в том, на что можно положиться. Можно ли положиться, что вот этот вот inner istream внутри BufReader -- это владение BufReader? Когда выполняется BufReader::drop, следует ли вызвать drop на inner? Если inner принадлежит BufReader'у, то да, это _необходимо_, потому что иначе объект inner просто "утечёт": либо останется потерянный открытый файловый дескриптор, либо потерянный выделенный кусок кучи, либо и то и другое, и может быть ещё что-то третье. Если же вызывающий код сохранил у себя ссылку на inner, то такой drop приведёт к последующему use-after-free в вызывающем коде. Ну или если inner -- это просто файловый дескриптор, то вызывающий код либо столкнётся с внезапно ставшим невалидным файловым дескриптором, или, что хуже, будет читать из нового файлового дескриптора, который был открыт между drop и попыткой чтения и занял то же значение, что и дропнутый файловый дескриптор. А такое уже вообще хрен отладишь, потому что такая ошибка может вылезать в коде, который вообще никак логически не связан ни с данным инстансом BufReader'а, ни с кодом работающим с BufReader'ом. В смысле, глядя на место возникновения ошибки можно математически доказать, что там всё правильно написано и без ошибок, и это даже будет так, но ошибка всё равно будет возникать, и где тот код, который нacpaл? Как его найти теперь?

Ответить | Правка | Наверх | Cообщить модератору

375. "Выпуск языка программирования Rust 1.55"  +/–
Сообщение от Аноним (363), 12-Сен-21, 20:19 
>> Всё что угодно большое ты не будешь передавать "по-значению" без передачи владения, которая позволит избежать копирования. Если владение не передаётся, то компилятор вынужден создавать копию, дабы не было бы двух одновременных ссылок.

По значению передавать не буду, буду передавать другими способами, но передавать владение при этом вовсе не обязательно. Передача владения по-умолчанию приводит к борьбе программиста с борроу-чекером.
А где сказано, что компилятору (даже расту) нельзя создать несколько "одновременных ссылок"? В С++ такого ограничения вообще нет.

>> WindowBuilder

Да, для этого примера, передача владения работает как некая оптимизация, но это не единственный метод который позволяет избежать копирования в таком паттерне. В часности, компилятор С++ может выполнять технику "избежания копирования": https://en.wikipedia.org/wiki/Copy_elision#Return_value_opti...

>> String::from_utf8(vec: Vec<u8>) -> Result<String, FromUTF8Error>

Тут описан очень частный случай. Тк. если создается уникод-строка, то чаще всего под неё понадобится больше памяти чем есть у "vec" и выделять новый блок памяти всё-равно придется.
Если же String остается в UTF8 представлении, то эта функция - просто преобразование типов, которая скомпилируется в no-op. С точки зрения оптимизации, передача владения тут - сомнительная необходимость.

>> что будет если ты сделаешь:
>> string s = "хеллоувролд";
>> foo(std::move(s));
>> std::cout << s << std::endl;

Ничего "такого" не будет, cout "напечатает" пустую строку.

>> C++ программисты не любят внешние API

Откуда такая уверенность?

>> проще навелосипедить своё;

Это зависит от конкретной ситуации, бывает что проще своё написать.

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

Да, надо. Читайте документацию (и документируйте свой АПИ).

Ответить | Правка | Наверх | Cообщить модератору

379. "Выпуск языка программирования Rust 1.55"  +1 +/–
Сообщение от Ordu (ok), 12-Сен-21, 22:48 
>>> WindowBuilder
> Да, для этого примера, передача владения работает как некая оптимизация,

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

>>> String::from_utf8(vec: Vec<u8>) -> Result<String, FromUTF8Error>
> Тут описан очень частный случай.

Постоянный. Я тебе привёл ещё один пример ровно того же самого -- BufReader. Такие "преобразования типов" типичны. В качестве ещё одного примера: drain итераторы, например, создаются именно так, и позволяют тебе деструктивно вынимать из контейнера один элемент за другим вплоть до исчерпания контейнера.

В std есть стандартные трейты Into и From, которые забирают один объект насовсем, и возвращают другой. И трейты эти используются на регулярной основе. Скажем, если я вызвал функцию, получил ошибку, и хочу завершить функцию с ошибкой, то в некоторых случаях я буду возвращать err.into() -- компилятор сам подберёт нужную реализацию трейта Into, которая преобразует ошибку полученного типа, в ошибку возвращаемого типа.

Хотя, если точнее, Into и From не обязательно забирают объект насовсем -- это зависит от того, реализует ли тип объекта трейт Copy. Как правило они не реализуют, потому что копировать налево и направо неявным образом -- зашквар.

> Тк. если создается уникод-строка, то чаще всего
> под неё понадобится больше памяти чем есть у "vec" и выделять
> новый блок памяти всё-равно придется.

Нет. Это в C/C++ придётся выделять из-за нуля-терминатора, который постоянно мешает работать со строками, там без своей реализации строк вообще невозможно жить. В rust'е же не придётся ничего выделять, потому что нет никаких терминаторов. String отличается от Vec только тем, что String гарантирует валидность utf8, обеспечивает некоторые операции, специфичные для utf8 строк, не обеспечивает некоторые операции Vec, которые не очень работают с utf8 строками.

> Если же String остается в UTF8 представлении, то эта функция - просто
> преобразование типов, которая скомпилируется в no-op.

Нет, это не noop. Result видишь? Происходит проверка валидности utf8, потому что String гарантирует, что если String-объект существует, то он содержит валидный utf8. Кроме того, String и Vec, хоть и являются оба умными указателями на один и тот же буфер, и оба сводятся к трём полям -- buf, size, len, -- но они _разные_ умные указатели, там может быть другое расположение полей в структуре, например. String::from_utf8, я полагаю, делает Vec::into_raw_parts(self) с возвращаемым значением по типу (usize, usize, *u8) /* обрати внимание, опять тот же паттерн, Vec уходит в into_raw_parts насовсем и безвозвратно */, а потом создаёт из этих raw-parts новый объект String. Если случится чудо, и новый объект String будет бинарно идентичен старому объекту Vec, то перетасовка полей превратится в noop. Если нет, то значит это не будет noop'ом.

>>> что будет если ты сделаешь:
>>> string s = "хеллоувролд";
>>> foo(std::move(s));
>>> std::cout << s << std::endl;
> Ничего "такого" не будет, cout "напечатает" пустую строку.

А, да точно. Я увидел на cppreference в примере упоминание UB, но при внимательном изучении там оказывается, что UB возникает не из-за неопределённого состояния s, а из-за того, что s.back() при том состоянии -- это UB. (Не, ты прикинь, ты вызываешь внешний API, и он тебе выкидывает не ошибку, не исключение, но UB. Ипануцца!) Но это значит, что foo(std::move(s)) -- это вызов конструктора std::string для создания пустой строки в s? Нахрена? Не, я понимаю, что в данном случае компилятор отоптимизирует и выкинет ненужный вызов (хотя не, не выкинет, s ведь используется в operator<<). Но в каких-то других случаях, этот конструктор может иметь side-эффекты, он может быть тормозным, он может не инлайниться, и мы не будем использовать s после вызова foo, но компилятор не сможет доказать, что выкидывание этого вызова -- это законная оптимизация, а не саботаж задумки программиста. Мы получаем абстракцию, которая нихрена не zero-cost.

>>> C++ программисты не любят внешние API
> Откуда такая уверенность?

Сравни использование внешних зависимостей в rust'е с таковым в C++. Как давно тебе приходилось тянуть в свой проект зависимостью специфическую реализацию хештаблички, которая долго создаётся, не умеет добавлять элементы после создания, зато выделяет памяти ровно столько сколько нужно (а не на 20-50% больше) и гарантирует отсутствие коллизий? Или пакет для работы со временем, который умеет всё, что нужно тебе, а не только то, что в прошлом веке сочли нужным те, кто писал стандарт для стандартной библиотеки? Или пакет для url-encode/url-decode? Пакет для парсинга markdown? Реализацию sha512? Base64? Пакет для форматирования размера в понятном человеку виде -- в смысле чтобы не "310438330", а "297M". Все эти вещи в C и C++ принято велосипедить. В C++ может чуть меньше, но всё равно велосипедить. Опеннет полагает это признаком квалификации программиста и способом избежать dependency hell'а, что может быть и так, но это также приводит к появлению тысяч полусырых велосипедов. Зато мейнтейнерам дистров жить проще.

>>> проще навелосипедить своё;
> Это зависит от конкретной ситуации, бывает что проще своё написать.

В расте крайне редко это проще. Если нет, того что надо, то скорее всего есть почти то, что надо, а это значит, что проще туда пулл-реквест закинуть, который доведёт "почти то что надо" до уровня "то что надо". И это проще, в частности, потому что даже внутренние, возможно недокументированные, API пакета довольно прозрачны, очень легко работать с чужим кодом. Ты видишь #[derive(Copy,Clone)] ты знаешь всё что тебе нужно знать о реакции объекта на присваивание его куда-то, тебе не надо выискивать код трёх-четырёх конструкторов и продираться через него, чтобы понять, что, собственно, имелось в виду. Ты смотришь в код, и понимаешь задумку автора этого кода.

>>> надо чтобы вызывающий код понимал как и что надо делать, чтобы не наступить на грабли.
> Да, надо. Читайте документацию (и документируйте свой АПИ).

Это не всегда работает. Попробуй продраться через документацию, скажем, к ffmpeg, понять когда безопасно вызывать free на буфер, который ты передавал в недра ffmpeg, когда не стоит этого делать, а когда ни-ни-ни-низзя этого делать совсем. В расте полезно проконсультироваться на этот счёт с документацией, но там такие вопросы _прозрачны_, и, кроме того, если ты где-то что-то поймёшь неверно (потому что документация кривая, или потому что ты читал невнимательно), то тебе компилятор потом об этом сообщит, выкинув ошибку компиляции. Лучшая документация на код -- это сам код. Документация может отстать от изменений кода, или не отстать, а измениться вместе с версией библиотеки, но твой код так и останется написанным по старой версии документации.

Ответить | Правка | Наверх | Cообщить модератору
Часть нити удалена модератором

381. "Выпуск языка программирования Rust 1.55"  +/–
Сообщение от Ordu (ok), 12-Сен-21, 23:36 
> Я понял -  вы нашли своё растаманское счастье. Я не намерен
> вас его лишать.

Ох, как резко с обсуждения по существу на личности. Ничто не предвещало, и вдруг БАБАХ.

Ответить | Правка | К родителю #376 | Наверх | Cообщить модератору

367. "Выпуск языка программирования Rust 1.55"  +/–
Сообщение от Аноним (-), 12-Сен-21, 18:12 
>C/C++

Товарищ майор такого языка не существует.

Ответить | Правка | К родителю #359 | Наверх | Cообщить модератору

371. "Выпуск языка программирования Rust 1.55"  +/–
Сообщение от Ordu (ok), 12-Сен-21, 19:24 
>>C/C++
> Товарищ майор такого языка не существует.

Мне начхать.

Ответить | Правка | Наверх | Cообщить модератору

100. "Выпуск языка программирования Rust 1.55"  +6 +/–
Сообщение от Аноним (46), 09-Сен-21, 23:29 
Это как если бы у бабки был эцсамое.. Раст позволяет на писать код для очищения памяти(он его генерирует за программиста, причем можно явно понять в каком месте будет освобождена любая переменная и гарантирует что не будет утечек и doublefree, по крайней мере в unsafe-коде. Так же компилятор гарантирует что все ссылки всегда ссылаются на живые объекты и в расте в принципе не возможны null-pointer-exception'ы). Си можно было бы исправить, но из-за обратной совместимости это уже не будет си. С плюсами собсна то же самое.
Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

103. "Выпуск языка программирования Rust 1.55"  –3 +/–
Сообщение от СССР (?), 09-Сен-21, 23:33 
чем вам умные указатели не угодили? ну если быть внимательным не вариант
После раста что будет? зменить мозк на чип? ну как же, мозг он то боится то отвлекается, то и меет свою точку зрения, что не безопасно.
Ответить | Правка | Наверх | Cообщить модератору

107. "Выпуск языка программирования Rust 1.55"  +3 +/–
Сообщение от Аноним (13), 09-Сен-21, 23:46 
А где в чистом Си умные указатели? Стороннюю либу для этого тащить? Или свой велосипед писать?

Внимательнее быть не вариант - такая уж багонутая прошивка у homo sapiens. Особенно на больших и запутанных проектах. Периодически невнимательные все вплоть до kernelописателей, а потом cve с получением рута исправляют.

Ответить | Правка | Наверх | Cообщить модератору

115. "Выпуск языка программирования Rust 1.55"  –3 +/–
Сообщение от СССР (?), 10-Сен-21, 01:09 
> А где в чистом Си умные указатели? Стороннюю либу для этого тащить?
> Или свой велосипед писать?
> Внимательнее быть не вариант - такая уж багонутая прошивка у homo sapiens.
> Особенно на больших и запутанных проектах. Периодически невнимательные все вплоть до
> kernelописателей, а потом cve с получением рута исправляют.

в си не приходилось использовать умные указатели не сторонние (если таковые имеются) не реализовывать свой. В с++ пользуюсь QTшными, но и свой создать дело получаса, а после моно пользоваться. Если мне нужен стиль си то просто его использую и без умных указателей потому что о боже, не может быть , я с другой планеты, для меня в полне нормально внимательно создавать переменные указатели, освобождать память и обращатся к ней. Вы пытаетесь проблему идиота повесить на плечи нормальных людей. Если бы растоманы и прочие хайповые любители говорилибы так что вот вам новй язык который разработан для невнимательных программистов то все было бы логично, но когда читаешь про то что всякого рода клоуны теперь могут ликовать что все больше и больше не нужно думать своей головой а ЯП сам все за вас сделат. блин , да это быдло новость, и прививать эту было идею моветон среди порядочных людей.

Ответить | Правка | Наверх | Cообщить модератору

139. "Выпуск языка программирования Rust 1.55"  –2 +/–
Сообщение от An (??), 10-Сен-21, 06:55 
+
Ответить | Правка | Наверх | Cообщить модератору

216. "Выпуск языка программирования Rust 1.55"  +3 +/–
Сообщение от freecoderemail (ok), 10-Сен-21, 12:47 
Ага, появился ДВС - кучеры и конюхи сразу напряглись.
Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

413. "Выпуск языка программирования Rust 1.55"  +/–
Сообщение от СССР (?), 11-Окт-21, 23:41 
> Ага, появился ДВС - кучеры и конюхи сразу напряглись.

появление ДВС является прогресс, а вот появление телевизора является деградацией.
конечно смотря сколлько времени уделять и тому и тому, и какие цели при использовании. а то для того кто на тачке катается по городу и шлюх по дорогам снимает, то таким двигатель это не про прогресс.

двигатель и колесо - для вас ходить не нужно и педали крутить
телевизор - путишевствовать не нужно
раст - думать не нужно

что вам еще не хватает для полного счастья?

Ответить | Правка | Наверх | Cообщить модератору

251. "Выпуск языка программирования Rust 1.55"  +/–
Сообщение от VladShemail (?), 10-Сен-21, 14:43 
Если так рассуждать, то и другие проверки на уровне компиляции не нужны - нужно быть просто внимательным.

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

Ответить | Правка | К родителю #115 | Наверх | Cообщить модератору

259. "Выпуск языка программирования Rust 1.55"  –2 +/–
Сообщение от InuYasha (??), 10-Сен-21, 15:51 
"знать и учитывать" != "думать постоянно".
Ответить | Правка | Наверх | Cообщить модератору

414. "Выпуск языка программирования Rust 1.55"  +/–
Сообщение от СССР (?), 11-Окт-21, 23:46 
вы из крайности в крайности бросаетесь.
еще раз для тупоголового быдла ) если инструмен позволяет только упростить процесс создания чего либо - это хорошо.
если инструмент в чем то упрощает труд но в чем то ограничивает (пример  водолазный скафандр для охотника, да мошкара не кусает, но передвигаться становится не удобно) а так же если инструмент в последствии становится частью продукта - это не очень хорошо.

надеюсь понятно объяснил.

Ответить | Правка | К родителю #251 | Наверх | Cообщить модератору

116. "Выпуск языка программирования Rust 1.55"  –1 +/–
Сообщение от СССР (?), 10-Сен-21, 01:12 
> А где в чистом Си умные указатели? Стороннюю либу для этого тащить?
> Или свой велосипед писать?
> Внимательнее быть не вариант - такая уж багонутая прошивка у homo sapiens.
> Особенно на больших и запутанных проектах. Периодически невнимательные все вплоть до
> kernelописателей, а потом cve с получением рута исправляют.

и потом, вам для лэндинг-пэйджей зачем? вы вообще хоть чтото на с++ писали? )

Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

112. "Выпуск языка программирования Rust 1.55"  +2 +/–
Сообщение от Dzen Python (ok), 10-Сен-21, 00:31 
Уже писал уже как-то:
Мемори-сейф-си требует квалификации программиста гораздо выше средней.

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

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

Так вот, хрустик это всего лишь попытка максимально убыстрить и удешевить разработку того софта, что просто так в браузер не сунешь, для контингента, знакомого лишь с "программированием" на js, подкатыванием штанишек и разговорам через губу при реальном отсутствии даже намека на высшую нервную деятельность. Корпам нужно дешевое айтишное пушечное мясо, которое можно пасти не как умнейших людей поколения, а как обычных продавашек и впаривателей. Корпам нужен легко заменяемый, дешевый и достаточно запуганный т.н. "культурой отмены" офисный скот.

Все остальные аргумента хрустеров стоит рассматривать только в этом контектсе.

<\Нодискасс>

Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

120. "Выпуск языка программирования Rust 1.55"  +4 +/–
Сообщение от Наноним (?), 10-Сен-21, 01:55 
Твоя теория не подтверждается: школьники и дебилы, обозлённые сложностью вхождения в Rust, плюются говном в сторону его синтаксиса и концепций, которые осилить у них не получается.
Ответить | Правка | Наверх | Cообщить модератору

134. "Выпуск языка программирования Rust 1.55"  +/–
Сообщение от Аноним (134), 10-Сен-21, 05:22 
Сириус? И именно поэтому т.н. корпы так радостно наяривают на сиё творение? Рассказывают про то, что большинство ошибок в их корпо-коде связаны с работой с памятью и как они хотят побыстрее внедрить Раст?

Судя по вашему комментарию, если у школотронов и есть мнение про Раст, то оно фанатично-одобряющее. А своеобразный синтаксис только добавляет налёта илитарнасти. Они это любят.

Ответить | Правка | Наверх | Cообщить модератору

188. "Выпуск языка программирования Rust 1.55"  +2 +/–
Сообщение от ТотСамыйАноним (?), 10-Сен-21, 11:12 
Корпы наяривают на Go, JavaScript, Java. Rust лишь очень узкую нишу у них занимает.
Ответить | Правка | Наверх | Cообщить модератору

150. "Выпуск языка программирования Rust 1.55"  –1 +/–
Сообщение от Аноним (157), 10-Сен-21, 08:27 
>но у нас тут как бэ капитализм

бла-бла-бла, капитализьм польоха, угнетение, привилегии белых. Тху!

А  покажи ка пару хороших языков порожденных вне капитализма ?!

И еще напомню, угнетенной снежинке, что С родился внутри бессердечной капиталистической корпорации AT&T.
И призван он был быстрее клепать код (по сравнению с кучей ассемблеров).

>Вот тут и происходит конфликт интересов: прогер, могущий быстро и качественно писать на си, просит не просто много денег, но и серьёзные нематериальные и неденежные бенефиты, без которых - вся эта менеджерская мразота горько рыдает из-за отмененных рабства и крепостного права - он может просто тупо встать и тупо уйти в другую контору. Или даже работать на себя. Или присосаться к госкормушке. Или создать свою контору, СБиШ. Неважно. Так вот, мразота плачет и думает, как удешевить разработку и при этом уменьшить  вероятность ухода человека.

Вот тут в своем опусе меняй раст на С, а С на ассемблер и наслаждайся.

Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

236. "Выпуск языка программирования Rust 1.55"  +1 +/–
Сообщение от www2 (??), 10-Сен-21, 13:41 
>А  покажи ка пару хороших языков порожденных вне капитализма ?!

Рефал, ДССП.

Ответить | Правка | Наверх | Cообщить модератору

279. "Выпуск языка программирования Rust 1.55"  –1 +/–
Сообщение от Аноним (157), 10-Сен-21, 17:41 
если Рефал еще как-то похож на ЯП, то ДССП - это вообще какоето академическое убожество, которое морально устарело уже на момент создания.
Ответить | Правка | Наверх | Cообщить модератору

373. "Выпуск языка программирования Rust 1.55"  +/–
Сообщение от другой аноним (?), 12-Сен-21, 19:36 
Писал на ДССП в конце 80х. Оно какое угодно, только не "академическое". На практике это просто более удобный форт, чем форт. А на настоящий фортанутый форт мне мозги вывернуть так и не удалось. Неудобно всё: базовый набор слов для манипуляций стеком, вывернутый flow control, налепленные зачем-то сверху фичи времени компиляции (это в лиспе они уместны, но когда ты байтики экономишь -- нафига тебе ещё и мета?!). Для машинки с десятками килобайт памяти -- самое оно.
Ответить | Правка | Наверх | Cообщить модератору

295. "Выпуск языка программирования Rust 1.55"  +/–
Сообщение от Аноним (117), 10-Сен-21, 21:44 
ДССП - Для Служебного Системного Программирования
Ответить | Правка | К родителю #236 | Наверх | Cообщить модератору

330. "Выпуск языка программирования Rust 1.55"  –1 +/–
Сообщение от Аноним (-), 11-Сен-21, 17:03 
Гоподи какой унылый совок.
Ответить | Правка | Наверх | Cообщить модератору

374. "Выпуск языка программирования Rust 1.55"  +/–
Сообщение от Аноним (374), 12-Сен-21, 19:37 
Ну ведь соврамши товарищ, а вы повелись! Не так оно расшифровывается!
Ответить | Правка | Наверх | Cообщить модератору

185. "Выпуск языка программирования Rust 1.55"  +5 +/–
Сообщение от Аноним (13), 10-Сен-21, 11:05 
Проблема в том что погромисты даже с супер квалификацией не умеют в мемори-сейф-си. Раз в год, но и они стреляют себе в ногу. Есть только те кто рассказывает что "все вокруг рукожопы, а вот у меня ничего не падает".
И это прекрасно видно по спискам CVE в ядре линукса и популярных либах.

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

Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

192. "Выпуск языка программирования Rust 1.55"  –2 +/–
Сообщение от Аноним (134), 10-Сен-21, 11:18 
А знаешь, почему нет такого количества CVE в проетах на Расте? Очевидно, потому, что его используют полтора землекопа. И если он распространится, то будет то же самое. Или накатывать патчи на бгоугодный растософт - это будет совсем другое?
Ответить | Правка | Наверх | Cообщить модератору

197. "Выпуск языка программирования Rust 1.55"  +7 +/–
Сообщение от Аноним (13), 10-Сен-21, 11:32 
Нет, тоже самого не будет. Во всех проектах есть логические ошибки - и в с, и в раст - недавняя проблема с парсингом ip4 в растовой stdlib прекрасный пример. И от них не спасешься (кроме возможно формальной верификации, но это стоит кучу денег).
Но такого количества безумных проблем с памятью в расте не будет by design.
Ответить | Правка | Наверх | Cообщить модератору

332. "Выпуск языка программирования Rust 1.55"  –3 +/–
Сообщение от нах.. (?), 11-Сен-21, 18:10 
И вот сходу началось виляние.
Ответить | Правка | Наверх | Cообщить модератору

261. "Выпуск языка программирования Rust 1.55"  –1 +/–
Сообщение от InuYasha (??), 10-Сен-21, 15:56 
Так это хорошо - хаос, бурления и срывы покровов! И пусть обновляют своё проприетарное почаще. )
Говорите так, будто можно что-то написать один раз и навсегда (* таки, на теоретическом уровне, можно было и это уже сделали Дейкстра с Кнутом, например), но по факту всё равно будут раз в полгода обновляться стандарты, протоколы и чужие софты, так что, сидеть без обновлений всё равно не уастся.
Ответить | Правка | К родителю #185 | Наверх | Cообщить модератору

360. "Выпуск языка программирования Rust 1.55"  +/–
Сообщение от МояВенда (ok), 12-Сен-21, 11:26 
Попробуй хоть раз в жизни собрать что-нибудь стороннее из сорцов на C/C++. Вопросы отпадут сами.
Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру