Состоялся (https://blog.rust-lang.org/2019/02/28/Rust-1.33.0.html) релиз языка системного программирования Rust 1.33 (http://www.rust-lang.org), развиваемого проектом Mozilla. Язык сфокусирован на безопасной работе с памятью, обеспечивает автоматическое управление памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime.Автоматическое управление памятью в Rust избавляет разработчика от манипулирования указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п. Для распространения библиотек, обеспечения сборки и управления зависимостями проектом развивается пакетный менеджер Cargo (http://blog.rust-lang.org/2014/11/20/Cargo.html), позволяющий получить нужные для программы библиотеки в один клик. Для размещения библиотек поддерживается репозиторий crates.io (https://crates.io/).
В подготовке нового выпуска приняли участие 163 разработчика. Основные новшества (https://github.com/rust-lang/rust/blob/stable/RELEASES.md#ve...):- Расширены возможности функций, определённых с использованием выражения "const fn", которые могут вызываться не только как обычные функции, но и использоваться в любом контексте вместо констант. Данные функции вычисляются на этапе компиляции, а не в ходе выполнения, поэтому на них накладываются определённые ограничения, такие как запрет булевых операторов ("&&" и "||") и возможность чтение только из констант.
В новом выпуске внутри функций "const fn" добавлена возможность вызова других функций, определённых через выражение "const unsafe" (ранее допускался только вызов функций, определённых через "const fn"). Также обеспечена поддержка инициализированных присвоений let (например, "let mut x = 1" и "let mut x = 1"), явно типизированных шаблонов вида "const fn foo((x, y): (u8, u8)) { ... }", операторов присвоения ("x=y" и "x += y") и обособленных выражений (например, "3;").Указанные изменения позволили применить признак "const" для многих функций и методов стандартной библиотеки, включая overflowing_{add, sub, mul, shl, shr}, rotate_left, rotate_right, wrapping_{add, sub, mul, shl, shr}, is_positive, is_negative, get, count_ones, count_zeros, leading_zeros, trailing_zeros, swap_bytes, from_be, from_le, to_be, to_le и Ipv4Addr::new;
- Представлена концепция закрепления объектов в определённой области памяти (Pinning (https://doc.rust-lang.org/std/pin/index.html)), основанная на использовании типа std::pin::Pin‹P› (https://doc.rust-lang.org/std/pin/struct.Pin.html) и типажа (trait) std::marker::Unpin (https://doc.rust-lang.org/std/marker/trait.Unpin.html). Закрепление гарантирует, что объекты не будут перемещены и их размещение в памяти будет постоянным;
- Добавлена возможность (https://github.com/rust-lang/rust/pull/56303/) импортирования элементов как "_", что позволяет импортировать реализации (impl (https://doc.rust-lang.org/rust-by-example/generics/impl.html)) без определения отдельного имени в пространстве имён. Например "use std::io::Read as _;"
- Добавлен атрибут "cfg(target_vendor)", позволяющий выполнить код в привязке к целевой плтформе, например "#[cfg(target_vendor="apple")] fn main() { println!("Hello Apple!"); }";
- Реализована возможность указания нескольких условий в выражениях "if let" и "while let", например, "if let Creature::Crab(name) | Creature::Person(name) = state {";
- В разряд стабильных переведена новая порция API, в том числе стабилизированы методы unix::FileExt::read_exact_at, unix::FileExt::write_all_at, Option::transpose, Result::transpose,
convert::identity, pin::Pin, marker::Unpin, marker::PhantomPinned, Vec::resize_with, VecDeque::resize_with,
Duration::as_millis, Duration::as_micros и Duration::as_nanos;- В пакетный менеджер Cargo добавлена поддержка пересборки пакетов (crate) в случает изменения файла во время начальной сборки;
- В репозитории Crates.io для публикации новых пакетов теперь обязательно требуется подтверждение своего email;
- В компиляторе повышены требования к минимальной версии LLVM (теперь требуется 6.0) и добавлена поддежка архитектуры PowerPC64 во FreeBSD.URL: https://blog.rust-lang.org/2019/02/28/Rust-1.33.0.html
Новость: https://www.opennet.me/opennews/art.shtml?num=50235
> Для распространения библиотек, обеспечения сборки и управления зависимостями проектом развивается пакетный менеджер Cargo, позволяющий получить нужные для программы библиотеки в один клик. Для размещения библиотек поддерживается репозиторий crates.io.а можно попросить cargo собрать проект (с учётом всех зависимостей) -- но сказать ему чтобы он НЕ скачивал бы ни чего из сети (ни в коем случае!)? сказать чтобы вообще не пытался бы лесть в интернет (своими замечательными руками)?
то есть чтобы попробовал бы собрать из того что есть уже скаченного (очевидно нужно как-то указать на каталог где оно должно лежать скаченным) -- либо упасть с сообщением "ни чего не выйдет, запчастей не хватает! требуемые запчасти это РУЛЬ и КОЛЁСА, остальное всё пока-что кажется будто бы хватает"
# P.S.: сорян, не пишу на Rast поэтому такие примитивные вопросы
# P.P.S.: то есть речь идёт о ситуации когда нужно организовать на 100% ПОВТОРЯЕМЫЙ результат сборки, в независимости от того на каких компьютерах есть или нет интернета или какие-там-ip-адреса доступны/недоступны на каком-из-компьютеров (или автор пакета решил что-то удалить своего из сети, обидившись на свою жену).
> позволяющий получить нужные для программы библиотеки в один клик
подразумевается что просьба "не лезь в интернет" тоже хотелось бы в один клик :-)
cargo build --frozen
> cargo build --frozenсудя по описанию похоже на то что надо :-) ..
а путь к РУЛЮ и КОЛЁСАМ указывать-то можно?
Да, можно. В депендансах надо прописать что-то типа:[dependencies]
my-crate = { path="../my-crate" }Или можно попробовать через git:
[dependencies]
my-crate = { git="бла-бла-бла/", tag="v1.0" }Я сам не пробовал так, в примерах везде вместо "бла-бла-бла" ссылки, но подозреваю, что туда подставить путь к директории где git-реп лежит, то оно сработает: cargo склонирует оттуда нужную ревизию, и соберёт её.
> Да, можно. В депендансах надо прописать что-то типа:
> [dependencies]
> my-crate = { path="../my-crate" }
> Или можно попробовать через git:
> [dependencies]
> my-crate = { git="бла-бла-бла/", tag="v1.0" }менять исходный код нельзя (в том числе нельзя менять исходный код зависимостей, которые имеют другие зависимости, которые имеют другие зависимости -- вся эта глубокая-цепочка-зависмостей должна оставаться в оринигальном виде -- без наложения патчей).
можно только лишь командовать СНАРУЖИ всем этим :-)
то есть предполагаем что проект уже есть (изготовленный традиционным способом) а не с расчётом на offline-сборку, а теперь мы хотим его собрать, но при этои не давая cargo шанса залесть в сеть.
> Я сам не пробовал так, в примерах везде вместо "бла-бла-бла" ссылки, но подозреваю, что туда подставить путь к директории где git-реп лежит, то оно сработает: cargo склонирует оттуда нужную ревизию, и соберёт её.
так ли я понял что вобщем судя по всему -- нужно создать локальный репозиторий и всё накопировать туда?
а при сборке cargo -- сказать ему что-то типа "используй вот этот конфигурационный файл (вместо обычного конфигурационного файла)! а в конфигурационном файле лежат уже ссылки на локальный репозиторий" -- так?
или может не репозиторий а какой-то индивидуальный каталог кэша можно сделать? чтобы возиться поменьше, но получить сходный результат
> так ли я понял что вобщем судя по всему -- нужно создать локальный репозиторий и всё накопировать туда?Не. Это если я сделал git clone https://github.com/.../my-crate, а потом cargo берёт этот my-crate не с github'а, а из этого локального клона репа.
> или может не репозиторий а какой-то индивидуальный каталог кэша можно сделать? чтобы возиться поменьше, но получить сходный результат
У cargo при этом есть какая-то переменная окружения, которая рулит тем, куда он скачивает пакеты. Он по умолчанию складывает их в ~/.cargo, но можно складывать их куда угодно.
А если потом использовать --frozen, то он больше не будет скачивать.
> Он по умолчанию складывает их в ~/.cargo, но можно складывать их куда угодно.ну эт переменная по сути CARGO_HOME , тут понятно..
> А если потом использовать --frozen, то он больше не будет скачивать.
следовательно для того чтобы весь пазл сошёлся -- нужна ещё какая-то (какая?) инсталляционная cargo-команда которая бы взала бы исходный код пакета-зависимости (пакет-зависимость -- уже заведомо скаченный своим путём в ОБХОД cargo.. то есть это НЕ cargo fetch) и положила бы <что-то> в этот кэш ($CARGO_HOME/.cargo).
> нужна ещё cargo-команда которая бы собрала бы исходный код пакета-зависимости (пакет-зависимость -- уже заведомо скаченный МИМО cargo.. то есть это НЕ cargo fetch) и положила бы <что-то> в этот кэш ($CARGO_HOME/.cargo)Эмм... То есть, ситуация примерно такая. Вчера, перед тем как лечь спать, ты скачал тарболл с офигенно нужным тебе пакетом. Когда же ты встал с утра, то прочитал в новостях, что CIA передралось с ФБР, а ФБР с китайцами, и кто-то из них, решил что crates.io -- это самое удачное место, через которое можно напихать бекдоров потенциальному противнику. В результате теперь все пакеты в интернете теперь содержат бекдоров больше, чем в них строк кода есть. Тебе тем не менее хочется собрать вчера скачанный тарболл (он был скачан до начала конфликта и поэтому без бекдоров), но скачивать ничего ты не намерен. И вопрос собственно: возможно ли это. При этом, есть ещё два условия: 1) в CARGO_HOME уже лежит куча пакетов, которые были выкачаны раньше, и возможно их достаточно; 2) модифицировать сорцы из тарболла или из CARGO_HOME нельзя. Так?
У меня нет ответа на такой вопрос. Я не знаю. Мне кажется, что это нельзя сделать, не ковыряя вручную того, что лежит в ~/.cargo. А может даже ковыряя не удастся.
>[оверквотинг удален]
> ФБР, а ФБР с китайцами, и кто-то из них, решил что
> crates.io -- это самое удачное место, через которое можно напихать бекдоров
> потенциальному противнику. В результате теперь все пакеты в интернете теперь содержат
> бекдоров больше, чем в них строк кода есть. Тебе тем не
> менее хочется собрать вчера скачанный тарболл (он был скачан до начала
> конфликта и поэтому без бекдоров), но скачивать ничего ты не намерен.не совсем -- подразумевается что сборка проектов происходит на разных компьютерах, в том числе на сборочных серверах без доступа к интернету (без доступа к сети).
а не на одном и том же (одном) компьютере.
но кроме того то что на сборочных серверах нет доступа к интернету (а на некоторых сборочных-серверах он есть) -- есть ещё и ВТОРОЕ требование -- нужна ещё и гарантия того что у мы ТОЧНО знаем все источники из которых компилировались зависимости к проектам (в том числе источники с модифицированным (нашими руками) исходным кодом зависимостей).
если мы модицифируем исходный-код какой-то-там-зависимости -- то следущий раз сборочный сервер во чтобы то ни стало -- должен собрать уже СООТВЕТСТВУЮЩУЮ версию проекта (проекта который использует эту зависимость).
то есть независимо там от номеров версий или ещё каких-там-сраных кэшэй -- проект всегда должен (на сборочном сервере) собираться ВСЕГДА ровно из того что указано в его сборочных скриптах.
(НАПРИМЕР: исходный код какой-то зависимости поменялся, а номер версии остался тем же самым? не важно -- это не должно ничего портить!)
на сборочных серверах -- всегда кэши очищаются (и доступа в интернет нет, который бы доставил им свежий кэш откуда-то из глубины "облака"). исходных код зависимостей доставлется до сборочных серверов -- через свои собственные каналы. причём именно исходный код, а не уже-какая-то-предкомпилированная хеератень.
и вот и требуется чтобы сборка происходила РОВНО из тех исходных кодов которые бы доставлялись бы до сборочных серверов. и не из какого другого места.
и как и раньше говорил: собираем не свою программу а обычную какую-то программу написанную в обычном стиле (НЕ расчитанную на offline-компиляцию).
> И вопрос собственно: возможно ли это. При этом, есть ещё два
> условия: 1) в CARGO_HOME уже лежит куча пакетов, которые были выкачаны
> раньше, и возможно их достаточно; 2) модифицировать сорцы из тарболла или
> из CARGO_HOME нельзя. Так?ну тоесть на момент сборки (каждый раз перед сборкой) -- ни чего внутри $CARGO_HOME нет. для сборочного сервера -- каждая компиляция это как новая свежая система :-).
> модифицировать сорцы из тарболла или из CARGO_HOME нельзя. Так?
можно, но не желательно. судя из ответа я так понял -- это делать всё-таки придётся. а хотелось бы узнать можно ли это не делать.
> У меня нет ответа на такой вопрос. Я не знаю. Мне кажется,
> что это нельзя сделать, не ковыряя вручную того, что лежит в
> ~/.cargo. А может даже ковыряя не удастся.жаль..
ну тогда может спасёт накладывание патча на Cargo.toml (Cargo.lock) каждый раз перед сборкой (через sed например)
то есть как ты ранее сказал -- "модифицировать сорцы из тарболла или из CARGO_HOME нельзя. Так?" -- отказаться от этого требования
>ну тогда может спасёт накладывание патча на Cargo.toml (Cargo.lock) каждый раз перед сборкой >(через sed например)Нет, спасет только чтение документации. Там все ваши хотелки расписаны по ключам.
дай подсказку
работа на offline "Airplane" mode https://github.com/rust-lang/cargo/issues/4686 "почти закончена"
https://hackmd.io/hetFa17jRem_aKBCukrjVg#Cargo
#[cfg(target_vendor="dos")]
fn main() {
println!("This program cannot be run in DOS mode.");
}
Кроха сын к отцу пришёл, и спросила кроха: "Что сложнее C++ или Rust?"
Отец попросил кроху прийти лет через 30, когда разница в возрасте не будет так заметна)
Отец попросил кроху прийти лет через 30, когда он подучит С++
Если под сложностью понимать сложность самой реализации своих идей на языке, то сложнее C++. А вот если подразумевать сложность монетизации своих навыков, то сложнее Rust.
Есть мнение что это не надолго
Если C++ не осилить, то на нём конечно сложно написать что-либо полезное. Только вот ржавчина, у которой половина синтаксиса посвящена работе с памятью, в этом плане не легче.
У раста вообще синтаксиса много. И читается сложно
Отец ответил: "хз, шо там make, шо там make"
Сложнее понять, зачем вам вообще нужны эти монстры. D - наше всё. Особенно после появления бэкенда на LLVM.
На этот твой D даже Facebook забил. Не понятно зачем он нужен в свете C++20.
О да, Facebook же пуп Земли.
>C++20в котором опять не будет модулей
Features voted into C++20 in the winter meeting in February 2019 include:[34] [35]coroutines[36] – already experimentally supported in Clang 5[37]
modules[38] – experimentally supported in Clang 5[39] and Visual Studio 2015 Update 1[40] as well as GCC[41]
various improvements to structured bindings (interaction with lambda captures, static and thread_local storage duration)[42] [43]
в первый раз что ли? отложат как обычно
Чего отложат как обычно? Они это уже проголосовали в стандарт (читать умеешь?). Когда это они до этого выкидывали то, что уже проголосовали?
последний раз в c++ 17
Не было такого, не ври. В С++17 модули не голосовали никогда. Голосовали TS после принятия стандарта.
Ни холивара, но справедливости ради, таки выкинули concept'ы из С++0x. Прям из черновика стандарта судорожно вычищали в последний момент
Если справедливости ради - так их же не проголосовали в стандарт, а потом выкинули. Всё как Аноним из 7.75 и говорил.
> Если справедливости ради - так их же не проголосовали в стандарт, а
> потом выкинули. Всё как Аноним из 7.75 и говорил.Что значит "не проголосовали"? Их включили в стандарт, но до утверждения не дошло. С модулям тоже до утверждения ещё целый год. Могут и выкинуть, теоретически
Хомячкам сложно без уверенности в большом папке за спиной (читай лицокнига), без крутых тулчейнов и идеешек, с дебаггерами и рюшечками, без встроенной документации и телеграмм каналов с готовыми стогами ответов на стэк овер флоу
Абсолютно правы. Только не Facebook, а Mozilla.
Александреску облажался, впилив сборку мусора. Её-то сейчас можно отключить, только без неё тот же BCL не работает.
А ведь просили всего лишь допилить синтаксис крестов.
Вынужден открыто не согласиться, как бывший пользователь и фанат D. Я уже писал это и напишу ещё раз:
- Стабильные релизы D примерно равны по стабильности Rust nightly: тоже периодически падают на "хитром" коде, который в D уже сто лет как стандарт.
- Некоторые баги в D не лечатся десятилетиями: https://issues.dlang.org/show_bug.cgi?id=2043
Я сам наступал на эти грабли, писал багрепорт, писал на форум... Ноль реакции.
- Главные разработчики занимаются какой-то, простите, хернёй, вместо того, чтобы работать над важными задачами и чинить баги: например, Уолтер, главный разработчик и один из немногих знатоков компилятора, работает над взаимодействием (линковкой и т.п.) с кодом на C++. Ирония в том, что большинство пользователей D хотят убежать от C++ как можно дальше, и эта фича нужна только малому числу копропротивных пользователей, которым лень выкинуть свой шлак (так называемую "кодовую базу"), с кучей переполнениями стека, а также утечками и порчей памяти.
- shared - неюзабельное УГ, которое на бумаге выглядело хорошо, пока я не попытался использовать это в настоящем проекте. И стоило в объявлении класса писать shared, чтобы потом откастовывать его от всех полей класса внутри самого класса?
- Про микроконтроллеры можно забыть. Писать на D что-либо под STM32 - особый вид мазохизма.
- GC, всё ещё пронизывающий стандарную библиотеку.
- Всякие полезные атрибуты типа const, pure и @nogc не включены по умолчанию.
- ООП и наследование; трейты гораздо гибче.
- Разделение типов данных на ссылочные и нет. Захотел класс сделать структурой или наоборот? Скатертью дорога.
- Три разных компилятора. Моё мнение: выбросить велосипеды и оставить только LDC, ибо DMD генерит слабоватый код, а GDC сильно отстаёт по версии фронтенда.
- Вездесрущий null и всё, что с ним связано. После перехода на Rust вообще непонятно, зачем этот атавизм в современных языках программирования.Ну, и на все проблемы один ответ: "Хочешь фичи и багфиксы - пиши всё сам, у нас всё держится на коммьюнити" (читай: на соплях). А ведь раньше я тоже брызгал слюной и верил, что уж за 20-то лет D поднимется с колен, но воз и ныне там. D всё ещё мало пригоден для продакшена. Под продакшеном я понимаю нечто долговременное и надёжное, а не свои хобби-поделки с тремя звёздочками на гитхабе.
D вообще непонятно почему и зачем развивается, уже на rust есть вакансии, а на D нет вакансий;
они столько сил тратят на этот D, что лучше бы на тот же C++ тратили силы
Согласен. Но ещё лучше - на Rust. С++, как по мне, сам себя убивает с каждым новым стандартом.
Вы правда не понимаете? Столько раз об этом говорилось.
D и Rust не конкуренты. D --- акцент на быстрой(!) разработке при достаточной(!) надёжности, Rust --- обещание(!) надёжности.
Всё.
PS: C++ обещание современных высокоуровневых средств при максимально близком доступе к железу.далее выбираете тот инструмент, который Вам нужен, благо и D и Rust, не говоря о плюсах, к сегодня вполне себе допилен.
> писал багрепорт,я бы не стал *так* писать в багзилле. как-то хамством очень попахивает :)
>работает над взаимодействием (линковкой и т.п.) с кодом на C++.
конечно. слишком много кода на плюсах, убежать или переписать его невозможно (и попросту, глупо).
Жаль, что умер DSOM, не было-бы проблем с межъязыковыми связями.>Ирония в том, что большинство пользователей D хотят убежать от C++ как можно дальше,
наверное, все-таки, не убежать, а минимизировать объём усилий в плюсах.
Совсем убежать не выёдет (см выше).>shared - неюзабельное УГ, которое на бумаге выглядело хорошо
очень сильное утверждение. Надо же понимать, как это сделано и ограничения!
>Про микроконтроллеры можно забыть. Писать на D что-либо под STM32 - особый вид мазохизма.
Да. Но такие цели и не ставились. Но и сказать, что нельзя запилить соотв. средства, тоже преувеличение. Понадобится кому --- сделает, нет сомнений.
>GC, всё ещё пронизывающий стандарную библиотеку.
и что?
>Всякие полезные атрибуты типа const, pure и @nogc не включены по умолчанию.
и что? разработчик, что, трёхлетка, которого надо водить за ручку? сам написать не может?
> ООП и наследование; трейты гораздо гибче.
о как. а трейты и соотв., миксины?
>Разделение типов данных на ссылочные и нет. Захотел класс сделать структурой или наоборот?
А изучить теорию, *почему* этио было сделано? Ведь заведомо ссылочная природа класса в ООП сразу решает массу неприятных проблем.
>Три разных компилятора.
и что? компилятор -- не Дункан Мак'Лауд
>Вездесрущий null и всё, что с ним связано. После перехода на Rust вообще непонятно, зачем этот атавизм
А что ты бы предложил?
>Хочешь фичи и багфиксы - пиши всё сам
я бы тоже был счастлив, если бы кто-то крупный взял бы проект под крыло. Очевидно, не так-то это просто, даже если у кого-то из китов и есть заинтересованность.
>Под продакшеном я понимаю нечто долговременное и надёжное
будет развитие, будут и ресурсы на стабильность. плюнем все дружно --- ну, там оно и останется.
[{[][Objectiv-C}{][)
> избавляет разработчика от манипулирования указателямиВот не могу понять, почему при всех фичах этого языка в первую очередь принято говорить об избавлении от указателей? С каких пор проблемы людей, не умеющих складывать целые числа, стали основной заботой разработчиков ЯП?
При чём тут "складывать числа"? Речь о другом. Скажем rust отслеживает ownership за тебя, а это значит, что ты не упрёшься в ситуацию, когда у строки есть два "владельца", и статически невозможно решить, кто из них должен освобождать память. Точнее даже не так. Это в C у тебя есть возможность подобную ситуацию не заметить, и эскалировать её до того, что один владелец освободит память, а другой продолжит ею пользоваться. В rust'е же ты как раз упрёшься в эту ситуацию лбом, потому что получишь ошибку компиляции.Разруливать эту ситуацию всё равно придётся тебе -- создавая лишнюю копию строки, или перелопачивая код так, чтобы не возникало нужды освобождать память дважды. То есть, фразировка в новости не совсем верная: манипулировать указателями придётся программисту. Но под пристальным оком борроу-чекера, который будет раздавать пинков за любое проявление неспособности просчитать лайфтаймы объектов в уме.
При чём тут "Это в C"? Скажем C++ отслеживает ownership за тебя.Но разруливать дизайн всё равно придётся тебе -- выбирая подходящий тип смартпоинетра.
> При чём тут "Это в C"? Скажем C++ отслеживает ownership за тебя.Но это все не то.
https://vnduongthanhtung.gitbooks.io/migrate-from-c-to-rust/...
> The operator = in Rust, by default, is equivalent to the move operator in C++.
> After the = operator in Rust, the original object becomes invalid. In Rust, accessing variable after it no longer owns an object, will raise an error during compilation. In C++, there is no compilation error but the program will encounter some unexpected results.А уж концепта отслеживания времени жезни (как впрочем и "одалживания") в плюсах вообще нет:
https://vnduongthanhtung.gitbooks.io/migrate-from-c-to-rust/...
>> При чём тут "Это в C"? Скажем C++ отслеживает ownership за тебя.
> Но это все не то.
>> is equivalentВы уж как-нибудь определитесь.
> А уж концепта отслеживания времени жезни (как впрочем и "одалживания") в плюсах
> вообще нет:И без ссылки верю, что разрулить не получилось.
>>> is equivalent
> Вы уж как-нибудь определитесь.Вы уж как-нибудь научитесь читать не по частям:
>>> After the = operator in Rust, the original object becomes invalid. In Rust, accessing variable after it no longer owns an object, will raise an error during compilation. In C++, there is no compilation error but the program will encounter some unexpected results.-
>> А уж концепта отслеживания времени жезни (как впрочем и "одалживания") в плюсах
>> вообще нет:
> И без ссылки верю, что разрулить не получилось.Понимаю. Ходить по ссылкам, еще и читать целиком, осмысливая ...
>>>> is equivalent
>> Вы уж как-нибудь определитесь.
> Вы уж как-нибудь научитесь читать не по частям:
>>>> After the = operator in Rust, the original object becomes invalid. In Rust, accessing variable after it no longer owns an object, will raise an error during compilation.Это описание move, она была в цитате выше. В С++ она в наличии. Эквивалент.
> In C++, there is no compilation error but the program will encounter some unexpected results.
Зависит тот имплементации operator=().
>>> А уж концепта отслеживания времени жезни (как впрочем и "одалживания") в плюсах
>>> вообще нет:
>> И без ссылки верю, что разрулить не получилось.
> Понимаю. Ходить по ссылкам, еще и читать целиком, осмысливая ...Если ты не осмыслил, то мне оно не зачем. Исходный мой тезис: "разруливать" приходится автору.
С тех пор как работа с указателями стала отвлекать от бизнеслогики
Для маленький программ проблем нет, но проблемы больших и производительных систем очень заметны.
Мы пытаемся уменьшить количество человеко часов, но когда система разрастается приходиться делить её на модули что опять не очень хорошо но это один из эффективных способ масштабирования проекта. Также очень желательно что бы разработчика не отвлекал ЯП на рутину в виде указателей и отладки.
Да. Интересный вопрос. Для сравнения:Имеет тонкий и быстрый FFI, обеспечивающий полное двустороннее взаимодействие с языком Си (вплоть до взаимной рекурсии); а также генератор привязок NLFFI (No-Longer-Foreign Function Interface), позволяющий встраивать заголовочные файлы Си прямо в проект на *** и использовать прямые вызовы функций Си в программах на ***.
После утверждения модулей, сопрограмм и многих прочих вкусностей в C++20 растишку можно закапывать.
Сипипи давно уже из могилы вещает, так что непонятна ваша радость на похоронах :)
А вот в C# появился pattern matching. Ни бог весть какая фича, но на понимание кода влияет сильно. Возврат кортежей - тоже удобно. Сам язык тоже всё больше упирает на лаконичность и читаемость. На его фоне юзать сипипи - можно оправдать только если вы полностью погружены в линукс.
> Ни бог весть какая фича, но на понимание кода влияет сильно. Возврат кортежей - тоже удобно.система алиасов -- недоделана доконца! а они каккую-то дополнительную хрень выдумывают.
A using alias directive cannot have an open generic type on the right hand side. For example, you cannot create a using alias for a List<T>, but you can create one for a List<int>.
вот просто где тут логика? почему нельзя сделать алиас на неуточнённый генерик?
любой алиас сделать можно -- но на неуточнённый генерик сделать алис нельзя (ЗА ШТО?!)-- "тут играем тут не играем"
Я больше скажу — алиас на алиас всё ещё иногда не собирается.
> А вот в C#И что мне делать с тюремным С на платформах отличных от windows? Есть нормальные опенсорсные тулзы для него?
А то пока С#, windows, visual studio неразрывно связаны. Голимая прориетарщина.
> Есть нормальные опенсорсные тулзы для него?Нормальные тулзы кроме JetBrains вообще кто-нибудь делает? Скажем, для какой технологии есть действительно вменяемая IDE, и это не intellij?
> А то пока С#, windows, visual studio неразрывно связаны.
Большинство моих коллег поменяло VS+r# на Rider. Движение идёт в сторону .netcore. Надеемся, ждём
> Голимая прориетарщина.
Ну да. Тут не поспоришь.
> для какой технологии есть действительно вменяемая IDE, и это не intellij?VSCode для JS\TypeScript. Такой себе ответ, но всё же.
Когда на ржавчине напишут хоть что-нибудь полезное кроме двух процентов кода Firefox, тогда и будете рассказывать про его преимущества над C++.
Этот Си-паунд уже можно компилировать напрямую в нативный машинный код без костылей вроде CLR?
До-диез же.
Это тот тюремный с с рантаймом, il'ом и раздутой либой? Пускай идёт с джавой конкурировать и то только на винде. Плюсам он не ровня, а если мне будет плевать на производительность, я просто возьму питон.
Иногда возникает ощущение, что скорее выйдет Half-Life 3, чем наконец утвердят стандарт модулей C++.
его утвердили https://www.reddit.com/r/cpp/comments/au0c4x/201902_kona_iso.../
Кул. Правда, насколько я понимаю, речь пока о черновике, который теоретически могут в текущем виде и не принять.
Его могут поправить, но не принять не могут. Модули уже много лет мусолят, их планировали к C++17, на них было TS, две реализации в Clang, по одной в GCC и MSVS. Этот черновик не с бухты барахты.
Могут, могут. См. мой коммент выше про C++0x concepts.
> его утвердили https://www.reddit.com/r/cpp/comments/au0c4x/201902_kona_iso...Half-Life 3 утвердили? Ну наконец-то!
> C++ Committee Trip ReportЭто объясняет текущее состояние плюсов )
> при этом обходясь без использования сборщика мусора и runtimeПрекратите уже повторять этот бред из новости в новость. Rust использует рантайм LLVM, причем, например, паники там реализованы с использованием механизма исключений C++.
Т.е реализовать zero runtime как в си нельзя?
Можно. Есть режим 'без стандартной библиотеки'.
> Т.е реализовать zero runtime как в си нельзя?Если на нем реализовали вполне работающую на реальном железе (пусть и игрушечную) ОСь и загрузчик:
https://www.redox-os.org/
https://github.com/rust-osdev/bootloader
> An experimental x86 bootloader written in Rust and inline assembly.то наверное таки реализовать можно.
>> Т.е реализовать zero runtime как в си нельзя?
> Если на нем реализовали вполне работающую на реальном железе (пусть и игрушечную)
> ОСь и загрузчик:
> https://www.redox-os.org/
> https://github.com/rust-osdev/bootloader
>> An experimental x86 bootloader written in Rust and inline assembly.
> то наверное таки реализовать можно.Даже сорцы смотреть нет смысла, достаточно описания коммита:
"Use only `si` instead of `esi` for println in real mode (#47)"SI это имя регистра, то есть загрузчик написан на языке ассемблера.
> Даже сорцы смотреть нет смысла, достаточно описания коммита:
> "Use only `si` instead of `esi` for println in real mode (#47)"
> SI это имя регистра, то есть загрузчик написан на языке ассемблера.
> загрузчик
> на языке ассемблера.Ну-ка, ну-ка. Код для MBR на плюсах, с инициализацией регистров, с точным контролем адресов инструкций и данных - в студию! Так и быть, читать с носителя за отсутствием рантайма, разрешаю через либастрал.
"А потов-то, а понтов!" (с)
>> Даже сорцы смотреть нет смысла, достаточно описания коммита:
>> "Use only `si` instead of `esi` for println in real mode (#47)"
>> SI это имя регистра, то есть загрузчик написан на языке ассемблера.
>> загрузчик
>> на языке ассемблера.
> Ну-ка, ну-ка. Код для MBR на плюсах, с инициализацией регистровМожет заодно и работу твою за тебя скампелировать?
asm - ключевое слово языка. ,-)
> с точным
> контролем адресов инструкций и данных - в студию!А вот это даже на асме зачастую лишнее.
> Так и быть,
> читать с носителя за отсутствием рантайма, разрешаю через либастрал.
> "А потов-то, а понтов!" (с)Да, я бы на твоём месте вёл себя поскромнее.
>> Ну-ка, ну-ка. Код для MBR на плюсах, с инициализацией регистров
> Может заодно и работу твою за тебя скампелировать?О, мы опять имеем счастье и честь лицезреть великих гуру опеннета!
>> SI это имя регистра, то есть загрузчик написан на языке ассемблера.
> asm - ключевое слово языка. ,-)А, ну если так, то это конечно уже не язык ассемблера. И регистры там не регистры.
>> с точным контролем адресов инструкций и данных - в студию!
> А вот это даже на асме зачастую лишнее.Ну раз гуру опеннета так говорит … в общем, "show me the code" или балабол.
Ну, код ты в доказательство своей гипотезы не показал, так что... ;-)
> Даже сорцы смотреть нет смысла, достаточно описания коммита:
> "Use only `si` instead of `esi` for println in real mode (#47)"
> SI это имя регистра, то есть загрузчик написан на языке ассемблера.О, сколько нам открытий чудных!
Вы только не расстраивайтесь:
http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/boo...
/* Print message string */
#define MSG(x) movw $x, %si; call LOCAL(message)
#define ERR(x) movw $x, %si; jmp LOCAL(error_message)
>> Даже сорцы смотреть нет смысла, достаточно описания коммита:
>> "Use only `si` instead of `esi` for println in real mode (#47)"
>> SI это имя регистра, то есть загрузчик написан на языке ассемблера.
> О, сколько нам открытий чудных!
> Вы только не расстраивайтесь:
> http://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/boo...
>/* Print message string */
> #define MSG(x) movw $x, %si; call LOCAL(message)
> #define ERR(x) movw $x, %si; jmp LOCAL(error_message)
>А разве кто-то утверждал, что это тоже на Rust?
> А разве кто-то утверждал, что это тоже на Rust?А кто утверждал-то, что оно полностью на Rust? Какое именно слово в процитированом "in Rust and inline assembly" вам не понятно? Не томите, расскажите!
Было логичное предположение, что те, кого возможность реализации "zero runtime" интересует не только сугубо теоретически, более-менее в курсе, что классический загрузчик для x86 без частей на асме пишется весьма фигово (от слова никак). Ну или хотя бы перед ответом прочтут написаное. Видимо я ошибся, увы мне :(Или это обычное "когда нечего возразить, но очень подгор^W хочется — прискипайся к формулировке"?
>> А разве кто-то утверждал, что это тоже на Rust?
> А кто утверждал-то, что оно полностью на Rust?В #110 анон утверждает, требуя от меня аналогичный код на плюсах для опровержения его гипотезы. :)
> Какое именно слово в
> процитированом "in Rust and inline assembly" вам не понятно?Там не инлайн, если уж заниматься буквоедством, а вполне файлы *.s
> Не томите, расскажите!
> Было логичное предположение, что те, кого возможность реализации "zero runtime" интересует
> не только сугубо теоретически, более-менее в курсе, что классический загрузчик для
> x86 без частей на асме пишется весьма фигово (от слова никак).Вот пример вполне практического "zero-runtime" на С++ https://github.com/icestudent/ontl/tree/master/ntl/rtl
К бутлоадерам отношения не имеет.
Асм там может потребоваться* - обратите, пожалуйста, на этот момент внимание - потому что тамошний компилятор для поддержки исключений генерирует определённые структуры, для работы с которыми интринсиков недостаточно.
Теперь возвращаемся к исходной посылке "рантайм LLVM, причем, например, паники там реализованы с использованием механизма исключений C++".
Так вот мне, что бы считать "реализовать можно" без "наверное таки", желательно увидеть подобную реализацию, иначе может оказаться, что .s файлов по объёму там достаточно для имплементации незаурядной Forth-машины (и она будет считаться zero-runtime :))
*) frestanding implementation допускает отсутствие исключений, в таком случае имеем свободное от ассемблера "zero-runtime".
>>> А разве кто-то утверждал, что это тоже на Rust?
>> А кто утверждал-то, что оно полностью на Rust?
> В #110 анон утверждает, требуя от меня аналогичный код на плюсах для
> опровержения его гипотезы. :)Э-э, это конечно же, очень-очень интересно … но причем тут именно эта вот ветка?
> Там не инлайн, если уж заниматься буквоедством, а вполне файлы *.sЕсли заниматься буквоедством, то в GRUB точно то же кино с файлами. При этом MS VC++ инлайном ни в армщину, ни в 64 бита не умеет, да и вообще по стандарту:
> The asm declaration is conditionally-supported; its meaning is implementation-defined..
> Вот пример вполне практического "zero-runtime" на С++ https://github.com/icestudent/ontl/tree/master/ntl/rtl
> К бутлоадерам отношения не имеет.
> Асм там может потребоваться* - обратите, пожалуйста, на этот момент внимание -
> потому что тамошний компилятор для поддержки исключений генерирует определённые структуры,
> для работы с которыми интринсиков недостаточно.А, это такое замысловатое "да, но пока еще нет, но почти что да, только пока нет"? :)
Кстати, если уж буквоедствовать, то интринсики (которые вроде как и в ржавчине не один год имеются) у нас в каком стандарте-то прописаны?> Теперь возвращаемся к исходной посылке "рантайм LLVM, причем, например, паники там реализованы
> с использованием механизма исключений C++".
> Так вот мне, что бы считать "реализовать можно" без "наверное таки", желательно
> увидеть подобную реализациюhttps://os.phil-opp.com/freestanding-rust-binary/
https://github.com/phil-opp/blog_os/blob/post-01/src/main.rsБинарник в пару KB (на самом деле, заполнен нулями чуть менее чем полностью), без зависимостей, нормально собирается и исправно запускается, демонстрируя JMP@here в gdb.
cargo rustc -- -Clink-arg=-nostartfiles
Тот же cargo rustc -- -Clink-arg=-nostartfiles --emit asm
дает выхлоп:
.text
.file "blog_os.6pwfxw6d-cgu.0"
.section .text._start,"ax",@progbits
.globl _start
.p2align 4, 0x90
.type _start,@function
_start:
pushq %rbp
movq %rsp, %rbp
.p2align 4, 0x90
.LBB0_1:
jmp .LBB0_1
.Lfunc_end0:
.size _start, .Lfunc_end0-_start.section .text.rust_begin_unwind,"ax",@progbits
.hidden rust_begin_unwind
.globl rust_begin_unwind
.p2align 4, 0x90
.type rust_begin_unwind,@function
rust_begin_unwind:
pushq %rbp
movq %rsp, %rbp
.p2align 4, 0x90
.LBB1_1:
jmp .LBB1_1
.Lfunc_end1:
.size rust_begin_unwind, .Lfunc_end1-rust_begin_unwind
.section ".note.GNU-stack","",@progbits
очень смахивет на q.e.d.
>>>> А разве кто-то утверждал, что это тоже на Rust?
>>> А кто утверждал-то, что оно полностью на Rust?
>> В #110 анон утверждает, требуя от меня аналогичный код на плюсах для
>> Там не инлайн, если уж заниматься буквоедством, а вполне файлы *.s
> Если заниматься буквоедством, то в GRUB точно то же кино с файлами.Э-э, это конечно же, очень-очень интересно … но
причем тут GRUB? :)> При этом MS VC++ инлайном ни в армщину, ни в 64
> бита не умеет, да и вообще по стандарту:
>> The asm declaration is conditionally-supported; its meaning is implementation-defined.Повторюсь (было в сноске), поддержка исключений по стандарту не обязательна. Без них остаётся чистый С++. (впрочем, поддержку исключений GCC можно в упомянутую реализацию добавить).
>> Вот пример вполне практического "zero-runtime" на С++ https://github.com/icestudent/ontl/tree/master/ntl/rtl
> > К бутлоадерам отношения не имеет.
>> Асм там может потребоваться* - обратите, пожалуйста, на этот момент внимание -
>> потому что тамошний компилятор для поддержки исключений генерирует определённые структуры,
>> для работы с которыми интринсиков недостаточно.
> А, это такое замысловатое "да, но пока еще нет, но почти что
> да, только пока нет"? :)Это такое прямое и вполне прикладное применение "на С++ можно писать драйвера (даже несмотря на заявления производителя тамошней ОС об обратном)".
На Rust можно? Есть примеры? Бутлоадеры и студенческие ОС это очень интересно, но немножко ближе к теории, чем к практике.
> Кстати, если уж буквоедствовать, то интринсики (которые вроде как и в ржавчине
> не один год имеются) у нас в каком стандарте-то прописаны?Так нет их в исходниках (вместо них авторам пришлось использовать асм - в опциональной части).
>> Теперь возвращаемся к исходной посылке "рантайм LLVM, причем, например, паники там реализованы
>> с использованием механизма исключений C++".
>> Так вот мне, что бы считать "реализовать можно" без "наверное таки", желательно
>> увидеть подобную реализацию
> https://os.phil-opp.com/freestanding-rust-binary/
> https://github.com/phil-opp/blog_os/blob/post-01/src/main.rs
> Бинарник в пару KB (на самом деле, заполнен нулями чуть менее чем
> полностью), без зависимостей, нормально собирается и исправно запускается, демонстрируя
> JMP@here в gdb.Спасибо. Вот только бинарник ничего не делает.
>[оверквотинг удален]
> movq
> %rsp, %rbp
> .p2align
> 4, 0x90
> .LBB0_1:
> jmp
> .LBB0_1
> .Lfunc_end0:
> .size _start,
> .Lfunc_end0-_startВот тут обозначен диапазон адресов, где может быть сгенерировано исключение?
Что делать с этим в _произвольном_ месте в ядре? Вот в чём вопрос.>[оверквотинг удален]
> .LBB1_1:
> jmp
> .LBB1_1
> .Lfunc_end1:
> .size rust_begin_unwind,
> .Lfunc_end1-rust_begin_unwind
> .section
> ".note.GNU-stack","",@progbits
>
>> JMP@here в gdb.
> Спасибо. Вот только бинарник ничего не делает.Вам, анонимам, не угодишь – то вам "файлов по объёму там достаточно для имплементации незаурядной Forth-машины", то компактная демонстрация, реализуемая штатными методами без UD и прочих хаков – наоборот, ничего не делает.
> Вот тут обозначен диапазон адресов, где может быть сгенерировано исключение?
> Что делать с этим в _произвольном_ месте в ядре? Вот в чём вопрос.Неужели так сложно было пройти по ссылке на код в пару строк?
Это реализация обработчика паник, о котором изначально и шла речь в #27 "паники там реализованы с использованием механизма исключений C++."
// This function is called on panic.
#[panic_handler]
fn panic(_info: &PanicInfo) -> ! {
loop {}
}
> Вам, анонимам, не угодишь –
> то вам "файлов по объёму там достаточно для имплементации незаурядной Forth-машины",
> то компактная демонстрация, реализуемая штатными методами
> без UD и прочих хаков – наоборот, ничего не делает.Не делает ничего, и не обрабатывает исключения. Запустите это без системного загрузчика и будет ой.
>> Что делать с этим в _произвольном_ месте в ядре? Вот в чём вопрос.
> Неужели так сложно было пройти по ссылке на код в пару строк?
> Это реализация обработчика паник, о котором изначально и шла речь в #27
> "паники там реализованы с использованием механизма исключений C++."Это не ответ не вопрос.
Этот Rust ещё толком не родился, а уже весь в [s]костылях[/s] макросах.
Его на ходу патчат левой пяткой, проектирование языка не для них.
Идём смотрим на пример реальной программы на этом язычке: https://gitlab.gnome.org/GNOME/fractal/issues/431 И что мы там видим? Конечно панику.
Вроде и радоваться надо, что кривой индонигeрский код падает с паникой, а не творит делов, но там куча issues один другого лучше.
Все правильно, в c/c++ получили бы чтение и использование неинициализированной памяти, в rust - паника. Именно так все и задумывалось.
В C++ было бы исключение, которое было бы поймано и обработано. В Rust исключений нет, поэтому паника на любой чих.
У Раста панику можно обработать внутри кода, дубина.
У очередного растамана пригорело. Вам специально сделали язык, чтобы вы не игнорировали возвращаемые ошибки, так вы придумали макрос unwrap, который паникует при любой ошибке. Алсо It is not recommended to use [std::panic::catch_unwind] for a general try/catch mechanism. A panic in Rust is not always implemented via unwinding, but can be implemented by aborting the process as well.
> A panic in Rust is not always implemented
> via unwinding, but can be implemented by aborting the process as
> well.Так это же Undefined behavior.
В Расте гибко сделана обработка ошибок, это может быть паника, либо обработка этой паники.
В чем претензия у Вас?
> В C++ было бы исключение, которое было бы поймано и обработано. В
> Rust исключений нет, поэтому паника на любой чих.Оно было бы обработано примерно так:
int main() {
try {
real_main();
} catch (...) {
cerr << "Spurious exception caught. Some of us, stupid coders did something nasty.";
return -1;
}
}Может быть это происходило бы не в main'е, а где-то ещё, но в любом случае, с точки зрения программы это бы выглядело как "непредвиденное исключение вылетело, единстсвенный выход -- упасть, сделав вид, что не упал".
Если тебе непонятно почему, то почитай этот самый issue, и представь себе, что программа написана на C++, что вылетает не паника, а исключение, но просто оно не обрабатывается в программе. И теперь твоя задача выбрать место, где воткнуть try {} catch (OutOfBoundException e) /*или как там это в C называется?*/. Попробуй выбрать какой-нибудь из стековых фреймов где это исключение должно быть обработано и аргументируй свой выбор.
Вот тебе код connect_gtk, на стековом фрейме которой случается попытка доступа за границы массива:
pub fn connect_gtk(&self) {
self.connect_headerbars();
self.connect_login_view();
self.connect_send();
self.connect_markdown();
self.connect_autocomplete();
self.connect_directory();
self.connect_leave_room_dialog();
self.connect_new_room_dialog();
self.connect_join_room_dialog();
self.connect_account_settings();
self.connect_invite_dialog();
self.connect_invite_user();
self.connect_direct_chat();
self.connect_roomlist_search();
}Допустим, я заверну всё это в try {} catch (...) {}, и теперь вопрос: будет ли допустимым продолжать выполнение программы, если мы получили здесь OutOfBoundsException? Или может надо сделать несоколько блоков try, и из некоторых падать, а из некоторых продолжать? Расскажи нам, как бы здесь C++ программист обрабатывал бы исключение, и как бы ему удалось решить проблему без падения.
А если тебе до сих пор ещё неясно, то я могу копнуть ещё глубже. connect_headerbars (который вероятно был заинлайнен, и поэтому не имеет самостоятельного стекового фрейма в release) содержит такие строчки:
if let Some(decor) = set.get_property_gtk_decoration_layout() {
let decor = decor.to_string();
let decor_split: Vec<String> =
decor.splitn(2, ':').map(|s| s.to_string()).collect();
if decor_split[1].contains("close") {
right_header.set_show_close_button(false);
left_header.set_show_close_button(true);
} else {
left_header.set_show_close_button(false);
right_header.set_show_close_button(true);
}
}
Тут есть индексация в decor_splitn, которая предполагает, что там будет хотя бы два элемента, то есть что set.get_property_gtk_decoration_layout() вернула строчку, в которой есть хотя бы один символ ':'. Я не знаю, насколько такое предположение допустимо, но предположим что нет. А автор кода, очевидно считает, что да. Это предполагаемое заблуждение автора ведь никак не связано с выбором языка программирования, так? И вероятно именно оно, приводит к вылету паники или в случае C++ исключения. Расскажи как в этой гипотетической ситуации исключения C++ вместо паники rust'а сделали бы поведение программы лучше.ps. Тут четыре выделения памяти: одно под Vec, и ещё три под String, и вся эта память освобождается обратно, после завершения внешнего if'а. И если let decor = decor.to_string(), я предполагаю, связан с тем, что gtk'шная функция возвращает что-нибудь типа CStr, и чтобы задействовать rust'овую библиотеку для работы со строками, нам необходимо сделать из него rust'овую строку (хотя всё равно я не понимаю зачем он нужен), то три оставшихся только ради того, чтобы выполнить один if с read-only доступом к decor_split[1]. И при этом, тут есть как раз потенциальная паника, если decor_split содержит меньше двух элементов.
Вместо этого ведь можно:
if decor.split(":").skip(1).map(|s| s.contains("close")).next() == Some(true) {
right_header.set_show_close_button(false);
left_header.set_show_close_button(true);
} else {
left_header.set_show_close_button(false);
right_header.set_show_close_button(true);
}Осталось только одна пара malloc/free, тоже по-моему ненужная, но это не очень важно поскольку в любом случае это O(1) добавленной сложности для программы, а что важно, так это то, что мы больше не полагаемся на то, что splitn вернёт нам хотя бы один элемент.
Я бы объяснил им, как надо, но не знаю, как на gitlab зарегаться или залогиниться. У меня не выходит, а разбираться в чём там дело я не буду.
Ну тебя и бомбит чувак. Если я в C++ конструирую окошечко и где-то внутрях вылетело std::out_of_range, мне не обязательно уничтожать всю программу, а достаточно лишь показать пользователю сообщение об ошибке в том месте, где пользователь попросил это окошечко открыть, и продолжить дальше. Впрочем, исключение при создании окошка на C++ тулкитах - это какая-то невероятная экзотика. Это только Rust может запаниковать на такой банальной фигне.
> Если я в C++ конструирую окошечко и
> где-то внутрях вылетело std::out_of_range, мне не обязательно уничтожать всю программу,
> а достаточно лишь показать пользователю сообщение об ошибке в том месте,
> где пользователь попросил это окошечко открыть, и продолжить дальше.Вся эта хрень, судя по всему, происходит при старте программы и инициализации собственно графики. В каком месте и как ты будешь показывать окошечко, если графика не сынициализировалась? И что ты будешь делать дальше?
Вот такие портянки растофанатиков почитаешь и понимаешь, что этот язык не для нормальных людей.
> Вот такие портянки растофанатиков почитаешь и понимаешь, что этот язык не для
> нормальных людей.Да. Нормальные нам не нужны. Нормальные пускай дальше на C пишут.
> Вот такие портянки растофанатиков почитаешь и понимаешь, что этот язык не для
> нормальных людей.А кстати, что по твоему "нормальный человек"? Это тот, кто не может прочитать более 1kb текста, разбирающего код? То есть не программист вообще?
1kb гнилых оправданий почему программы на Rust должны паниковать вместо того, чтобы работать.
> 1kb гнилых оправданий почему программы на Rust должны паниковать вместо того, чтобы
> работать.Заурядная техника. Не можешь оспорить, навесь ярлык. Скучно. Ты не пробовал хотя бы правила демагога на луркморе прочитать, что ли? Ну, чтоб хоть немного разнообразия в свой арсенал демагогических приёмов внести.
Демагогия - это рассказы про безопасность раста и отсутсвие UB. В реальности растопрограммы - это минное поле паник в рантайме, дедлоков и утечек ресурсов вместе с борьбой программистов против компилятора с помощью unwrap.
> Демагогия - это рассказы про безопасность раста и отсутсвие UB. В реальности
> растопрограммы - это минное поле паник в рантайме, дедлоков и утечек
> ресурсов вместе с борьбой программистов против компилятора с помощью unwrap.Молодец! Стоило только указать тебе на ошибки, и ты смог моментально переключиться на Bad Infinitum[1]. Такая гибкость заслуживает уважения.
[1] https://techiavellian.com/intellectual-denial-of-service-att...
Это тебе нечего мне возразить https://ru.wikipedia.org/wiki/%D0%9F%D1%...)
> Это тебе нечего мне возразить https://ru.wikipedia.org/wiki/%D0%9F%D1%...)Я выше всё написал. В качестве возражений я слышал лишь демагогию. Не, если хочешь, я могу скопировать ту простынку и ещё раз её запостить.
В твоей простынке написано, что программа на расте, создающая графическое окно, обязательно должна паниковать. Я с этим и не спорю, если ты ещё не понял.
> В твоей простынке написано, что программа на расте, создающая графическое окно, обязательно
> должна паниковать. Я с этим и не спорю, если ты ещё
> не понял.Ты читать умеешь? Там написано, что тот кто писал код не может распарсить строку вида "ключ:значение".
Отличный повод для паники 👍
> Отличный повод для паники 👍Слушай, может ты всё же почитаешь, что я там написал, и подумаешь головой о том, как C++ позволил бы избежать этой проблемы? Позволил бы он? Если бы автор написал бы этот свой код на всяких разных языках программирования, то в C он бы получил чтение за пределами массива, в C++/rust'е он бы получил исключение выхода за границы массива, в js и прочей нечисти такого рода, он бы прочитал несуществующее значение из массива, получил бы null или типа того, он бы получил false в результате сравнения и его код сработал бы. Правильно или не правильно -- я не знаю, всё зависит от того, должна ли быть else ветка if'а дефолтной или нет.
В C++/rust'е он бы получил исключительную ситуацию, в C++ размотку стека исключением, в rust'е паникой. Обработать эту ошибку осмысленно невозможно. Такого рода ошибки исправляются единственным способом: проверкой индекса до того, как этот индекс был использован по назначению.
Ты, я вижу, никак не можешь впитать эту идею. Я могу тебе помочь. Расскажи как бы ты, имея на руках аналогичную C++ программу, обезопасил функцию connect_gtk от подобных вылетающих исключений, вызванных тем, что тот кто писал всю эту пачку connect_* функций, позволял себе эпизодически выходить за границы массивов. Как бы ты обрабатывал такие исключения? Вот возьми и расскажи. Пока ты будешь рассказывать ты поймёшь о чём я, и тебе надоест рассказывать, ты удалишь всё написанное и опять включишь свою демагогию.
> как C++ позволил бы избежать этой проблемы? Позволил бы он?Разумеется! Во-первых, в C++ никому в голову не пришло бы писать подобный бред с разбором строк ad-hoc:
if let Some(decor) = set.get_property_gtk_decoration_layout() {
let decor = decor.to_string();
let decor_split: Vec<String> =
decor.splitn(2, ':').map(|s| s.to_string()).collect();
if decor_split[1].contains("close") {
right_header.set_show_close_button(false);
left_header.set_show_close_button(true);
} else {
left_header.set_show_close_button(false);
right_header.set_show_close_button(true);
}
}это для скриптов такое поделие сойдёт, но не для кода, который должен выполняться быстро (иначе зачем мы языком для системного программирования занялись?). Во-вторых, даже если бы и пришло, в C++ подобную конструкцию всегда можно окружить try/catch блоком и выполнить сценарий по умолчанию, например:
} else {
left_header.set_show_close_button(false);
right_header.set_show_close_button(true);
}
И не надо мне писать, что панику в расте можно отловить так же, как исключение в C++. Нельзя, паники в придумали расте не для этого. Но главная проблема раста даже не в этом. Проблема раста в том, что из этого кода просто не видно, что там зарыта паника.
>> как C++ позволил бы избежать этой проблемы? Позволил бы он?
> Во-первых, в C++ никому в голову не пришло бы писать подобный
> бред с разбором строк ad-hoc:О, да. Я всё ждал, когда ты скажешь, что C++ программисты особенные, и они не делают таких ошибок.
> это для скриптов такое поделие сойдёт, но не для кода, который должен
> выполняться быстро (иначе зачем мы языком для системного программирования занялись?).Речь идёт о стартапе программы, который выполнится один раз. Какая разница четыре там выделения памяти или ноль? Никто никогда не заметит этой разницы глазом.
> connect_headerbars (который вероятно был заинлайнен
> и поэтомуНе является причиной.
> не имеет самостоятельного стекового фрейма в release)
_Даже_если_ так, не играет роли (и стандарт не оперирует абстракциями "регистр rbp"). Изучай существующие имплементации обработчиков, если интересны детали.
Не понял. Не является причиной чему? Не играет роли какой? При чём тут имплементации обработчиков?Ты хочешь этим намекнуть, что ты знаешь каким образом строится бектрейс, который выводится при RUST_BACKTRACE=1, и полагаешь, что если этот бектрейс не содержит в себе каких-то функций, которые по логике вещей должны были бы там быть, то это вовсе не потому, что эти функции были заинлайнены? Если ты так думаешь, то ты глубоко и печально ошибаешься. Сделай по сорцам раста find . -name libunwind, и загляни туда. Ты увидишь, что размотка стека на линуксе идёт посредством libgcc_s.so. Который -- сюрприз-сюрприз -- тоже входит в список абстракций, которым не оперирует стандарт. Подстава, да?
> Не понял. Не является причиной чему?Упомянутым якобы ограничениям. По стековым фреймам в *nix см. red zone, кадры не всегда организуются даже когда нужны.
> Не играет роли какой?
Предписываемой в гипотетических исключениях. Будет использовать кадр вызывающей функции (если имплементация вообще требует стэк, как в Win32).
> При чём
> тут имплементации обработчиков?Стандарт С++ определяет семантику исключений и приходится соответствовать. То есть перевод разговора на уровень имплементации рантайма трактуются лишь в ключе "я (не) знаю как".
> Ты хочешь этим намекнуть, что ты знаешь каким образом строится бектрейс, который
> выводится при RUST_BACKTRACE=1Скажу прямо: это не моя забота знать, как там в Rust и почему inline стало проблемой, когда в С++ таковой не является.
> По стековым фреймам в *nix см. red zone, кадры не всегда организуются даже когда нужны.И что? Стековый фрейм начинается адресом возврата, и продолжается до следующего адреса возврата. То что ты называешь "организацией кадра" -- это лишь специальные телодвижения сводящиеся к тому, чтобы положить в известное и доступное место адрес этого самого стекового фрейма.
> Стандарт С++ определяет семантику исключений и приходится соответствовать. То есть перевод разговора на уровень имплементации рантайма трактуются лишь в ключе "я (не) знаю как".
Ах, так ты о C++ говоришь? И чё, бектрейсы в C++ пишут и про заинлайненные функции? Вот если я напишу C++ программу, скомпилирую её с -O2, стрипну всю дебаг-инфу из файла, то я смогу получить полный список вложенных вызовов в бектрейсе?
> Скажу прямо: это не моя забота знать, как там в Rust и почему inline стало проблемой, когда в С++ таковой не является.
Ты сам с собой разговариваешь? Где тут ты видишь проблему? Что бектрейс неполный? Дык это преимущество, это значит что бинарь не содержит всяких ненужностей, что inline-функция именно что inline функция, она встроена в вызывающую её функцию, будто она там была написана, она, в некоторых случаях, может быть оптимизирована так, что в коде не останется ни одной инструкции машинного кода от неё. Это преимущество, это хорошо и прельстиво. Если же тебе это не нравится, собирай debug-билд.
>> По стековым фреймам в *nix см. red zone, кадры не всегда организуются даже когда нужны.
> И что? Стековый фрейм начинается адресом возврата, и продолжается до следующего адреса
> возврата.Обычно под кадром понимают аргументы (если они сохранены на стэке) и локальные переменные функции. Адрес возврата это адрес возврата - его рисуют на картинках в книжках для пущего понимания и целостности картины. Эти данные не относятся к исключениям.
> То что ты называешь "организацией кадра" -- это лишь специальные
> телодвижения сводящиеся к тому, чтобы положить в известное и доступное место
> адрес этого самого стекового фрейма.Организация кадра выполняется модификацией регистра процессора "указатель стека" (иногда используется регистр "базы стека"). Действительно, упомянутый регистр - известное место.
>> Стандарт С++ определяет семантику исключений и приходится соответствовать. То есть перевод разговора на уровень имплементации рантайма трактуются лишь в ключе "я (не) знаю как".
> Ах, так ты о C++ говоришь?Ну да. Выше кто-то заявил, что в С++ с этим нет проблем.
> И чё, бектрейсы в C++ пишут
> и про заинлайненные функции? Вот если я напишу C++ программу, скомпилирую
> её с -O2, стрипну всю дебаг-инфу из файла, то я смогу
> получить полный список вложенных вызовов в бектрейсе?Уверен, сможешь. Возможно, не с первой попытки, но сможешь. Ты специалист весьма грамотный и упорный, другое дело, что больше интересуешься высоким уровнем, а не всякими rop-гаджетами.
Тут надо понимать, что дебажная инфа не относится к исключениям. Для них генерируются отдельные таблицы адресов try-блоков. То есть эти вещи ортогональны. Дебажная инфа по большому счёту нужна для сопоставления адресов машинных команд строчкам с исходниках. Ну и при построении графа вызовов не всегда получается гарантировано однозначно раскрутить стек, если не используется регистр базы стека.
>> Скажу прямо: это не моя забота знать, как там в Rust и почему inline стало проблемой, когда в С++ таковой не является.
> Ты сам с собой разговариваешь? Где тут ты видишь проблему?Я просто поверил тебе, как специалисту по Rust. Ты же сам сообщил, что из-за инлайна не будет стекового фрейма и потому в итоге вываливается паника, а иначе сделать нельзя.
> Адрес возврата это адрес возврата - его рисуют на картинках в книжках для пущего понимания и целостности картины. Эти данные не относятся к исключениям.Что значит не относятся, если адреса возврата используются при размотке стека? То есть, возможны варианты организации размотки стека, когда ради неё создаётся отдельный стек, но... Не знаю как там в C++, думаю нет, и совершенно определённо этого не делается в rust'е. В стековом фрейме всё фигня, а адресами возврата устанавливается связь между вложенными контекстами выполнения. Ради этих адресов возврата стек и существует, всё остальное в стеке оказывается там по принципу: если уж у нас есть стек, то почему бы не использовать его под локальные переменные и под передачу аргументов в функции.
Весь мой опыт отладки говорит, что адрес возврата -- это самая удобная точка отсчёта границ между стековыми фреймами. Даже если под адресом возврата лежат аргументы функции, всё равно удобнее ориентироваться на адрес возврата, потому что он будет даже тогда, когда аргументы передаются в регистрах, или когда их переменное число. Более того, если ты хочешь сделать что-нибудь типа tail-call'а, или вернуться из функции при помощи iret, хотя вызывали твою функцию командой call, или ещё какой-нибудь такой трюк провернуть, то тебе будет глубоко наплевать где там на стеке лежит значение bp/ebp/rbp, тебя будет в первую очередь интересовать, где лежит адрес возврата.
> Организация кадра выполняется модификацией регистра процессора "указатель стека" (иногда используется регистр "базы стека"). Действительно, упомянутый регистр - известное место.
Спасибо за справку.
> Тут надо понимать, что дебажная инфа не относится к исключениям.
Относится... Не относится... Какая разница мне, если при отсутствии отладочной информации я не могу увидеть осмысленного бектрейса от вылетевшего исключения? А речь идёт ведь именно о бектрейсе вполне конкретного исключения (то есть паники) на вполне конкретном коде.
Из наблюдений за тобой, я сформировал полезный совет тебе. Ну, познание -- моя больная тема: то как человеческие мозги упорядочивают входящий поток информации, которую они получают от рецепторов -- это очень интересный вопрос. И глядя на тебя, я вижу что ты немного не так расставляешь акценты, занимаясь познанием реальности. Собственно следующая портянка как раз об этом. Если тебе это tl;dr, ты можешь скипнуть к следующей цитате себя и читать оттуда.
Не надо так упорно пытаться делить вещи на те, которые относятся к X и те которые не относятся к X, для любого X. Вселенная не работает так. То что ты пытаешься делать -- это очень удобный способ упорядочивать информацию о Вселенной в голове, но надо быть готовым к тому, что отношение между вещами и X окажется субъективным. То есть с одной стороны его нет, с другой стороны оно есть -- как посмотреть. Граница между X и не-X -- это всегда размытая граница, там всегда есть серая область, которая иногда относится к X, а иногда нет.
Скажем, все твои рассуждения о стековых фреймах, построены на каком-то определении стекового фрейма, в котором очевидно упоминался rbp. Из чего по логике вытекает, что если не используется rbp или его аналог, то стекового фрейма нет. Чёткая граница между X и не-X, где X -- множество стековых фреймов. Но если ты попытаешься, например, отревёрсить программу, которая не использует rbp, ты будешь ковырять эту программу в дизассемблере и отладчике, и ты всё равно будешь думать о стековых фреймах, даже несмотря на то, что доступ к переменным на стеке программа выполняет посредством адресации относительно rsp. И тебе будет совершенно не важно, что там вумные люди пишут во всяких вумных учебниках о том, что они считают стековым фреймом. Даже более того, в качестве исторической справки, я скажу тебе, что использование bp, ebp и rbp для организации стека, возникло исходно лишь потому, что в 16-битном режиме интеловские процессоры не умеют в косвенную адресацию через sp, там все эти SIB да MOD/rm байты в системе команд кодируются так, что через sp никак. В 32-битном коде SIB и modrm декодируются несколько иначе, и они позволяют использовать esp, но... но люди продолжали использовать bp по двум причинам: во-первых, привычка, во-вторых, без фиксированной ссылки на стековый фрейм в ebp было невозможно пользоваться дебуггером высокоуровневого языка. Надо либо кодировать на каждую строчку кода смещение esp от адреса возврата на момент выполнения этой строчки кода (компилятор так или иначе отслеживает эту инфу, он её использует, но не сохраняет в бинаре), либо учить дебуггер всяким хитрым трюкам, чтобы тот анализируя выполняемые команды сам бы высчитывал все эти смещения. То есть, когда код стал 32-битным (и тем более 64-битным), использование ebp/rbp для организации стекового фрейма стало лишь данью тупости отладчиков, такой же данью тупости отладчиков, как и отладочная инфа. Ещё его можно использовать для размотки стека в случае исключений, но можно и не использовать, придумав какой-нибудь иной способ. А, если мы, разматывая стек, хотим ещё и ресурсы подбирать и освобождать, то что-то иное всё равно приходится придумывать, и это что-то иное может не включать в себя использование rbp для организации стекового фрейма. Но так или иначе, ты видишь, да? Граница между X и не-X размазалась, и уже неясно, нужен ли rbp для организации стекового фрейма, или это просто дань традиции, возникшей из-за убогости первых x86.
То же самое происходит и с отладочной информацией. Она нужна для отладки. Точка. Чёткая граница между X и не-X, где X -- это инфа для отладки. Но... эмм... если мы всунем обрезанный вариант этой отладочной инфы в релиз, то мы сможем получать осмысленные бектрейсы, которые могут помочь нам общаться с пользователями о багах. Обрезанный вариант -- это без номеров строк, без информации о размещении переменных на стеке, без всего, лишь информацию о границах функций в секции кода, и каноничные имена этих функций, со ссылками на файлы где они объявлены. То есть, это тоже, как бы, "для отладки", но в то же время, как бы, и не совсем для отладки.
Отладочная информация может использоваться и для того, чтобы определить факт того, что исключение возникло не в функции foo, а в функции bar, которая была заинлайнена в foo. Я не знаю, используется ли она в действительности всякими разными библиотеками, которые позволяют программе построить свой бектрейс. То есть, де факто, отладочная информация используется ими -- иначе бы бектрейсы программы с отладочной инфой не отличались бы от бектрейсов программ без неё. Но тут вопрос в том, может ли построитель бектрейса в C++ использовать эту информацию для определения того, что на стековом фрейме foo сверху есть ещё стековый фрейм функции bar, несмотря на то, что bar не вызывался через call, и адрес возврата не клался на стек, и вообще после того как bar был заинлайнен, при взгляде на дизассемблерный дамп даже возникает сомнение в осмысленности разговора о том, что какой-то кусок foo -- это на самом деле самостоятельная функция bar.
Более того, имея опыт создания странных вещей странными способами, я допускаю, что отладочную инфу можно использовать для организации размотки стека по исключению и для организации RAII. Не думаю, что кто-нибудь так поступает -- во всяком случае не в C++, где исключения -- это заурядный механизм, тормознутость которого и без того причиняет анальные боли, и вот только ещё не хватало парсить текстовую дебаг-инфу, и извлекать из неё информацию о переменных, чьи деструкторы надо вызвать.
Отладочная инфа или не *отладочная* инфа -- вот в чём вопрос, границы опять расплываются. Относится "отладочная" инфа к размотке стека или не относится? Не надо излишне парится о чёткости этих границ, чёткость должна быть на экзамене, потому что экзамены часто принимаются тупыми педантами. Чёткость может оказаться полезной при общении с другим человеком, но тут палка о двух концах: если твои чёткие границы между понятиями будут пролегать немного не там, где его чёткие границы между понятиями, то вам будет очень сложно понять друг-друга, более того вы будете рисковать не понять того, что вы не понимаете друг-друга, а это худшее, что может случиться в коммуникации. Даже мордобой, как способ вести коммуникацию, не столь плох, потому что он по-крайней мере несёт в себе чёткое взаимопонимание хотя бы по одному вопросу.
> Уверен, сможешь. Возможно, не с первой попытки, но сможешь. Ты специалист весьма грамотный и упорный, другое дело, что больше интересуешься высоким уровнем, а не всякими rop-гаджетами.
Это "да" или "нет"? Я знаю, что я смогу, мне в жизни удавалось заставлять работать очень странные вещи и очень странными способами. Но это не ответ на поставленный вопрос.
Впрочем, я уже догадался, что ответ -- нет. Если бы ответ был "да", ты бы не извивался тут ужом на сковородке, пытаясь изобразить что-то похожее на ответ так, чтобы оно не содержало бы в себе актуального ответа.
> Ты же сам сообщил, что из-за инлайна не будет стекового фрейма и потому в итоге вываливается паника, а иначе сделать нельзя.
Я такого не сообщал, ты не тем местом читал. У меня там выше целый пост, который приводит возможную причину паники, и не слова не сказано о том, что паника вылетела из-за отсутствия стекового фрейма. Слова о стековых фреймах были для того, чтобы обосновать поиск причины паники не только в той функции, из которой эта паника вылетела, согласно бектрейсу, но и в функциях, которые вызываются из неё, несмотря на то, что эти функции не упоминаются в бектрейсе, из чего, *как бы*, следует, что исключение возникло не в них.
>В репозитории Crates.io для публикации новых пакетов теперь обязательно требуется подтверждение своего email;Давайте ещё тогда сразу фингерпринт браузера, привязку мобильного, скан паспорта факсом, видео на фоне паспорта с приседаниями и "Ку!", снятое через приложение, крутящееся в TEE и образец ДНК требовать сразу, что уж мелочиться?
Для адекватных же разработчиков просто оставлю ссылку: https://github.com/whyrusleeping/gx . Написан на goвне, из коробки идёт только для goвна и нодика, но можно приделать плагин для любого языка или даже дисприбутива.
>>для публикации новых пакетов … подтверждение своего email;
> Давайте ещё тогда сразу фингерпринт браузера, привязку мобильного, скан паспорта факсом,Вот уж действительно, эталонное сравнение попы и пальца.
Ну да, правильно, пускай любой Васян сможет вообще без усилий заспамить репу, зато аноним сохранит свое (гипотетическое, ведь пользоваться им он на самом деле не будет) право закоммитить что-то полностью от анонима и без возможности обратной связи …Кстати, если вместо гадания и праведного негодования взять и пройти по ссылке и глянуть в оригинал, то там вполне простое объяснение:
https://users.rust-lang.org/t/a-verified-email-address-will-...
> To comply with DMCA, we need a guaranteed way to contact publishers of content on crates.io.Ни слова о том, что адрес должен быть привязан к реальному имени.
>To comply with DMCAЧто не является легитимной причиной, как и любой другой to comply with <law of a totalitarian state> (напр. to comply to Yarovaya law) повод.
>Ни слова о том, что адрес должен быть привязан к реальному имени.
Фактически должен. Почтовые сервисы собирают либо телефоны пользователей, либо платёжные реквизиты. Либо им такие несговорчивые пользователи не нужны, их посылают вообще в баню. Есть временные почты, надо понимать, что они небесплатно работают: абузоустойчивый хостинг стоит денег, а абузы и маски-шоу силовиков будут, так как существование подобных сервисов многим невыгодно, а значит для владельца нужна юридическая и персональная защита, что тоже стоит недешево и поэтому результат будет таков:
1 пакет, к аккаунту которого привязана временная почта, будет заменён на вредоносный
2 "чтобы защитить пользователей" вообще ведут черные или даже белые списки почтовых сервисов, а внезапно ВСЕ крупные сервисы либо требуют привязку мобильного ИЛИ (в смысле F7) делают browser fingerprinting ИЛИ требуют оплату
>>To comply with DMCA
> Что не является легитимной причиной, как и любой другой to comply with <law of a totalitarian state> (напр. to comply to Yarovaya law) повод.Угу, нужно уйти в онион-подполье и питаться биткоинами -- зато не нужно будет соответствовать законам страны базирования.
>> Ни слова о том, что адрес должен быть привязан к реальному имени.
> Фактически должен. Почтовые сервисы собирают либо телефоны пользователей, либо платёжные
> реквизиты. Либо им такие несговорчивые пользователи не нужны, их посылают вообще в баню.Такое ощущение, что мы обитаем в разных мирах.
Почему-то у меня есть почтовые адреса, которым уже 20 лет и ни один не привязан через телефон, реальный адрес или оплату и не фигурирует в черных списках.
Единственная проблема с такими адресами -- обычно ограниченное количество свободного места для котиков и регулярная реклама самого сервиса "закажи Про-версию", которая отлично фильтруется автоматически или расчитана на вебморду и вообще не отображается в почтовом клиенте.Это помимо того, что большинство разработчиков и так предпочитают оставлять в шапке кода или "credits" свои реальные имя-фамилию + почту …
> а внезапно ВСЕ крупные сервисы либо требуют привязку мобильного
Тайные знания:
https://web.de/ -- сервису уже 20 лет, мелким не назовешь, ни адрес, ни телефон не нужен, доступ через imap тоже сложновато зафингерпринтить.> ИЛИ (в смысле F7) делают browser fingerprinting
Это делают вообще все, кому не лень. Тем более, могут "тайком" и на крейтс.ио делать, поэтому туда все равно будет лучше не ходить, даже если отменят регистрацию мыла :rolleyes:
>Угу, нужно уйти в онион-подполье и питаться биткоинами -- зато не нужно будет соответствовать законам страны базирования.Достаточно передать управление репозиторием иностранной организации, расположенной в юрисдикции, кде DMCA не действует. Но лучше всё же хостить всё в IPFS, а сайт упразднить.
> Достаточно передать управление репозиторием иностранной организации, расположенной
> в юрисдикции, кде DMCA не действует. Но лучше всё же хостить всё в IPFS, а сайт упразднить.Если я правильно понимаю ваши претензии -- все это нужно во имя сохранения анонимности автора?
Но скольким авторам _на самом деле_ это нужно?
Вы можете привести пару примеров более-менее полезного софта "от анонимного анонима" (тем более остается вопрос, захотят ли они сами публиковаться на таком ресурсе)?
Стоит ли "городить огород" для (почти буквально) 3½ человек, попутно создавая "все условия" для скрипткиддизов и прочих персонажей сомнительной нужности?
При условии анонимности хотиться проще, не от кого бы не убыло, а проектов может и прибыло.
>Если я правильно понимаю ваши претензии -- все это нужно во имя сохранения анонимности автора?Это нужно, чтобы автор не потерял доступ к аккаунту. Если почта, на которой я зареган, потребует по закону о мессенджерах привязку мобильного, то я останусь без всех своих аккаунтов. Поэтому привязка аккаунтов к почте вместо привязки к информации для входа - это постановка меня в зависимость от этого сервиса и его хозяев. По сути это сродни установки рекапчи (оч. частое явление, не пользуюсь такими сайтами, только для некоторых вебсайтов сделано исключение, потому что капча у них только на регистрации, а я уже давно зарегистрирован, ещё при рекапче v1, и потому что они всё-таки работают над уходом от рекапчи) или требованием входа через фейсбук/госуслуги/AADHAAR (сразу в игнор - у меня нет этих аккаунтов).
Уважаемый, вы чем-то похожи на Ruptor-а. Но тот при всём при этом автор purenoise и enrupt, а вы?
Гугл говорит, что ruptor - это программа, а не ник. purenoise вообще какой-то вебсайт. Требую пояснения, кто такой этот Sean O'Neil, чем он знаменит (в википедии нет), чем его вклад значим и куда и по какой причине он пропал (за последние годы статей нет, институтская страничка тоже не гуглится).>Но тот при всём при этом автор purenoise и enrupt, а вы?
Какое это отношение имеет к данному обсуждению? Чтобы иметь легитимное желание не быть лишённым всех аккаунтов по желанию левой пятки владельца сервиса электронной почты, нужно быть какой-то особо выдающейся личностью?
> Гугл говорит, что ruptor - это программа, а не ник.Ну, видать что-то не то с вопросами.
https://wasm.in/threads/uvazhaemye-guru-pomogite-najti-reali...
> purenoise вообще
> какой-то вебсайт.Да. Был. https://web.archive.org/web/20090406230617/http://www.pureno.../
> Требую пояснения, кто такой этот Sean O'Neil, чем он
> знаменит (в википедии нет)Правда? Помнится, он числился в её авторах.
> чем его вклад значим и куда и
> по какой причине он пропал (за последние годы статей нет, институтская
> страничка тоже не гуглится).
>>Но тот при всём при этом автор purenoise и enrupt, а вы?
> Какое это отношение имеет к данному обсуждению? Чтобы иметь легитимное желание не
> быть лишённым всех аккаунтов по желанию левой пятки владельца сервиса электронной
> почты, нужно быть какой-то особо выдающейся личностью?Почитайте выше свой вопрос, который остался без ответа.
> Это нужно, чтобы автор не потерял доступ к аккаунту. Если почта, на
> которой я зареган, потребует по закону о мессенджерах привязку мобильного, то
> я останусь без всех своих аккаунтов. Поэтому привязка аккаунтов к почте
> вместо привязки к информации для входа - это постановка меня в
> зависимость от этого сервиса и его хозяев.Это натягивание совы на глобус/притягивание за уши.
Аккаунты, можно сказать традиционно и "издавна", привязывают к почте.
Потерей аккаунта это грозит только в том случае, если прое^W потерять и пароль аккаунта и почтовый адрес одномоментно. В ином случае почтовый адрес вполне меняется, а пароль обычно восстанавливается как раз через ящик.
Самое смешное -- за все это время я лишился только 1 почтового ящика по причине прекращения предоставления услуги, а вот аккаунты для давно не существующих ресурсов даже считать не хочу.
поскольку аккаунты привязываются к почте, то любое действие по смене пароля или почты требует подтверждения через почту. то есть если потеряете доступ к почте - аккаунт навечно останется к ней поривязан. при любом взломе сервиса, компромитирующего базу паролей/хешей, вам принудительно сбросят пароль и вы потряете дос туп к аккаунту.
> 2 "чтобы защитить пользователей" вообще ведут черные или даже белые списки почтовых
> сервисов, а внезапно ВСЕ крупные сервисы либо требуют привязку мобильного ИЛИ
> (в смысле F7) делают browser fingerprinting ИЛИ требуют оплатуПрошляпил добавить:
сейчас там для логина нужен аккаунт на смузха^W гитхабе. А тот точно так же требует мыло, так что -- "что совой о пень, что пнем о сову ..." (с)
Ещё один довод не пользоваться их поделием.
Зарегайте себе отдельный мэйл для этого дела и не морочте голову.
"Отдельный мейл" тоже хостится на законопослушном сервисе, который выполнит закон о мессенджерах путём обязательной привязки мобильного.
Чет я не особо могу вакансию на раст найти
Это да. И на ЛОРе главные растофанатики пишут на ненавистных крестах. Такие дела...
http://itmozg.ru/vacancy/show/247722
https://t.me/rustlang_jobs
В этом telegram канале, часто объявления публикуются.
Часто вижу вакансии на Rust в сфере торговли, криптовалюты и т.д.