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

"Выпуск языка программирования Rust 1.33"	+/–
Сообщение от opennews (ok), 02-Мрт-19, 13:17
Состоялся (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.dev/opennews/art.shtml?num=50235
Ответить | Правка | Cообщить модератору

Сообщения по теме

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

1. "Выпуск языка программирования Rust 1.33"	–5 +/–
Сообщение от Xasd (ok), 02-Мрт-19, 13:17
> Для распространения библиотек, обеспечения сборки и управления зависимостями проектом развивается пакетный менеджер Cargo, позволяющий получить нужные для программы библиотеки в один клик. Для размещения библиотек поддерживается репозиторий crates.io. а можно попросить cargo собрать проект (с учётом всех зависимостей) -- но сказать ему чтобы он НЕ скачивал бы ни чего из сети (ни в коем случае!)? сказать чтобы вообще не пытался бы лесть в интернет (своими замечательными руками)? то есть чтобы попробовал бы собрать из того что есть уже скаченного (очевидно нужно как-то указать на каталог где оно должно лежать скаченным) -- либо упасть с сообщением "ни чего не выйдет, запчастей не хватает! требуемые запчасти это РУЛЬ и КОЛЁСА, остальное всё пока-что кажется будто бы хватает" # P.S.: сорян, не пишу на Rast поэтому такие примитивные вопросы # P.P.S.: то есть речь идёт о ситуации когда нужно организовать на 100% ПОВТОРЯЕМЫЙ результат сборки, в независимости от того на каких компьютерах есть или нет интернета или какие-там-ip-адреса доступны/недоступны на каком-из-компьютеров (или автор пакета решил что-то удалить своего из сети, обидившись на свою жену). > позволяющий получить нужные для программы библиотеки в один клик подразумевается что просьба "не лезь в интернет" тоже хотелось бы в один клик :-)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Выпуск языка программирования Rust 1.33"	+6 +/–
	Сообщение от Инна Друзь (?), 02-Мрт-19, 13:26
	cargo build --frozen
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	5. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Xasd (ok), 02-Мрт-19, 13:36
	> cargo build --frozen судя по описанию похоже на то что надо :-) .. а путь к РУЛЮ и КОЛЁСАМ указывать-то можно?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	4. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Ordu (ok), 02-Мрт-19, 13:33
	Да, можно. В депендансах надо прописать что-то типа: [dependencies] my-crate = { path="../my-crate" } Или можно попробовать через git: [dependencies] my-crate = { git="бла-бла-бла/", tag="v1.0" } Я сам не пробовал так, в примерах везде вместо "бла-бла-бла" ссылки, но подозреваю, что туда подставить путь к директории где git-реп лежит, то оно сработает: cargo склонирует оттуда нужную ревизию, и соберёт её.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	6. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Xasd (ok), 02-Мрт-19, 13:40
	> Да, можно. В депендансах надо прописать что-то типа: > [dependencies] > my-crate = { path="../my-crate" } > Или можно попробовать через git: > [dependencies] > my-crate = { git="бла-бла-бла/", tag="v1.0" } менять исходный код нельзя (в том числе нельзя менять исходный код зависимостей, которые имеют другие зависимости, которые имеют другие зависимости -- вся эта глубокая-цепочка-зависмостей должна оставаться в оринигальном виде -- без наложения патчей). можно только лишь командовать СНАРУЖИ всем этим :-) то есть предполагаем что проект уже есть (изготовленный традиционным способом) а не с расчётом на offline-сборку, а теперь мы хотим его собрать, но при этои не давая cargo шанса залесть в сеть. > Я сам не пробовал так, в примерах везде вместо "бла-бла-бла" ссылки, но подозреваю, что туда подставить путь к директории где git-реп лежит, то оно сработает: cargo склонирует оттуда нужную ревизию, и соберёт её. так ли я понял что вобщем судя по всему -- нужно создать локальный репозиторий и всё накопировать туда? а при сборке cargo -- сказать ему что-то типа "используй вот этот конфигурационный файл (вместо обычного конфигурационного файла)! а в конфигурационном файле лежат уже ссылки на локальный репозиторий" -- так? или может не репозиторий а какой-то индивидуальный каталог кэша можно сделать? чтобы возиться поменьше, но получить сходный результат
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	9. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Ordu (ok), 02-Мрт-19, 13:52
	> так ли я понял что вобщем судя по всему -- нужно создать локальный репозиторий и всё накопировать туда? Не. Это если я сделал git clone https://github.com/.../my-crate, а потом cargo берёт этот my-crate не с github'а, а из этого локального клона репа. > или может не репозиторий а какой-то индивидуальный каталог кэша можно сделать? чтобы возиться поменьше, но получить сходный результат У cargo при этом есть какая-то переменная окружения, которая рулит тем, куда он скачивает пакеты. Он по умолчанию складывает их в ~/.cargo, но можно складывать их куда угодно. А если потом использовать --frozen, то он больше не будет скачивать.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	12. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Xasd (ok), 02-Мрт-19, 14:10
	> Он по умолчанию складывает их в ~/.cargo, но можно складывать их куда угодно. ну эт переменная по сути CARGO_HOME , тут понятно.. > А если потом использовать --frozen, то он больше не будет скачивать. следовательно для того чтобы весь пазл сошёлся -- нужна ещё какая-то (какая?) инсталляционная cargo-команда которая бы взала бы исходный код пакета-зависимости (пакет-зависимость -- уже заведомо скаченный своим путём в ОБХОД cargo.. то есть это НЕ cargo fetch) и положила бы <что-то> в этот кэш ($CARGO_HOME/.cargo).
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	14. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Ordu (ok), 02-Мрт-19, 14:33
	> нужна ещё cargo-команда которая бы собрала бы исходный код пакета-зависимости (пакет-зависимость -- уже заведомо скаченный МИМО cargo.. то есть это НЕ cargo fetch) и положила бы <что-то> в этот кэш ($CARGO_HOME/.cargo) Эмм... То есть, ситуация примерно такая. Вчера, перед тем как лечь спать, ты скачал тарболл с офигенно нужным тебе пакетом. Когда же ты встал с утра, то прочитал в новостях, что CIA передралось с ФБР, а ФБР с китайцами, и кто-то из них, решил что crates.io -- это самое удачное место, через которое можно напихать бекдоров потенциальному противнику. В результате теперь все пакеты в интернете теперь содержат бекдоров больше, чем в них строк кода есть. Тебе тем не менее хочется собрать вчера скачанный тарболл (он был скачан до начала конфликта и поэтому без бекдоров), но скачивать ничего ты не намерен. И вопрос собственно: возможно ли это. При этом, есть ещё два условия: 1) в CARGO_HOME уже лежит куча пакетов, которые были выкачаны раньше, и возможно их достаточно; 2) модифицировать сорцы из тарболла или из CARGO_HOME нельзя. Так? У меня нет ответа на такой вопрос. Я не знаю. Мне кажется, что это нельзя сделать, не ковыряя вручную того, что лежит в ~/.cargo. А может даже ковыряя не удастся.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	17. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Xasd (ok), 02-Мрт-19, 14:59
	>[оверквотинг удален] > ФБР, а ФБР с китайцами, и кто-то из них, решил что > crates.io -- это самое удачное место, через которое можно напихать бекдоров > потенциальному противнику. В результате теперь все пакеты в интернете теперь содержат > бекдоров больше, чем в них строк кода есть. Тебе тем не > менее хочется собрать вчера скачанный тарболл (он был скачан до начала > конфликта и поэтому без бекдоров), но скачивать ничего ты не намерен. не совсем -- подразумевается что сборка проектов происходит на разных компьютерах, в том числе на сборочных серверах без доступа к интернету (без доступа к сети). а не на одном и том же (одном) компьютере. но кроме того то что на сборочных серверах нет доступа к интернету (а на некоторых сборочных-серверах он есть) -- есть ещё и ВТОРОЕ требование -- нужна ещё и гарантия того что у мы ТОЧНО знаем все источники из которых компилировались зависимости к проектам (в том числе источники с модифицированным (нашими руками) исходным кодом зависимостей). если мы модицифируем исходный-код какой-то-там-зависимости -- то следущий раз сборочный сервер во чтобы то ни стало -- должен собрать уже СООТВЕТСТВУЮЩУЮ версию проекта (проекта который использует эту зависимость). то есть независимо там от номеров версий или ещё каких-там-сраных кэшэй -- проект всегда должен (на сборочном сервере) собираться ВСЕГДА ровно из того что указано в его сборочных скриптах. (НАПРИМЕР: исходный код какой-то зависимости поменялся, а номер версии остался тем же самым? не важно -- это не должно ничего портить!) на сборочных серверах -- всегда кэши очищаются (и доступа в интернет нет, который бы доставил им свежий кэш откуда-то из глубины "облака"). исходных код зависимостей доставлется до сборочных серверов -- через свои собственные каналы. причём именно исходный код, а не уже-какая-то-предкомпилированная хеератень. и вот и требуется чтобы сборка происходила РОВНО из тех исходных кодов которые бы доставлялись бы до сборочных серверов. и не из какого другого места. и как и раньше говорил: собираем не свою программу а обычную какую-то программу написанную в обычном стиле (НЕ расчитанную на offline-компиляцию). > И вопрос собственно: возможно ли это. При этом, есть ещё два > условия: 1) в CARGO_HOME уже лежит куча пакетов, которые были выкачаны > раньше, и возможно их достаточно; 2) модифицировать сорцы из тарболла или > из CARGO_HOME нельзя. Так? ну тоесть на момент сборки (каждый раз перед сборкой) -- ни чего внутри $CARGO_HOME нет. для сборочного сервера -- каждая компиляция это как новая свежая система :-). > модифицировать сорцы из тарболла или из CARGO_HOME нельзя. Так? можно, но не желательно. судя из ответа я так понял -- это делать всё-таки придётся. а хотелось бы узнать можно ли это не делать. > У меня нет ответа на такой вопрос. Я не знаю. Мне кажется, > что это нельзя сделать, не ковыряя вручную того, что лежит в > ~/.cargo. А может даже ковыряя не удастся. жаль.. ну тогда может спасёт накладывание патча на Cargo.toml (Cargo.lock) каждый раз перед сборкой (через sed например) то есть как ты ранее сказал -- "модифицировать сорцы из тарболла или из CARGO_HOME нельзя. Так?" -- отказаться от этого требования
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	64. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (64), 02-Мрт-19, 22:24
	>ну тогда может спасёт накладывание патча на Cargo.toml (Cargo.lock) каждый раз перед сборкой >(через sed например) Нет, спасет только чтение документации. Там все ваши хотелки расписаны по ключам.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	131. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Xasd5 (?), 04-Мрт-19, 01:00
	дай подсказку
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	144. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Anon111 (?), 05-Мрт-19, 13:20
	работа на offline "Airplane" mode https://github.com/rust-lang/cargo/issues/4686 "почти закончена"
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	145. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Anon111 (?), 05-Мрт-19, 13:39
	https://hackmd.io/hetFa17jRem_aKBCukrjVg#Cargo
	Ответить | Правка | ^ к родителю #144 | Наверх | Cообщить модератору

2. "Выпуск языка программирования Rust 1.33"	+12 +/–
Сообщение от Ordu (ok), 02-Мрт-19, 13:22
#[cfg(target_vendor="dos")] fn main() {     println!("This program cannot be run in DOS mode."); }
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Выпуск языка программирования Rust 1.33"	+3 +/–
Сообщение от Аноним (7), 02-Мрт-19, 13:48
Кроха сын к отцу пришёл, и спросила кроха: "Что сложнее C++ или Rust?"
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (10), 02-Мрт-19, 13:59
	Отец попросил кроху прийти лет через 30, когда разница в возрасте не будет так заметна)
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	23. "Выпуск языка программирования Rust 1.33"	+12 +/–
	Сообщение от Аноним (23), 02-Мрт-19, 15:51
	Отец попросил кроху прийти лет через 30, когда он подучит С++
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	13. "Выпуск языка программирования Rust 1.33"	+3 +/–
	Сообщение от Вы забыли заполнить поле Name. (?), 02-Мрт-19, 14:24
	Если под сложностью понимать сложность самой реализации своих идей на языке, то сложнее C++. А вот если подразумевать сложность монетизации своих навыков, то сложнее Rust.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	20. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от GentooBoy (ok), 02-Мрт-19, 15:35
	Есть мнение что это не надолго
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	30. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (-), 02-Мрт-19, 16:16
	Если C++ не осилить, то на нём конечно сложно написать что-либо полезное. Только вот ржавчина, у которой половина синтаксиса посвящена работе с памятью, в этом плане не легче.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	51. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Илья (??), 02-Мрт-19, 18:55
	У раста вообще синтаксиса много. И читается сложно
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	16. "Выпуск языка программирования Rust 1.33"	–3 +/–
	Сообщение от VINRARUS (ok), 02-Мрт-19, 14:52
	Отец ответил: "хз, шо там make, шо там make"
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	19. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (19), 02-Мрт-19, 15:25
	Сложнее понять, зачем вам вообще нужны эти монстры. D - наше всё. Особенно после появления бэкенда на LLVM.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	29. "Выпуск языка программирования Rust 1.33"	+2 +/–
	Сообщение от Аноним (-), 02-Мрт-19, 16:13
	На этот твой D даже Facebook забил. Не понятно зачем он нужен в свете C++20.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	45. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (45), 02-Мрт-19, 17:30
	О да, Facebook же пуп Земли.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	58. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (58), 02-Мрт-19, 21:52
	>C++20 в котором опять не будет модулей
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	63. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (63), 02-Мрт-19, 22: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]
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	71. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (58), 03-Мрт-19, 00:27
	в первый раз что ли? отложат как обычно
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	75. "Выпуск языка программирования Rust 1.33"	+1 +/–
	Сообщение от Аноним (-), 03-Мрт-19, 01:43
	Чего отложат как обычно? Они это уже проголосовали в стандарт (читать умеешь?). Когда это они до этого выкидывали то, что уже проголосовали?
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	98. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (98), 03-Мрт-19, 10:02
	последний раз в c++ 17
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	100. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (-), 03-Мрт-19, 11:55
	Не было такого, не ври. В С++17 модули не голосовали никогда. Голосовали TS после принятия стандарта.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	135. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от nobody (??), 04-Мрт-19, 10:44
	Ни холивара, но справедливости ради, таки выкинули concept'ы из С++0x. Прям из черновика стандарта судорожно вычищали в последний момент
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	139. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (139), 04-Мрт-19, 18:29
	Если справедливости ради - так их же не проголосовали в стандарт, а потом выкинули. Всё как Аноним из 7.75 и говорил.
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	146. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от nobody (??), 05-Мрт-19, 14:22
	> Если справедливости ради - так их же не проголосовали в стандарт, а > потом выкинули. Всё как Аноним из 7.75 и говорил. Что значит "не проголосовали"? Их включили в стандарт, но до утверждения не дошло. С модулям тоже до утверждения ещё целый год. Могут и выкинуть, теоретически
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	33. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Чёртик (?), 02-Мрт-19, 16:26
	Хомячкам сложно без уверенности в большом папке за спиной (читай лицокнига), без крутых тулчейнов и идеешек, с дебаггерами и рюшечками, без встроенной документации и телеграмм каналов с готовыми стогами ответов на стэк овер флоу
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	49. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Иваныч (??), 02-Мрт-19, 18:41
	Абсолютно правы. Только не Facebook, а Mozilla.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	38. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (38), 02-Мрт-19, 16:58
	Александреску облажался, впилив сборку мусора. Её-то сейчас можно отключить, только без неё тот же BCL не работает. А ведь просили всего лишь допилить синтаксис крестов.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	83. "Выпуск языка программирования Rust 1.33"	+3 +/–
	Сообщение от burjui (ok), 03-Мрт-19, 02:32
	Вынужден открыто не согласиться, как бывший пользователь и фанат 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 всё ещё мало пригоден для продакшена. Под продакшеном я понимаю нечто долговременное и надёжное, а не свои хобби-поделки с тремя звёздочками на гитхабе.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	134. "Выпуск языка программирования Rust 1.33"	+1 +/–
	Сообщение от anonjym (?), 04-Мрт-19, 10:34
	D вообще непонятно почему и зачем развивается, уже на rust есть вакансии, а на D нет вакансий; они столько сил тратят на этот D, что лучше бы на тот же C++ тратили силы
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	140. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от burjui (ok), 04-Мрт-19, 18:36
	Согласен. Но ещё лучше - на Rust. С++, как по мне, сам себя убивает с каждым новым стандартом.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	141. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от glebiao (ok), 05-Мрт-19, 06:22
	Вы правда не понимаете? Столько раз об этом говорилось. D и Rust не конкуренты. D --- акцент на быстрой(!) разработке при достаточной(!) надёжности, Rust --- обещание(!) надёжности. Всё. PS: C++ обещание современных высокоуровневых средств при максимально близком доступе к железу. далее выбираете тот инструмент, который Вам нужен, благо и D и Rust, не говоря о плюсах, к сегодня вполне себе допилен.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	142. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от glebiao (ok), 05-Мрт-19, 06:35
	> писал багрепорт, я бы не стал *так* писать в багзилле. как-то хамством очень попахивает :) >работает над взаимодействием (линковкой и т.п.) с кодом на C++. конечно. слишком много кода на плюсах, убежать или переписать его невозможно (и попросту, глупо). Жаль, что умер DSOM, не было-бы проблем с межъязыковыми связями. >Ирония в том, что большинство пользователей D хотят убежать от C++ как можно дальше, наверное, все-таки, не убежать, а минимизировать объём усилий в плюсах. Совсем убежать не выёдет (см выше). >shared - неюзабельное УГ, которое на бумаге выглядело хорошо очень сильное утверждение. Надо же понимать, как это сделано и ограничения! >Про микроконтроллеры можно забыть. Писать на D что-либо под STM32 - особый вид мазохизма. Да. Но такие цели и не ставились. Но и сказать, что нельзя запилить соотв. средства, тоже преувеличение. Понадобится кому --- сделает, нет сомнений. >GC, всё ещё пронизывающий стандарную библиотеку. и что? >Всякие полезные атрибуты типа const, pure и @nogc не включены по умолчанию. и что? разработчик, что, трёхлетка, которого надо водить за ручку? сам написать не может? > ООП и наследование; трейты гораздо гибче. о как. а трейты и соотв., миксины? >Разделение типов данных на ссылочные и нет. Захотел класс сделать структурой или наоборот? А изучить теорию, *почему* этио было сделано? Ведь заведомо ссылочная природа класса в ООП сразу решает массу неприятных проблем. >Три разных компилятора. и что? компилятор -- не Дункан Мак'Лауд >Вездесрущий null и всё, что с ним связано. После перехода на Rust вообще непонятно, зачем этот атавизм А что ты бы предложил? >Хочешь фичи и багфиксы - пиши всё сам я бы тоже был счастлив, если бы кто-то крупный взял бы проект под крыло. Очевидно, не так-то это просто, даже если у кого-то из китов и есть заинтересованность. >Под продакшеном я понимаю нечто долговременное и надёжное будет развитие, будут и ресурсы на стабильность. плюнем все дружно --- ну, там оно и останется.
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	127. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от anono (?), 03-Мрт-19, 22:10
	[{[][Objectiv-C}{][)
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

8. "Выпуск языка программирования Rust 1.33"	+1 +/–
Сообщение от Аноним (8), 02-Мрт-19, 13:52
> избавляет разработчика от манипулирования указателями Вот не могу понять, почему при всех фичах этого языка в первую очередь принято говорить об избавлении от указателей? С каких пор проблемы людей, не умеющих складывать целые числа, стали основной заботой разработчиков ЯП?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Ordu (ok), 02-Мрт-19, 14:07
	При чём тут "складывать числа"? Речь о другом. Скажем rust отслеживает ownership за тебя, а это значит, что ты не упрёшься в ситуацию, когда у строки есть два "владельца", и статически невозможно решить, кто из них должен освобождать память. Точнее даже не так. Это в C у тебя есть возможность подобную ситуацию не заметить, и эскалировать её до того, что один владелец освободит память, а другой продолжит ею пользоваться. В rust'е же ты как раз упрёшься в эту ситуацию лбом, потому что получишь ошибку компиляции. Разруливать эту ситуацию всё равно придётся тебе -- создавая лишнюю копию строки, или перелопачивая код так, чтобы не возникало нужды освобождать память дважды. То есть, фразировка в новости не совсем верная: манипулировать указателями придётся программисту. Но под пристальным оком борроу-чекера, который будет раздавать пинков за любое проявление неспособности просчитать лайфтаймы объектов в уме.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	41. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (41), 02-Мрт-19, 17:09
	При чём тут "Это в C"? Скажем C++ отслеживает ownership за тебя. Но разруливать дизайн всё равно придётся тебе -- выбирая подходящий тип смартпоинетра.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	48. "Выпуск языка программирования Rust 1.33"	+5 +/–
	Сообщение от анонн (?), 02-Мрт-19, 17:55
	> При чём тут "Это в 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/...
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	85. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (41), 03-Мрт-19, 05:49
	>> При чём тут "Это в C"? Скажем C++ отслеживает ownership за тебя. > Но это все не то. >> is equivalent Вы уж как-нибудь определитесь. > А уж концепта отслеживания времени жезни (как впрочем и "одалживания") в плюсах > вообще нет: И без ссылки верю, что разрулить не получилось.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	88. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от анонн (?), 03-Мрт-19, 06:06
	>>> 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. - >> А уж концепта отслеживания времени жезни (как впрочем и "одалживания") в плюсах >> вообще нет: > И без ссылки верю, что разрулить не получилось. Понимаю. Ходить по ссылкам, еще и читать целиком, осмысливая ...
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	94. "Выпуск языка программирования Rust 1.33"	–2 +/–
	Сообщение от Аноним (41), 03-Мрт-19, 06:58
	>>>> 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=(). >>> А уж концепта отслеживания времени жезни (как впрочем и "одалживания") в плюсах >>> вообще нет: >> И без ссылки верю, что разрулить не получилось. > Понимаю. Ходить по ссылкам, еще и читать целиком, осмысливая ... Если ты не осмыслил, то мне оно не зачем. Исходный мой тезис: "разруливать" приходится автору.
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	22. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от GentooBoy (ok), 02-Мрт-19, 15:46
	С тех пор как работа с указателями стала отвлекать от бизнеслогики Для маленький программ проблем нет, но проблемы больших и производительных систем очень заметны. Мы пытаемся уменьшить количество человеко часов, но когда система разрастается приходиться делить её на модули что опять не очень хорошо но это один из эффективных способ масштабирования проекта.  Также очень желательно что бы разработчика не отвлекал ЯП на рутину в виде указателей и отладки.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	43. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (41), 02-Мрт-19, 17:14
	Да. Интересный вопрос. Для сравнения: Имеет тонкий и быстрый FFI, обеспечивающий полное двустороннее взаимодействие с языком Си (вплоть до взаимной рекурсии); а также генератор привязок NLFFI (No-Longer-Foreign Function Interface), позволяющий встраивать заголовочные файлы Си прямо в проект на *** и использовать прямые вызовы функций Си в программах на ***.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

15. "Выпуск языка программирования Rust 1.33"	–1 +/–
Сообщение от НеСмузихлёб (?), 02-Мрт-19, 14:34
После утверждения модулей, сопрограмм и многих прочих вкусностей в C++20 растишку можно закапывать.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	18. "Выпуск языка программирования Rust 1.33"	–2 +/–
	Сообщение от Аноним (19), 02-Мрт-19, 15:23
	Сипипи давно уже из могилы вещает, так что непонятна ваша радость на похоронах :) А вот в C# появился pattern matching. Ни бог весть какая фича, но на понимание кода влияет сильно. Возврат кортежей - тоже удобно. Сам язык тоже всё больше упирает на лаконичность и читаемость. На его фоне юзать сипипи - можно оправдать только если вы полностью погружены в линукс.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	21. "Выпуск языка программирования Rust 1.33"	+3 +/–
	Сообщение от Xasd (ok), 02-Мрт-19, 15:36
	> Ни бог весть какая фича, но на понимание кода влияет сильно. Возврат кортежей - тоже удобно. система алиасов -- недоделана доконца! а они каккую-то дополнительную хрень выдумывают. 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>. вот просто где тут логика?  почему нельзя сделать алиас на неуточнённый генерик? любой алиас сделать можно -- но на неуточнённый генерик сделать алис нельзя (ЗА ШТО?!)-- "тут играем тут не играем"
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	39. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (38), 02-Мрт-19, 17:00
	Я больше скажу — алиас на алиас всё ещё иногда не собирается.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	25. "Выпуск языка программирования Rust 1.33"	+2 +/–
	Сообщение от Аноним (23), 02-Мрт-19, 15:54
	> А вот в C# И что мне делать с тюремным С на платформах отличных от windows? Есть нормальные опенсорсные тулзы для него? А то пока С#, windows, visual studio неразрывно связаны. Голимая прориетарщина.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	54. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Илья (??), 02-Мрт-19, 19:18
	> Есть нормальные опенсорсные тулзы для него? Нормальные тулзы кроме JetBrains вообще кто-нибудь делает? Скажем, для какой технологии есть действительно вменяемая IDE, и это не intellij? > А то пока С#, windows, visual studio неразрывно связаны. Большинство моих коллег поменяло VS+r# на Rider. Движение идёт в сторону .netcore. Надеемся, ждём > Голимая прориетарщина. Ну да. Тут не поспоришь.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	67. "Выпуск языка программирования Rust 1.33"	–2 +/–
	Сообщение от НяшМяш (ok), 02-Мрт-19, 23:07
	> для какой технологии есть действительно вменяемая IDE, и это не intellij? VSCode для JS\TypeScript. Такой себе ответ, но всё же.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	28. "Выпуск языка программирования Rust 1.33"	+2 +/–
	Сообщение от Аноним (-), 02-Мрт-19, 16:04
	Когда на ржавчине напишут хоть что-нибудь полезное кроме двух процентов кода Firefox, тогда и будете рассказывать про его преимущества над C++.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	35. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (-), 02-Мрт-19, 16:35
	Этот Си-паунд уже можно компилировать напрямую в нативный машинный код без костылей вроде CLR?
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	44. "Выпуск языка программирования Rust 1.33"	+2 +/–
	Сообщение от Аноним (41), 02-Мрт-19, 17:19
	До-диез же.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	59. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (59), 02-Мрт-19, 21:59
	Это тот тюремный с с рантаймом, il'ом и раздутой либой? Пускай идёт с джавой конкурировать и то только на винде. Плюсам он не ровня, а если мне будет плевать на производительность, я просто возьму питон.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	24. "Модули в C++"	+2 +/–
	Сообщение от MT (ok), 02-Мрт-19, 15:52
	Иногда возникает ощущение, что скорее выйдет Half-Life 3, чем наконец утвердят стандарт модулей C++.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	26. "Модули в C++"	+2 +/–
	Сообщение от Аноним (23), 02-Мрт-19, 15:55
	его утвердили https://www.reddit.com/r/cpp/comments/au0c4x/201902_kona_iso.../
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	37. "Модули в C++"	+/–
	Сообщение от MT (ok), 02-Мрт-19, 16:44
	Кул. Правда, насколько я понимаю, речь пока о черновике, который теоретически могут в текущем виде и не принять.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	53. "Модули в C++"	+1 +/–
	Сообщение от Аноним (-), 02-Мрт-19, 19:15
	Его могут поправить, но не принять не могут. Модули уже много лет мусолят, их планировали к C++17, на них было TS, две реализации в Clang, по одной в GCC и MSVS. Этот черновик не с бухты барахты.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	136. "Модули в C++"	+/–
	Сообщение от nobody (??), 04-Мрт-19, 11:03
	Могут, могут. См. мой коммент выше про C++0x concepts.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	42. "Модули в C++"	+1 +/–
	Сообщение от Аноним (42), 02-Мрт-19, 17:09
	> его утвердили https://www.reddit.com/r/cpp/comments/au0c4x/201902_kona_iso... Half-Life 3 утвердили? Ну наконец-то!
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	68. "Модули в C++"	+/–
	Сообщение от НяшМяш (ok), 02-Мрт-19, 23:09
	> C++ Committee Trip Report Это объясняет текущее состояние плюсов )
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

27. "Выпуск языка программирования Rust 1.33"	+/–
Сообщение от Аноним (-), 02-Мрт-19, 16:02
> при этом обходясь без использования сборщика мусора и runtime Прекратите уже повторять этот бред из новости в новость. Rust использует рантайм LLVM, причем, например, паники там реализованы с использованием механизма исключений C++.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	47. "Выпуск языка программирования Rust 1.33"	–2 +/–
	Сообщение от proninyaroslav (ok), 02-Мрт-19, 17:43
	Т.е реализовать zero runtime как в си нельзя?
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	61. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (61), 02-Мрт-19, 22:17
	Можно. Есть режим 'без стандартной библиотеки'.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	66. "Выпуск языка программирования Rust 1.33"	+2 +/–
	Сообщение от Аноним84701 (ok), 02-Мрт-19, 22:52
	> Т.е реализовать zero runtime как в си нельзя? Если на нем реализовали вполне работающую на реальном железе (пусть и игрушечную) ОСь и загрузчик: https://www.redox-os.org/ https://github.com/rust-osdev/bootloader > An experimental x86 bootloader written in Rust and inline assembly. то наверное таки реализовать можно.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	86. "Выпуск языка программирования Rust 1.33"	–4 +/–
	Сообщение от Аноним (41), 03-Мрт-19, 05:57
	>> Т.е реализовать 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 это имя регистра, то есть загрузчик написан на языке ассемблера.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	90. "Выпуск языка программирования Rust 1.33"	+2 +/–
	Сообщение от анонн (?), 03-Мрт-19, 06:25
	> Даже сорцы смотреть нет смысла, достаточно описания коммита: > "Use only `si` instead of `esi` for println in real mode (#47)" > SI это имя регистра, то есть загрузчик написан на языке ассемблера. > загрузчик > на языке ассемблера. Ну-ка, ну-ка. Код для MBR на плюсах, с инициализацией регистров, с точным контролем адресов инструкций и данных - в студию! Так и быть, читать с носителя за отсутствием рантайма, разрешаю через либастрал. "А потов-то, а понтов!" (с)
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	93. "Выпуск языка программирования Rust 1.33"	–3 +/–
	Сообщение от Аноним (41), 03-Мрт-19, 06:51
	>> Даже сорцы смотреть нет смысла, достаточно описания коммита: >> "Use only `si` instead of `esi` for println in real mode (#47)" >> SI это имя регистра, то есть загрузчик написан на языке ассемблера. >> загрузчик >> на языке ассемблера. > Ну-ка, ну-ка. Код для MBR на плюсах, с инициализацией регистров Может заодно и работу твою за тебя скампелировать? asm - ключевое слово языка. ,-) > с точным > контролем адресов инструкций и данных - в студию! А вот это даже на асме зачастую лишнее. > Так и быть, > читать с носителя за отсутствием рантайма, разрешаю через либастрал. > "А потов-то, а понтов!" (с) Да, я бы на твоём месте вёл себя поскромнее.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	110. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от анонн (?), 03-Мрт-19, 13:36
	>> Ну-ка, ну-ка. Код для MBR на плюсах, с инициализацией регистров > Может заодно и работу твою за тебя скампелировать? О, мы опять имеем счастье и честь лицезреть великих гуру опеннета! >> SI это имя регистра, то есть загрузчик написан на языке ассемблера. > asm - ключевое слово языка. ,-) А, ну если так, то это конечно уже не язык ассемблера. И регистры там не регистры. >> с точным контролем адресов инструкций и данных - в студию! > А вот это даже на асме зачастую лишнее. Ну раз гуру опеннета так говорит … в общем, "show me the code" или балабол.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	133. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (41), 04-Мрт-19, 09:08
	Ну, код ты в доказательство своей гипотезы не показал, так что... ;-)
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	111. "Выпуск языка программирования Rust 1.33"	+1 +/–
	Сообщение от Аноним84701 (ok), 03-Мрт-19, 13:39
	> Даже сорцы смотреть нет смысла, достаточно описания коммита: > "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)
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	116. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (41), 03-Мрт-19, 14:44
	>> Даже сорцы смотреть нет смысла, достаточно описания коммита: >> "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?
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	120. "Выпуск языка программирования Rust 1.33"	+1 +/–
	Сообщение от Аноним84701 (ok), 03-Мрт-19, 15:17
	> А разве кто-то утверждал, что это тоже на Rust? А кто утверждал-то, что оно полностью на Rust? Какое именно слово в процитированом  "in Rust and inline assembly" вам не понятно? Не томите, расскажите! Было логичное предположение, что те, кого возможность реализации "zero runtime" интересует не только сугубо теоретически, более-менее в курсе, что классический загрузчик для x86 без частей на асме пишется весьма фигово (от слова никак). Ну или хотя бы перед ответом прочтут написаное. Видимо я ошибся, увы мне :( Или это обычное "когда нечего возразить, но очень подгор^W хочется — прискипайся к формулировке"?
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	124. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (41), 03-Мрт-19, 17:28
	>> А разве кто-то утверждал, что это тоже на 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".
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	126. "Выпуск языка программирования Rust 1.33"	+1 +/–
	Сообщение от Аноним84701 (ok), 03-Мрт-19, 18:33
	>>> А разве кто-то утверждал, что это тоже на 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.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	132. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (41), 04-Мрт-19, 08:57
	>>>> А разве кто-то утверждал, что это тоже на 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 > > очень смахивет на q.e.d.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	138. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним84701 (ok), 04-Мрт-19, 13:06
	>> JMP@here в gdb. > Спасибо. Вот только бинарник ничего не делает. Вам, анонимам, не угодишь – то вам "файлов по объёму там достаточно для имплементации незаурядной Forth-машины", то компактная демонстрация, реализуемая штатными методами без UD и прочих хаков – наоборот, ничего не делает. > Вот тут обозначен диапазон адресов, где может быть сгенерировано исключение? > Что делать с этим в _произвольном_ месте в ядре? Вот в чём вопрос. Неужели так сложно было пройти по ссылке на код в пару строк? Это реализация обработчика паник, о котором изначально и шла речь в #27 "паники там реализованы с использованием механизма исключений C++." // This function is called on panic. #[panic_handler] fn panic(_info: &PanicInfo) -> ! {     loop {} }
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	143. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (143), 05-Мрт-19, 06:52
	> Вам, анонимам, не угодишь – > то вам "файлов по объёму там достаточно для имплементации незаурядной Forth-машины", > то компактная демонстрация, реализуемая штатными методами > без UD и прочих хаков – наоборот, ничего не делает. Не делает ничего, и не обрабатывает исключения. Запустите это без системного загрузчика и будет ой. >> Что делать с этим в _произвольном_ месте в ядре? Вот в чём вопрос. > Неужели так сложно было пройти по ссылке на код в пару строк? > Это реализация обработчика паник, о котором изначально и шла речь в #27 > "паники там реализованы с использованием механизма исключений C++." Это не ответ не вопрос.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

32. "Выпуск языка программирования Rust 1.33"	–3 +/–
Сообщение от Аноним (-), 02-Мрт-19, 16:21
Этот Rust ещё толком не родился, а уже весь в [s]костылях[/s] макросах.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	34. "Выпуск языка программирования Rust 1.33"	–3 +/–
	Сообщение от Чёртик (?), 02-Мрт-19, 16:30
	Его на ходу патчат левой пяткой, проектирование языка не для них.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

36. "Выпуск языка программирования Rust 1.33"	+/–
Сообщение от Аноним (-), 02-Мрт-19, 16:43
Идём смотрим на пример реальной программы на этом язычке: https://gitlab.gnome.org/GNOME/fractal/issues/431 И что мы там видим? Конечно панику.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	40. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (38), 02-Мрт-19, 17:03
	Вроде и радоваться надо, что кривой индонигeрский код падает с паникой, а не творит делов, но там куча issues один другого лучше.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	46. "Выпуск языка программирования Rust 1.33"	+2 +/–
	Сообщение от Анонимус2 (?), 02-Мрт-19, 17:34
	Все правильно, в c/c++ получили бы чтение и использование неинициализированной памяти, в rust - паника. Именно так все и задумывалось.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	50. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (-), 02-Мрт-19, 18:51
	В C++ было бы исключение, которое было бы поймано и обработано. В Rust исключений нет, поэтому паника на любой чих.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	60. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (61), 02-Мрт-19, 22:07
	У Раста панику можно обработать внутри кода, дубина.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	65. "Выпуск языка программирования Rust 1.33"	+1 +/–
	Сообщение от Аноним (-), 02-Мрт-19, 22:48
	У очередного растамана пригорело. Вам специально сделали язык, чтобы вы не игнорировали возвращаемые ошибки, так вы придумали макрос 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.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	87. "Выпуск языка программирования Rust 1.33"	+1 +/–
	Сообщение от Аноним (41), 03-Мрт-19, 06:04
	> A panic in Rust is not always implemented > via unwinding, but can be implemented by aborting the process as > well. Так это же Undefined behavior.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	97. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (61), 03-Мрт-19, 09:33
	В Расте гибко сделана обработка ошибок, это может быть паника, либо обработка этой паники. В чем претензия у Вас?
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	70. "Выпуск языка программирования Rust 1.33"	–2 +/–
	Сообщение от Ordu (ok), 03-Мрт-19, 00:27
	> В 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 зарегаться или залогиниться. У меня не выходит, а разбираться в чём там дело я не буду.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	74. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (-), 03-Мрт-19, 01:37
	Ну тебя и бомбит чувак. Если я в C++ конструирую окошечко и где-то внутрях вылетело std::out_of_range, мне не обязательно уничтожать всю программу, а достаточно лишь показать пользователю сообщение об ошибке в том месте, где пользователь попросил это окошечко открыть, и продолжить дальше. Впрочем, исключение при создании окошка на C++ тулкитах - это какая-то невероятная экзотика. Это только Rust может запаниковать на такой банальной фигне.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	78. "Выпуск языка программирования Rust 1.33"	+1 +/–
	Сообщение от Ordu (ok), 03-Мрт-19, 01:48
	> Если я в C++ конструирую окошечко и > где-то внутрях вылетело std::out_of_range, мне не обязательно уничтожать всю программу, > а достаточно лишь показать пользователю сообщение об ошибке в том месте, > где пользователь попросил это окошечко открыть, и продолжить дальше. Вся эта хрень, судя по всему, происходит при старте программы и инициализации собственно графики. В каком месте и как ты будешь показывать окошечко, если графика не сынициализировалась? И что ты будешь делать дальше?
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	77. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (-), 03-Мрт-19, 01:46
	Вот такие портянки растофанатиков почитаешь и понимаешь, что этот язык не для нормальных людей.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	79. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Ordu (ok), 03-Мрт-19, 01:48
	> Вот такие портянки растофанатиков почитаешь и понимаешь, что этот язык не для > нормальных людей. Да. Нормальные нам не нужны. Нормальные пускай дальше на C пишут.
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	82. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Ordu (ok), 03-Мрт-19, 02:01
	> Вот такие портянки растофанатиков почитаешь и понимаешь, что этот язык не для > нормальных людей. А кстати, что по твоему "нормальный человек"? Это тот, кто не может прочитать более 1kb текста, разбирающего код? То есть не программист вообще?
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	101. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (-), 03-Мрт-19, 12:05
	1kb гнилых оправданий почему программы на Rust должны паниковать вместо того, чтобы работать.
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	104. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Ordu (ok), 03-Мрт-19, 12:35
	> 1kb гнилых оправданий почему программы на Rust должны паниковать вместо того, чтобы > работать. Заурядная техника. Не можешь оспорить, навесь ярлык. Скучно. Ты не пробовал хотя бы правила демагога на луркморе прочитать, что ли? Ну, чтоб хоть немного разнообразия в свой арсенал демагогических приёмов внести.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	105. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (-), 03-Мрт-19, 12:44
	Демагогия - это рассказы про безопасность раста и отсутсвие UB. В реальности растопрограммы - это минное поле паник в рантайме, дедлоков и утечек ресурсов вместе с борьбой программистов против компилятора с помощью unwrap.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	106. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Ordu (ok), 03-Мрт-19, 13:02
	> Демагогия - это рассказы про безопасность раста и отсутсвие UB. В реальности > растопрограммы - это минное поле паник в рантайме, дедлоков и утечек > ресурсов вместе с борьбой программистов против компилятора с помощью unwrap. Молодец! Стоило только указать тебе на ошибки, и ты смог моментально переключиться на Bad Infinitum[1]. Такая гибкость заслуживает уважения. [1] https://techiavellian.com/intellectual-denial-of-service-att...
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	107. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (-), 03-Мрт-19, 13:16
	Это тебе нечего мне возразить https://ru.wikipedia.org/wiki/%D0%9F%D1%...(%D0%BF%D1%81%D0%B8%D1%85%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F)
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	109. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Ordu (ok), 03-Мрт-19, 13:32
	> Это тебе нечего мне возразить https://ru.wikipedia.org/wiki/%D0%9F%D1%...(%D0%BF%D1%81%D0%B8%D1%85%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F) Я выше всё написал. В качестве возражений я слышал лишь демагогию. Не, если хочешь, я могу скопировать ту простынку и ещё раз её запостить.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	113. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (-), 03-Мрт-19, 14:10
	В твоей простынке написано, что программа на расте, создающая графическое окно, обязательно должна паниковать. Я с этим и не спорю, если ты ещё не понял.
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	114. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Ordu (ok), 03-Мрт-19, 14:28
	> В твоей простынке написано, что программа на расте, создающая графическое окно, обязательно > должна паниковать. Я с этим и не спорю, если ты ещё > не понял. Ты читать умеешь? Там написано, что тот кто писал код не может распарсить строку вида "ключ:значение".
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	118. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (-), 03-Мрт-19, 14:53
	Отличный повод для паники 👍
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	121. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Ordu (ok), 03-Мрт-19, 15:18
	> Отличный повод для паники 👍 Слушай, может ты всё же почитаешь, что я там написал, и подумаешь головой о том, как C++ позволил бы избежать этой проблемы? Позволил бы он? Если бы автор написал бы этот свой код на всяких разных языках программирования, то в C он бы получил чтение за пределами массива, в C++/rust'е он бы получил исключение выхода за границы массива, в js и прочей нечисти такого рода, он бы прочитал несуществующее значение из массива, получил бы null или типа того, он бы получил false в результате сравнения и его код сработал бы. Правильно или не правильно -- я не знаю, всё зависит от того, должна ли быть else ветка if'а дефолтной или нет. В C++/rust'е он бы получил исключительную ситуацию, в C++ размотку стека исключением, в rust'е паникой. Обработать эту ошибку осмысленно невозможно. Такого рода ошибки исправляются единственным способом: проверкой индекса до того, как этот индекс был использован по назначению. Ты, я вижу, никак не можешь впитать эту идею. Я могу тебе помочь. Расскажи как бы ты, имея на руках аналогичную C++ программу, обезопасил функцию connect_gtk от подобных вылетающих исключений, вызванных тем, что тот кто писал всю эту пачку connect_* функций, позволял себе эпизодически выходить за границы массивов. Как бы ты обрабатывал такие исключения? Вот возьми и расскажи. Пока ты будешь рассказывать ты поймёшь о чём я, и тебе надоест рассказывать, ты удалишь всё написанное и опять включишь свою демагогию.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	123. "Выпуск языка программирования Rust 1.33"	+1 +/–
	Сообщение от Аноним (123), 03-Мрт-19, 16:44
	>  как 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++. Нельзя, паники в придумали расте не для этого. Но главная проблема раста даже не в этом. Проблема раста в том, что из этого кода просто не видно, что там зарыта паника.
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	130. "Выпуск языка программирования Rust 1.33"	–2 +/–
	Сообщение от Ordu (ok), 04-Мрт-19, 00:49
	>>  как C++ позволил бы избежать этой проблемы? Позволил бы он? > Во-первых, в C++ никому в голову не пришло бы писать подобный > бред с разбором строк ad-hoc: О, да. Я всё ждал, когда ты скажешь, что C++ программисты особенные, и они не делают таких ошибок. > это для скриптов такое поделие сойдёт, но не для кода, который должен > выполняться быстро (иначе зачем мы языком для системного программирования занялись?). Речь идёт о стартапе программы, который выполнится один раз. Какая разница четыре там выделения памяти или ноль? Никто никогда не заметит этой разницы глазом.
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	89. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (41), 03-Мрт-19, 06:25
	> connect_headerbars (который вероятно был заинлайнен > и поэтому Не является причиной. > не имеет самостоятельного стекового фрейма в release) _Даже_если_ так, не играет роли (и стандарт не оперирует абстракциями "регистр rbp"). Изучай существующие имплементации обработчиков, если интересны детали.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	95. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Ordu (ok), 03-Мрт-19, 07:24
	Не понял. Не является причиной чему? Не играет роли какой? При чём тут имплементации обработчиков? Ты хочешь этим намекнуть, что ты знаешь каким образом строится бектрейс, который выводится при RUST_BACKTRACE=1, и полагаешь, что если этот бектрейс не содержит в себе каких-то функций, которые по логике вещей должны были бы там быть, то это вовсе не потому, что эти функции были заинлайнены? Если ты так думаешь, то ты глубоко и печально ошибаешься. Сделай по сорцам раста find . -name libunwind, и загляни туда. Ты увидишь, что размотка стека на линуксе идёт посредством libgcc_s.so. Который -- сюрприз-сюрприз -- тоже входит в список абстракций, которым не оперирует стандарт. Подстава, да?
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	115. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (41), 03-Мрт-19, 14:40
	> Не понял. Не является причиной чему? Упомянутым якобы ограничениям. По стековым фреймам в *nix см. red zone, кадры не всегда организуются даже когда нужны. > Не играет роли какой? Предписываемой в гипотетических исключениях. Будет использовать кадр вызывающей функции (если имплементация вообще требует стэк, как в Win32). > При чём > тут имплементации обработчиков? Стандарт С++ определяет семантику исключений и приходится соответствовать. То есть перевод разговора на уровень имплементации рантайма трактуются лишь в ключе "я (не) знаю как". > Ты хочешь этим намекнуть, что ты знаешь каким образом строится бектрейс, который > выводится при RUST_BACKTRACE=1 Скажу прямо: это не моя забота знать, как там в Rust и почему inline стало проблемой, когда в С++ таковой не является.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	119. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Ordu (ok), 03-Мрт-19, 15:06
	> По стековым фреймам в *nix см. red zone, кадры не всегда организуются даже когда нужны. И что? Стековый фрейм начинается адресом возврата, и продолжается до следующего адреса возврата. То что ты называешь "организацией кадра" -- это лишь специальные телодвижения сводящиеся к тому, чтобы положить в известное и доступное место адрес этого самого стекового фрейма. > Стандарт С++ определяет семантику исключений и приходится соответствовать. То есть перевод разговора на уровень имплементации рантайма трактуются лишь в ключе "я (не) знаю как". Ах, так ты о C++ говоришь? И чё, бектрейсы в C++ пишут и про заинлайненные функции? Вот если я напишу C++ программу, скомпилирую её с -O2, стрипну всю дебаг-инфу из файла, то я смогу получить полный список вложенных вызовов в бектрейсе? > Скажу прямо: это не моя забота знать, как там в Rust и почему inline стало проблемой, когда в С++ таковой не является. Ты сам с собой разговариваешь? Где тут ты видишь проблему? Что бектрейс неполный? Дык это преимущество, это значит что бинарь не содержит всяких ненужностей, что inline-функция именно что inline функция, она встроена в вызывающую её функцию, будто она там была написана, она, в некоторых случаях, может быть оптимизирована так, что в коде не останется ни одной инструкции машинного кода от неё. Это преимущество, это хорошо и прельстиво. Если же тебе это не нравится, собирай debug-билд.
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	125. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (41), 03-Мрт-19, 18:09
	>> По стековым фреймам в *nix см. red zone, кадры не всегда организуются даже когда нужны. > И что? Стековый фрейм начинается адресом возврата, и продолжается до следующего адреса > возврата. Обычно под кадром понимают аргументы (если они сохранены на стэке) и локальные переменные функции. Адрес возврата это адрес возврата - его рисуют на картинках в книжках для пущего понимания и целостности картины. Эти данные не относятся к исключениям. > То что ты называешь "организацией кадра" -- это лишь специальные > телодвижения сводящиеся к тому, чтобы положить в известное и доступное место > адрес этого самого стекового фрейма. Организация кадра выполняется модификацией регистра процессора "указатель стека" (иногда используется регистр "базы стека"). Действительно, упомянутый регистр - известное место. >> Стандарт С++ определяет семантику исключений и приходится соответствовать. То есть перевод разговора на уровень имплементации рантайма трактуются лишь в ключе "я (не) знаю как". > Ах, так ты о C++ говоришь? Ну да. Выше кто-то заявил, что в С++ с этим нет проблем. > И чё, бектрейсы в C++ пишут > и про заинлайненные функции? Вот если я напишу C++ программу, скомпилирую > её с -O2, стрипну всю дебаг-инфу из файла, то я смогу > получить полный список вложенных вызовов в бектрейсе? Уверен, сможешь. Возможно, не с первой попытки, но сможешь. Ты специалист весьма грамотный и упорный, другое дело, что больше интересуешься высоким уровнем, а не всякими rop-гаджетами. Тут надо понимать, что дебажная инфа не относится к исключениям. Для них генерируются отдельные таблицы адресов try-блоков. То есть эти вещи ортогональны. Дебажная инфа по большому счёту нужна для сопоставления адресов машинных команд строчкам с исходниках. Ну и при построении графа вызовов не всегда получается гарантировано однозначно раскрутить стек, если не используется регистр базы стека. >> Скажу прямо: это не моя забота знать, как там в Rust и почему inline стало проблемой, когда в С++ таковой не является. > Ты сам с собой разговариваешь? Где тут ты видишь проблему? Я просто поверил тебе, как специалисту по Rust. Ты же сам сообщил, что из-за инлайна не будет стекового фрейма и потому в итоге вываливается паника, а иначе сделать нельзя.
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	137. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Ordu (ok), 04-Мрт-19, 12:23
	> Адрес возврата это адрес возврата - его рисуют на картинках в книжках для пущего понимания и целостности картины. Эти данные не относятся к исключениям. Что значит не относятся, если адреса возврата используются при размотке стека? То есть, возможны варианты организации размотки стека, когда ради неё создаётся отдельный стек, но... Не знаю как там в 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-гаджетами. Это "да" или "нет"? Я знаю, что я смогу, мне в жизни удавалось заставлять работать очень странные вещи и очень странными способами. Но это не ответ на поставленный вопрос. Впрочем, я уже догадался, что ответ -- нет. Если бы ответ был "да", ты бы не извивался тут ужом на сковородке, пытаясь изобразить что-то похожее на ответ так, чтобы оно не содержало бы в себе актуального ответа. > Ты же сам сообщил, что из-за инлайна не будет стекового фрейма и потому в итоге вываливается паника, а иначе сделать нельзя. Я такого не сообщал, ты не тем местом читал. У меня там выше целый пост, который приводит возможную причину паники, и не слова не сказано о том, что паника вылетела из-за отсутствия стекового фрейма. Слова о стековых фреймах были для того, чтобы обосновать поиск причины паники не только в той функции, из которой эта паника вылетела, согласно бектрейсу, но и в функциях, которые вызываются из неё, несмотря на то, что эти функции не упоминаются в бектрейсе, из чего, *как бы*, следует, что исключение возникло не в них.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

52. "Выпуск языка программирования Rust 1.33"	–5 +/–
Сообщение от Аноним (52), 02-Мрт-19, 19:13
>В репозитории Crates.io для публикации новых пакетов теперь обязательно требуется подтверждение своего email; Давайте ещё тогда сразу фингерпринт браузера, привязку мобильного, скан паспорта факсом, видео на фоне паспорта с приседаниями и "Ку!", снятое через приложение, крутящееся в TEE и образец ДНК требовать сразу, что уж мелочиться? Для адекватных же разработчиков просто оставлю ссылку: https://github.com/whyrusleeping/gx . Написан на goвне, из коробки идёт только для goвна и нодика, но можно приделать плагин для любого языка или даже дисприбутива.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	55. "Выпуск языка программирования Rust 1.33"	+4 +/–
	Сообщение от Аноним84701 (ok), 02-Мрт-19, 19:33
	>>для публикации новых пакетов  … подтверждение своего 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. Ни слова о том, что адрес должен быть привязан к реальному имени.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	57. "Выпуск языка программирования Rust 1.33"	–3 +/–
	Сообщение от Аноним (52), 02-Мрт-19, 21:44
	>To comply with DMCA Что не является легитимной причиной, как и любой другой to comply with <law of a totalitarian state> (напр. to comply to Yarovaya law) повод. >Ни слова о том, что адрес должен быть привязан к реальному имени. Фактически должен. Почтовые сервисы собирают либо телефоны пользователей, либо платёжные реквизиты. Либо им такие несговорчивые пользователи не нужны, их посылают вообще в баню. Есть временные почты, надо понимать, что они небесплатно работают: абузоустойчивый хостинг стоит денег, а абузы и маски-шоу силовиков будут, так как существование подобных сервисов многим невыгодно, а значит для владельца нужна юридическая и персональная защита, что тоже стоит недешево и поэтому результат будет таков: 1 пакет, к аккаунту которого привязана временная почта, будет заменён на вредоносный 2 "чтобы защитить пользователей" вообще ведут черные или даже белые списки почтовых сервисов, а внезапно ВСЕ крупные сервисы либо требуют привязку мобильного ИЛИ (в смысле F7) делают browser fingerprinting ИЛИ требуют оплату
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	62. "Выпуск языка программирования Rust 1.33"	+3 +/–
	Сообщение от Аноним84701 (ok), 02-Мрт-19, 22:18
	>>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:
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	69. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (52), 03-Мрт-19, 00:04
	>Угу, нужно уйти в онион-подполье и питаться биткоинами -- зато не нужно будет соответствовать законам страны базирования. Достаточно передать управление репозиторием иностранной организации, расположенной в юрисдикции, кде DMCA не действует. Но лучше всё же хостить всё в IPFS, а сайт упразднить.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	73. "Выпуск языка программирования Rust 1.33"	+1 +/–
	Сообщение от Аноним84701 (ok), 03-Мрт-19, 01:33
	> Достаточно передать управление репозиторием иностранной организации, расположенной > в юрисдикции, кде DMCA не действует. Но лучше всё же хостить  всё в IPFS, а сайт упразднить. Если я правильно понимаю ваши претензии -- все это нужно во имя сохранения анонимности автора? Но  скольким авторам _на самом деле_ это нужно? Вы можете привести пару примеров более-менее полезного софта "от анонимного анонима" (тем более остается вопрос, захотят ли они сами публиковаться на таком ресурсе)? Стоит ли "городить огород" для (почти буквально) 3½ человек, попутно создавая "все условия" для скрипткиддизов и прочих персонажей сомнительной нужности?
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	76. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (76), 03-Мрт-19, 01:44
	При условии анонимности хотиться проще, не от кого бы не убыло, а проектов может и прибыло.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	80. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (52), 03-Мрт-19, 01:53
	>Если я правильно понимаю ваши претензии -- все это нужно во имя сохранения анонимности автора? Это нужно, чтобы автор не потерял доступ к аккаунту. Если почта, на которой я зареган, потребует по закону о мессенджерах привязку мобильного, то я останусь без всех своих аккаунтов. Поэтому привязка аккаунтов к почте вместо привязки к информации для входа - это постановка меня в зависимость от этого сервиса и его хозяев. По сути это сродни установки рекапчи (оч. частое явление, не пользуюсь такими сайтами, только для некоторых вебсайтов сделано исключение, потому что капча у них только на регистрации, а я уже давно зарегистрирован, ещё при рекапче v1, и потому что они всё-таки работают над уходом от рекапчи) или требованием входа через фейсбук/госуслуги/AADHAAR (сразу в игнор - у меня нет этих аккаунтов).
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	92. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (41), 03-Мрт-19, 06:43
	Уважаемый, вы чем-то похожи на Ruptor-а. Но тот при всём при этом автор purenoise и enrupt, а вы?
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	99. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (52), 03-Мрт-19, 10:33
	Гугл говорит, что ruptor - это программа, а не ник. purenoise вообще какой-то вебсайт. Требую пояснения, кто такой этот Sean O'Neil, чем он знаменит (в википедии нет), чем его вклад значим и куда и по какой причине он пропал (за последние годы статей нет, институтская страничка тоже не гуглится). >Но тот при всём при этом автор purenoise и enrupt, а вы? Какое это отношение имеет к данному обсуждению? Чтобы иметь легитимное желание не быть лишённым всех аккаунтов по желанию левой пятки владельца сервиса электронной почты, нужно быть какой-то особо выдающейся личностью?
	Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

	108. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (41), 03-Мрт-19, 13:25
	> Гугл говорит, что 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, а вы? > Какое это отношение имеет к данному обсуждению? Чтобы иметь легитимное желание не > быть лишённым всех аккаунтов по желанию левой пятки владельца сервиса электронной > почты, нужно быть какой-то особо выдающейся личностью? Почитайте выше свой вопрос, который остался без ответа.
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	112. "Выпуск языка программирования Rust 1.33"	+1 +/–
	Сообщение от Аноним84701 (ok), 03-Мрт-19, 13:54
	> Это нужно, чтобы автор не потерял доступ к аккаунту. Если почта, на > которой я зареган, потребует по закону о мессенджерах привязку мобильного, то > я останусь без всех своих аккаунтов. Поэтому привязка аккаунтов к почте > вместо привязки к информации для входа - это постановка меня в > зависимость от этого сервиса и его хозяев. Это натягивание совы на глобус/притягивание за уши. Аккаунты, можно сказать традиционно и "издавна", привязывают к почте. Потерей аккаунта это грозит только в том случае, если прое^W потерять и пароль аккаунта и почтовый адрес одномоментно. В ином случае почтовый адрес вполне меняется, а пароль обычно восстанавливается как раз через ящик. Самое смешное -- за все это время я лишился только 1 почтового ящика по причине прекращения предоставления услуги, а вот аккаунты для давно не существующих ресурсов даже считать не хочу.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	128. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (52), 03-Мрт-19, 23:24
	поскольку аккаунты привязываются к почте, то любое действие по смене пароля или почты требует подтверждения через почту. то есть если потеряете доступ к почте - аккаунт навечно останется к ней поривязан. при любом взломе сервиса, компромитирующего базу паролей/хешей, вам принудительно сбросят пароль и вы потряете дос туп к аккаунту.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	72. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним84701 (ok), 03-Мрт-19, 01:17
	> 2 "чтобы защитить пользователей" вообще ведут черные или даже белые списки почтовых > сервисов, а внезапно ВСЕ крупные сервисы либо требуют привязку мобильного ИЛИ > (в смысле F7) делают browser fingerprinting ИЛИ требуют оплату Прошляпил добавить: сейчас там для логина нужен аккаунт на смузха^W гитхабе. А тот точно так же требует мыло, так что -- "что совой о пень, что пнем о сову ..." (с)
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	81. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (52), 03-Мрт-19, 01:55
	Ещё один довод не пользоваться их поделием.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	91. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Онаним (?), 03-Мрт-19, 06:29
	Зарегайте себе отдельный мэйл для этого дела и не морочте голову.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	129. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Аноним (52), 03-Мрт-19, 23:31
	"Отдельный мейл" тоже хостится на законопослушном сервисе, который выполнит закон о мессенджерах путём обязательной привязки мобильного.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

84. "Выпуск языка программирования Rust 1.33"	–1 +/–
Сообщение от Аноним (84), 03-Мрт-19, 04:42
Чет я не особо могу вакансию на раст найти
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	96. "Выпуск языка программирования Rust 1.33"	–1 +/–
	Сообщение от Аноним (96), 03-Мрт-19, 09:06
	Это да. И на ЛОРе главные растофанатики пишут на ненавистных крестах. Такие дела...
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	102. "Выпуск языка программирования Rust 1.33"	+1 +/–
	Сообщение от Anonim (??), 03-Мрт-19, 12:28
	http://itmozg.ru/vacancy/show/247722 https://t.me/rustlang_jobs
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	103. "Выпуск языка программирования Rust 1.33"	+/–
	Сообщение от Anonim (??), 03-Мрт-19, 12:34
	В этом telegram канале, часто объявления публикуются. Часто вижу вакансии на Rust в сфере торговли, криптовалюты и т.д.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

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

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