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

"Выпуск языка программирования Rust 1.34"	+/–
Сообщение от opennews (??), 14-Апр-19, 11:26
Состоялся (https://blog.rust-lang.org/2019/04/11/Rust-1.34.0.html) релиз языка системного программирования Rust 1.34 (http://www.rust-lang.org), развиваемого проектом Mozilla. Язык сфокусирован на безопасной работе с памятью, обеспечивает автоматическое управление памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime. Автоматическое управление памятью в Rust избавляет разработчика от манипулирования указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п. Для распространения библиотек, обеспечения сборки и управления зависимостями проектом развивается пакетный менеджер Cargo (http://blog.rust-lang.org/2014/11/20/Cargo.html), позволяющий получить нужные для программы библиотеки  в один клик. Для размещения библиотек поддерживается репозиторий crates.io (https://crates.io/). Основные новшества (https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve...): -  В пакетный менеджер Cargo добавлены средства для работы с альтернативными реестрами пакетов, которые могут сосуществовать с публичным реестром crates.io. Например, разработчики закрытых приложений теперь могут использовать собственный приватный реестр, который можно использовать при перечислении зависимостей в Cargo.toml, и применять для своих продуктов модель версионирования, схожую с crates.io, а также ссылаться в зависимостях как на crates.io, так и на собственный реестр. Для добавления внешнего реестра в ~/.cargo/config в секции "[registries]" предусмотрена (https://doc.rust-lang.org/nightly/cargo/reference/registries...) новая опция "my-registry", а для  упоминания внешнего реестра в зависимостях в Cargo.toml в секции "[dependencies]" появилась опция "other-crate". Для подключения к дополнительному реестру достаточно поместить токен аутентификации в файл ~/.cargo/credentials и выполнить команду "cargo login --registry=my-registry", а для публикации пакета - "cargo publish --registry=my-registry"; -  Добавлена полноценная поддержка использования оператора "?" в тестах doctests (https://doc.rust-lang.org/beta/rustdoc/documentation-tests.html), позволяющих использовать код примеров из документации в качестве тестов. Ранее оператор "?" можно было использовать для обработки ошибок в процессе выполнения тестов только при наличии функции "fn main()" или в функциях "#[test]"; -  В определяемых при помощи процедурных макросов собственных атрибутах (custom attribute) обеспечена (https://github.com/rust-lang/rust/pull/57367) возможность использования произвольных наборов токенов ("#[attr($tokens)]", "#[attr[$tokens]] и #[attr{$tokens}]"). Ранее элементы могли задаваться только в древовидном/рекурсивном виде c использованием строковых литералов, например "#[foo(bar, baz(quux, foo = "bar"))]", а теперь возможно использование перечислений ('#[range(0..10)]') и конструкций вида "#[bound(T: MyTrait)]"; -  Стабилизированы типажи (trait) TryFrom (https://doc.rust-lang.org/std/convert/trait.TryFrom.html) и TryInto (https://doc.rust-lang.org/std/convert/trait.TryInto.html), позволяющие выполнять преобразования типов с обработкой ошибок. Например, методы, подобные from_be_bytes, с целочисленными типами в качестве входных данных используют массивы, но данные часто поступают c типом Slice, а преобразование между массивами и слайсами проблематично делать вручную. При помощи новых типажей указанная операция может быть совершена на лету через вызов .try_into(), например, "let num = u32::from_be_bytes(slice.try_into()?)". Для преобразований, которые всегда завершаются успешно (например, из типа u8 в u32) добавлен тип ошибок Infallible (https://doc.rust-lang.org/std/convert/enum.Infallible.html), позволяющий прозрачно использовать   TryFrom для всех существующих реализаций "From"; -  Объявлена устаревшей функция  CommandExt::before_exec (https://doc.rust-lang.org/std/os/unix/process/trait.CommandE...), позволявшая выполнить обработчик перед запуском exec, который выполнялся в контексте дочернего процесса, ответвлённого после вызова fork(). В подобных условиях некоторые ресурсы родительского процесса, такие как файловые дескрипторы и отражённые области памяти, могли быть дублированы, что могло привести к неопределённому поведению и неверной работе библиотек. Вместо before_exec рекомендуется использовать  unsafe-функцию CommandExt::pre_exec (https://doc.rust-lang.org/std/os/unix/process/trait.CommandE...). -  Стабилизированы знаковые и беззнаковые атомарные целочисленные типы размером от 8 до 64 бит (например, AtomicU8 (https://doc.rust-lang.org/std/sync/atomic/struct.AtomicU8.html)), а также знаковые типы  NonZeroI (https://doc.rust-lang.org/std/num/struct.NonZeroI8.html)[8|16|32|54|128]. -  В разряд стабильных переведена новая порция API, в том числе стабилизированы методы Any::type_id, Error::type_id,   slice::sort_by_cached_key, str::escape_*,   str::split_ascii_whitespace, Instant::checked_[add|sub] и     SystemTime::checked_[add|sub]. Стабилизированы функции iter::from_fn и iter::successors; -  Для всех целочисленных типов реализованы методы checked_pow, saturating_pow, wrapping_pow и overflowing_pow; -  Добавлена возможность включения оптимизаций на этапе связывания  через указание сборочной опции "-C linker-plugin-lto" (rustc компилирует код Rust в биткод LLVM, что позволяет применить LTO-оптимизации). URL: https://blog.rust-lang.org/2019/04/11/Rust-1.34.0.html Новость: https://www.opennet.dev/opennews/art.shtml?num=50513
Ответить | Правка | Cообщить модератору

Сообщения

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

1. "Выпуск языка программирования Rust 1.34"	+2 +/–
Сообщение от Аноним (1), 14-Апр-19, 11:26
Троекратное "урра!"
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "Выпуск языка программирования Rust 1.34"	+2 +/–
	Сообщение от Аноним (8), 14-Апр-19, 12:21
	Расти, расти, сынок, кушай Растишку :)
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	51. "Выпуск языка программирования Rust 1.34"	–2 +/–
	Сообщение от Аноним (51), 14-Апр-19, 16:34
	"М-м-м-м Данон"
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	139. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от x (?), 15-Апр-19, 13:35
	"Растишишку" же ну
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

2. "Выпуск языка программирования Rust 1.34"	+1 +/–
Сообщение от Аноним (2), 14-Апр-19, 11:59
Давайте только серьезно: на сколько нормальный этот язык?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Выпуск языка программирования Rust 1.34"	+5 +/–
	Сообщение от Аноним (3), 14-Апр-19, 12:06
	Если почистить от ржавчины, то будет норм.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	5. "Выпуск языка программирования Rust 1.34"	+2 +/–
	Сообщение от microcoder (ok), 14-Апр-19, 12:07
	Ржавчину от ржавчины? Что будет в остатке?
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	6. "Выпуск языка программирования Rust 1.34"	+2 +/–
	Сообщение от Аноним (3), 14-Апр-19, 12:15
	А останется Си.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	17. "Выпуск языка программирования Rust 1.34"	+7 +/–
	Сообщение от Аноним84701 (ok), 14-Апр-19, 13:00
	> А останется Си. Не останется. Для этого нужно не только чистить (т.е. удалить пространство имен, заменить нормальный, интегрированный непосредственно с ЯП движок макросов на "левый", отдельный препроцессор, умеющий лишь чуть больше, чем search&replace, удалить излишне строгую и гибкую типизацию, эти ваши новомодные трейты и дженерики), а еще и добавлять -- например, кучу исторически обусловленных UB.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	33. "Выпуск языка программирования Rust 1.34"	+7 +/–
	Сообщение от Аноним (33), 14-Апр-19, 14:06
	Не беспокойтесь, над этим уже работают.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	4. "Выпуск языка программирования Rust 1.34"	+6 +/–
	Сообщение от анонас (?), 14-Апр-19, 12:06
	Самый лучший язык in the world!
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	77. "Выпуск языка программирования Rust 1.34"	+33 +/–
	Сообщение от Злюка (?), 14-Апр-19, 21:16
	in the hello world!
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	15. "Выпуск языка программирования Rust 1.34"	+5 +/–
	Сообщение от anono (?), 14-Апр-19, 12:59
	критерий нормальности языка?!
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	22. "Выпуск языка программирования Rust 1.34"	+3 +/–
	Сообщение от Аноним (22), 14-Апр-19, 13:19
	> критерий нормальности языка?! 90 градусов к мейнстриму
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	92. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от НяшМяш (ok), 14-Апр-19, 23:43
	и по-моему, он отлично справляется
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	31. "Выпуск языка программирования Rust 1.34"	+1 +/–
	Сообщение от Fracta1L (ok), 14-Апр-19, 13:54
	На 8
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	62. "Выпуск языка программирования Rust 1.34"	+10 +/–
	Сообщение от Аноня (?), 14-Апр-19, 18:17
	Из плюсов 1. Интересная асинхронная модель 2. Отсутствие Null, очень мощный патерн-мачинг, Энамы со значениями 2. Абстракция от любых небезопасных взаимодействий с указателями 3. Возможность любых небезопасныйх действий с указателями в unsafe 3. FFI C, можно любую библиотеку в пару кликов завернуть 2. Единый стиль форматирования заложен в язык Rustfmt 3. Rustup как менеджер установленных версий раста, очень удобно 4. Cargo, очень удобно Из минусов (имхо) 6. Куча больных фанатиков, которые после месячного опыта в JS лезут куда не надо
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	90. "Выпуск языка программирования Rust 1.34"	–6 +/–
	Сообщение от Аноним (90), 14-Апр-19, 23:22
	> Интересная асинхронная модель Ничего интересного, шлём мессаджи в чаннелах. > Отсутствие Null, очень мощный патерн-мачинг, Энамы со значениями Option, pattern-matching слизан со Scala, он не дотягивает всё равно, Энамы со значениями - ололо, ну никто такого не умеет. > Абстракция от любых небезопасных взаимодействий с указателями В любых managed языках > FFI C, можно любую библиотеку в пару кликов завернуть Ok > Единый стиль форматирования заложен в язык Rustfmt Зачем это в языке. Решается сторонними тулами > Rustup как менеджер установленных версий раста, очень удобно Ok > Cargo, очень удобно Решается автоматическими системами сборки
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	97. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноним (97), 15-Апр-19, 00:27
	> Option, pattern-matching слизан со Scala, Scala-утёнок
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	127. "Выпуск языка программирования Rust 1.34"	–4 +/–
	Сообщение от Аноним (90), 15-Апр-19, 11:10
	По существу есть что, кроме ad hominem?
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	113. "Выпуск языка программирования Rust 1.34"	+14 +/–
	Сообщение от Аноним (113), 15-Апр-19, 07:24
	Тут весь прикол в том, что антинулл абстракции и паттерн-мэтчинг поставили на низкровневый язык. Так что все эти ваши "слизано со Скала" и "в 100500 языках есть" не аргумент - есть-то есть, но обычно это языки с ГЦ, а то и интерпретируемые.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	73. "Выпуск языка программирования Rust 1.34"	+6 +/–
	Сообщение от Аноним (113), 14-Апр-19, 20:42
	В нем же безопасная память без GC, это разве не киллер-фича?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	75. "Выпуск языка программирования Rust 1.34"	–4 +/–
	Сообщение от Аноним (75), 14-Апр-19, 20:50
	У тебя даже с русским нелады, какая тебе разница
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	91. "Выпуск языка программирования Rust 1.34"	+3 +/–
	Сообщение от Аноним (91), 14-Апр-19, 23:35
	> Давайте только серьезно: на сколько нормальный этот язык? Вот смотри. Пргер пишет разработчикам - я не моуг сделать ан вашем расте вот такую вешь. Разарабы отвчеют - оке, щас добавим в язык
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	161. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от burjui (ok), 17-Апр-19, 11:14
	Наглое враньё. Разработчики отвечают: пишите RFC, мы почитаем и подумаем. Иногда в язык что-то из RFC попадаёт. Иногда даже в изначальном виде.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

7. "Выпуск языка программирования Rust 1.34"	–3 +/–
Сообщение от Анонимс (?), 14-Апр-19, 12:16
Что говорят бенчмарки Rust vs. C++, какой язык более производительный и удобный в разработке? Или ещё пока рано делать какие-то выводы?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	16. "Выпуск языка программирования Rust 1.34"	+2 +/–
	Сообщение от zo0M (ok), 14-Апр-19, 13:00
	вас в гугле забанили? Первый же результат поисковой выдачи: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	24. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от rustshlak (?), 14-Апр-19, 13:28
	выборка не репрезентативная в отличии от раста на С и С++ можно написать код по разному и в примере как раз не самые лучшие реализации
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	26. "Выпуск языка программирования Rust 1.34"	+3 +/–
	Сообщение от Аноним84701 (ok), 14-Апр-19, 13:40
	> и в примере как раз не самые лучшие реализации Ну да, все так - проект "The Great Computer Language Shootout" слишком молод, за чуть менее чем 20 лет не успели вылизать реализации: https://benchmarksgame-team.pages.debian.net/benchmarksgame/... всего 6 штук плюсовых. И фильтр там хитрый стоит -- так-то туда код может любой желающий запостить (при мне ЛОРовец закоммитил более быструю реализацию чего-то для своего любимого ЯП), но вот анонимы с опеннета фильтруются только так, иначе бы они давно показали, как надо правильно реализовать! :)
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	35. "Выпуск языка программирования Rust 1.34"	–3 +/–
	Сообщение от rustshlak (?), 14-Апр-19, 14:18
	у меня достаточно знаний что бы увидеть почему реализация на расте опередила на чуть чуть реализацию на СИ и как сольет раст если из реализации на СИ это устранить а вам слабо назвать это причину ?
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	37. "Выпуск языка программирования Rust 1.34"	+7 +/–
	Сообщение от Аноним84701 (ok), 14-Апр-19, 14:23
	> у меня достаточно знаний что бы увидеть почему реализация на расте опередила > и как сольет раст если "Talk is cheap. Show me the code!" (c) https://salsa.debian.org/benchmarksgame-team/benchmarksgame/... > Upload a complete tested source-code file > Open a new [Contribute Source Code](https://salsa.debian.org/benchmarksgame-team/benchmarksgame/... Source Code) issue. > Attach your complete tested source-code file. .
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	42. "Выпуск языка программирования Rust 1.34"	+7 +/–
	Сообщение от Ordu (ok), 14-Апр-19, 14:55
	> у меня достаточно знаний что бы увидеть почему реализация на расте опередила на чуть чуть реализацию на СИ > и как сольет раст если из реализации на СИ это устранить Почему же? У меня нет желания копаться в коде и профайлить его, тем более что у меня есть generic объяснение: это работа оптимизатора. Меньше десяти процентов производительности, на фоне нескольких вариантов C'шной реализации -- это стопудов работа оптимизатора, C просто упёрся в невозможность оптимизировать некоторые вещи, в силу того что он позволяет слишком много свобод программисту. Искусственный интеллект оптимизатора недостаточно интеллект, чтобы сообразить некоторые вещи, а программист недостаточно искусно владеет C, для того, чтобы эти вещи выразить в коде в виде понятном для оптимизатора. Строгость rust'а позволяет иногда оптимизатору оптимизировать лучше. Или программисту меньше парится о возможных ошибках, потому как они невозможны. Тут ярким примером может служить utf8 строка: rust валидирует эти строки на входе, что с одной стороны замедляет, например, работу BufReader::read_line, но с другой стороны позволяет затем работать со строкой исходя из предположения, что мы имеем дело с валидным utf8, не добавляя в код условных переходов на случай невалидного utf8, и таким образом делая быстрее любой код итерирующий по символам. То есть вместо того, чтобы при каждом проходе по строке производить валидацию параллельно, мы делаем её один раз. И это может проявлятся не только в случае utf8 строк, но и в случае, например, указателей, потому что компилятор rust'а И программист, полагаются на то, что эти указатели ненулевые, в то время как C'шный код вынужден постоянно держать в уме возможность для любого указателя быть нулевым. Это, кстати, создаёт impedance mismatch на границе между rust'овым кодом и C'шным, потому что получая, например, строку из C'шного кода (то есть char*), мы должны проверить не NULL ли он, проверить валидность этой строки (потому что C запросто может жонглировать невалидными utf8 строками), и только после этого начинать какую-то осмысленную работу с этой строкой (это ещё если не придётся упереться в вопросы lifetime'ов, и не придётся рубить эти проблемы как гордиев узел посредством растового аналога strdup, хотя подобные проблемы, наверное, и в грамотном C'шном коде будет решаться так же, в rust'е они просто ярче проявляются и их сложнее не заметить). Но это я отвлёкся от темы. Помимо этого может сказываться большая выразительность языка. Например, rust для итерации позволяет использовать не только циклы, но и итераторы с их функционалами, типа map и reduce, которые гораздо удобнее оптимизатору для понимания происходящего, и более того ограничивают программиста загоняя его в узкие рамки, и вынуждая писать код, который легко векторизовать. Но это всё теоретические сопли, рассуждения из общих соображений. И я бы с радостью посмотрел бы на подробное сравнение C'шного кода и Rust'ового, чтобы с профайлером, ассемблерными дампами и прочими атрибутами, которое бы либо подтвердило мои общие соображения, либо опровергло бы их, дав альтернативное объяснение, которое лучше отражает реальность. Но сам я не готов лезть и тратить час, два или полдня на это.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	69. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от Forth (ok), 14-Апр-19, 19:09
	Если говорить про область системного ПО, то там часто с UTF-8 дела иметь не приходится. Что касается null, то многие функции пишутся с расчетом, что null туда не прилетит и никаких проверок не делается в релизном коде. В дебажном компилится макросами assert. Где тут потери производительности? Итераторы в С всегда делались на макросах или на структурах, если нужно. Возвращаешь вместо указателя на коллекцию итератор и функцию next. P.S. Сам перехожу на Rust с C, там где он был мне C был нужен. Если буду писать на Rust быстрее, чем на C, уже стоило того.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	74. "Выпуск языка программирования Rust 1.34"	+7 +/–
	Сообщение от Ordu (ok), 14-Апр-19, 20:45
	> Если говорить про область системного ПО, то там часто с UTF-8 дела > иметь не приходится. Да? Ты читаешь файл конфигурации, в нём может быть много чего, в том числе и utf8-комментарии, или utf8-строчки, между ними затесались имена файлов. Но это собственно не важно: пример с utf8 я приводил, только чтобы пояснить мысль о том, как повышение уровня гарантий может приводить к более быстрому коду. > Что касается null, то многие функции пишутся с расчетом, что null туда > не прилетит и никаких проверок не делается в релизном коде. В > дебажном компилится макросами assert. Где тут потери производительности? Как где? На практике же. В теории -- да, в теории не должно быть ненужных проверок на null. На практике же эти проверки так или иначе просачиваются в код. На всякий случай. Потому что C не даёт тебе способа доказать, что здесь не случится нулевого указателя. assert тебе тоже ничего не гарантирует: если дебажная сборка не падает на assert'ах, то это доказывает лишь то, что тебе не удалось найти способа уронить её на assert'ах. fuzzing может дать ответ, но он тоже не доказывает, лишь повышает степень уверенности. В rust'е же, если ты создавая ссылки из C'шных указателей в unsafe блоках проверил их на ноль (тут уже в обязательном порядке или с трёхстрочным комментарием поясняющим почему в данном случае проверка не нужна), обработал ситуацию когда указатель NULL, то тогда у тебя не может быть нулевых указателей. Довольно просто всё, и главное легко верифицируемо, даже совершенно посторонним человеком. Такой аудит проведёт и баба Клава, если ей объяснить как в коде найти все unsafe блоки, и на что именно надо смотреть. > Итераторы в С всегда делались на макросах или на структурах, если нужно. > Возвращаешь вместо указателя на коллекцию итератор и функцию next. Это не совсем то. map позволяет указать функцию, которую надо применить к каждому элементу коллекции. У этой функции будут серьёзные проблемы в rust'е, если она попытается иметь mutable доступ к внешней переменной (я не уверен, впрочем, преодолимы ли эти проблемы). То есть, скорее всего она не будет обращаться к внешним переменным и будет чем-то близким к pure function, то есть к функции чьё возвращаемое значение зависит исключительно от значения аргумента, и которая не меняет состояние мира, то есть никаких побочных эффектов нет. А если так, то вызовы этой функции для каждого элемента коллекции можно выполнять в произвольном порядке, хоть параллельно. Это проверяется тривиально в rust'е, и отклонение от этого будет причинять неудобства для программиста. А это значит, что с большей вероятностью код окажется параллелизуемым. В C это всё можно проделать, но там нет возможности объявить функцию inline, прям в списке аргументов вызова функционала. Поэтому так никто в здравом уме так делать не будет. Проще написать for/while, и отследить глазами, чтобы между последовательными итерациями не было бы зависимости по данным.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	78. "Выпуск языка программирования Rust 1.34"	+5 +/–
	Сообщение от JustCurious (?), 14-Апр-19, 21:26
	Круто! Редко на опеннете натыкаешься на такие качественные комментарии. Спасибо за детальные объяснения
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	86. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от Forth (ok), 14-Апр-19, 22:40
	> Да? Ты читаешь файл конфигурации, в нём может быть много чего, в > том числе и utf8-комментарии, или utf8-строчки, между ними затесались имена файлов. > Но это собственно не важно: пример с utf8 я приводил, только > чтобы пояснить мысль о том, как повышение уровня гарантий может приводить > к более быстрому коду. Я про то, что большой вопрос сколько данных на самом деле содержат utf-8. В Java недавно по этому поводу ввели два типа строк внутри, с ascii вариантом. По анализу дампов приложений статистика показала, что много чисто ascii дряни. Ясно почему, кругом json, html, xml и прочее около ascii. Много всякой фигни, типа csv с цифрами сполшными, что парсится-то как строки. > Как где? На практике же. В теории -- да, в теории не > должно быть ненужных проверок на null. .....Такой аудит проведёт и баба Клава, если ей объяснить > как в коде найти все unsafe блоки, и на что именно > надо смотреть. Я вот не вижу большой разницы между if (something == null) и Some + None. Все равно будет ветвление в коде. Кроме того, если в C основной код покрыт assert-ами и тестами, а входные данные проверяются, то null не поймать, на практике :) >> Итераторы в С всегда делались на макросах или на структурах, если нужно. >> Возвращаешь вместо указателя на коллекцию итератор и функцию next. > Это не совсем то. map позволяет указать функцию, которую надо применить к > каждому элементу коллекции. ... А это значит, что с большей вероятностью код > окажется параллелизуемым. Могу еще в C передать в функцию указатель на функцию. Её и применят на коллекцию. В C это все реализуемо и даже встречается местами. Безусловно не так удобно, но можно же. > В C это всё можно проделать, но там нет возможности объявить функцию > inline, прям в списке аргументов вызова функционала. Поэтому так никто в > здравом уме так делать не будет. Проще написать for/while, и отследить > глазами, чтобы между последовательными итерациями не было бы зависимости по данным. Макросами можно, выглядеть будет так, и инлайн будет. На самом деле проблема как обычно от рук идёт. Если программист на C хотел сделать код безопасным и хорошо структурированным, то сделал.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	96. "Выпуск языка программирования Rust 1.34"	+2 +/–
	Сообщение от Ordu (ok), 15-Апр-19, 00:22
	> Я вот не вижу большой разницы между if (something == null) и > Some + None. > Все равно будет ветвление в коде. Some+None будет возникать, если мы передаём в функцию (или извлекаем из какой-нибудь структуры) *T или Option<NonNull<T>>. А если мы туда передаём &T (что гораздо более распространено и удобно), то никаких ветвлений там не будет.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	122. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от Forth (ok), 15-Апр-19, 10:27
	> Some+None будет возникать, если мы передаём в функцию (или извлекаем из какой-нибудь > структуры) *T или Option<NonNull<T>>. А если мы туда передаём &T (что > гораздо более распространено и удобно), то никаких ветвлений там не будет. В C можно не передавать null и делать assert и ничего не проверять. Статический анализ делать в конце-концов. Я не считаю отсутствие null большим достоинством языка. Для меня в Rust принципиально новым являются правила владения и заимствования ссылок. А null не так страшен, как его малюют :)
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	80. "Выпуск языка программирования Rust 1.34"	+1 +/–
	Сообщение от Аноним84701 (ok), 14-Апр-19, 21:38
	> Что касается null, то многие функции пишутся с расчетом, что null туда > не прилетит и никаких проверок не делается в релизном коде. В > дебажном компилится макросами assert. Где тут потери производительности? https://github.com/systemd/systemd/issues/4234 > Assertion failure when PID 1 receives a zero-length message over notify socket #4234 Ubuntu, 16.04 (systemd v229), with the while loop PoC: Sep 28 22:21:36 odyssey systemd[1]: Cannot find unit for notify message of PID 21076. Sep 28 22:21:36 odyssey systemd[1]: Cannot find unit for notify message of PID 21077. Sep 28 22:21:36 odyssey systemd[1]: Assertion 'n > 0' failed at ../src/core/manager.c:1501, function manager_invoke_notify_message(). Aborting. Sep 28 22:21:37 odyssey systemd[1]: Caught , dumped core as pid 21079. Sep 28 22:21:37 odyssey systemd[1]: Freezing execution. Я не холивара ради (хотя: раст есть, системд есть, осталось упомянуть Теслу, питон, JS и смузи), просто пальцы зачесались ;)
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	88. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от Forth (ok), 14-Апр-19, 22:42
	Так тут assert не при чем. Assert для отлова ошибок в своем коде, а не для проверки внешних данных.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	149. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноним (149), 15-Апр-19, 19:47
	http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performa.../
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	104. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноним (104), 15-Апр-19, 01:52
	> у меня достаточно знаний что бы увидеть почему реализация на расте опередила > на чуть чуть реализацию на СИ > и как сольет раст если из реализации на СИ это устранить > а вам слабо назвать это причину ? Не говоришь потому, что боишся быть опозореным.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	28. "Выпуск языка программирования Rust 1.34"	+1 +/–
	Сообщение от zo0M (ok), 14-Апр-19, 13:44
	давайте факты в студию, или вы так, заради "потрындеть"? мне ваша полемика до одного места я вам бенчмарк, а теперь вы мне свой, вот тогда и поговорим серьезно.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	36. "Выпуск языка программирования Rust 1.34"	–8 +/–
	Сообщение от rustshlak (?), 14-Апр-19, 14:23
	это не ваш бенчмарк а я достаточно уверен в себе что бы никому ничего не доказывать в прочем лишний раз убеждаюсь что растоманы это похапе недоучи про алгоритмическую сложность их не учили какой то чудо растоман видимо только закончил школу и применил свои знания на бенчмарке получив чуть выиграша против "тупой реализации на СИ" и стадо растоманов уже подумало что их раст впереди ЛОЛ)))) сравните лучше одинаковые алгоритмические сложности на СИ и расте и поймете в какой попе ваш раст
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	64. "Выпуск языка программирования Rust 1.34"	+2 +/–
	Сообщение от Аноня (?), 14-Апр-19, 18:37
	Rust и c/с++ не настолько отличаются в производительности, чтобы серьёзно их сравнивать. Ну получите вы отличие в 7% И что? Перепишите всё с сей на раст или наоборот? Дело не в производительности, и производительность не первоочередная задача у раста.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	101. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от Аноним (101), 15-Апр-19, 00:55
	У раста вообще не понятно какая задача. Так замусорить синтаксис только ради введения семантики владения памятью - это надо было додуматься. А если кто-то придумает как дедлокобезопасность реализовать - опять новый язык с кучей мусора в синтаксисе будет?
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	116. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноня (?), 15-Апр-19, 08:07
	Нет, некоторые проблемы нереально решить средствами языка. Круг задач, решаемый борроу чекером ограничен и не предендует на панацею от всех проблем. Сами разработчики раста оперируют термином "undefined behavior", которое узко ограничено и не включает в себя утечки памяти, дедлоки и прочие проблемы. Вы токсичны, и ваши сообщения неприятно читать
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	124. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноним (124), 15-Апр-19, 11:00
	>  оперируют термином "undefined behavior", которое узко ограничено и не включает а ещё собственным определением понятия ООП, которое тоже ограничено и не включает > Вы токсичны, и ваши сообщения неприятно читать это называется правда глаза режет.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	136. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от анонн (?), 15-Апр-19, 12:19
	>>  оперируют термином "undefined behavior", которое узко ограничено и не включает > а ещё собственным определением понятия ООП, которое тоже ограничено и не включает А на самом деле правильное определение ООП будет? >> Вы токсичны, и ваши сообщения неприятно читать > это называется правда глаза режет. Но полемика и передерг почему-то у вас.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	148. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноня (?), 15-Апр-19, 19:19
	> а ещё собственным определением понятия ООП, которое тоже ограничено и не включает Понятное дело, объектов-то нет. В расте никто не обещал ООП.
	Ответить | Правка | ^ к родителю #124 | Наверх | Cообщить модератору

	93. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от НяшМяш (ok), 14-Апр-19, 23:50
	Вас в детстве языком без указателей и UB били? Что за ненависть к просто ещё одному языку? Почему вы считаете, что лучше опозориться прилюдно, чем пройти мимо новости?
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	123. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от Аноним (123), 15-Апр-19, 10:56
	Так ты и не доказывай, просто объясни как по-твоему можно быстрее написать код. А ходить и без дела поливать говном людей, которые меньше тебя разбираются в языке, выставляет тебя самого как недавно школу окончившего.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	19. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от GentooBoy (ok), 14-Апр-19, 13:04
	Два небольших примера что делают на расте при помощи макросов. http://diesel.rs https://usehelix.com Если нужно живое приложение то https://github.com/dani-garcia/bitwarden_rs отлично показывает что раст может сильно потеснить другие яп, в том числе и го, ну а  для С++ раст прямой конкурент. Бенчи вам тут мало помогут, https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	41. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноним (41), 14-Апр-19, 14:50
	Главное верить.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	57. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от Аноним (57), 14-Апр-19, 17:07
	Трындец, вот это фанбойство в терминальной стадии: макросы, рубины и непревзойденная ржавчина в одной куче с солнцеликой восторженностью.
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	70. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от GentooBoy (ok), 14-Апр-19, 19:27
	Даже приятно что у вас так пригорело. Держи еще прикольных проектов https://rocket.rs https://github.com/jwilm/alacritty https://github.com/sharkdp/bat https://github.com/tikv/tikv
	Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

	76. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноним (76), 14-Апр-19, 21:02
	Спасибо, пет-проектов у меня и своих хватает.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	99. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от GentooBoy (ok), 15-Апр-19, 00:38
	Приоткройте завесу тайны на каком ЯП?
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	34. "Выпуск языка программирования Rust 1.34"	+2 +/–
	Сообщение от Ordu (ok), 14-Апр-19, 14:10
	> Что говорят бенчмарки Rust vs. C++, какой язык более производительный и удобный в разработке? Бенчмарки тебе ничего не скажут. rust работает на том же уровне, что и C++, и абстракции использует схожие, а это значит, что в бенчмарках отличия будут в обе стороны и ничего не скажут осмысленного. Про удобство в разработке они тоже ничего не скажут тебе. Если вопрос интересен, то у тебя есть два способа исследовать его: 1. читать в интернете посты в блогах вида "я писал на C++ 20 лет, и решил попробовать rust" 2. писать на C++ 20 лет, а потом попробовать rust.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	46. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от хотел спросить (?), 14-Апр-19, 16:11
	почему вы сравнивате с плюсами, а не с С, если в расте нет классов? или я что-то пропустил?
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	55. "Выпуск языка программирования Rust 1.34"	+1 +/–
	Сообщение от Ordu (ok), 14-Апр-19, 16:50
	> почему вы сравнивате с плюсами, а не с С, если в расте > нет классов? > или я что-то пропустил? Во-первых, потому что выше вопрос был про C++, а не про C. Во-вторых, потому что если копнуть идею "нет классов", то она сведётся к тому, что в расте нет злых многоуровневых иерархий типов, но если мы начнём писать на C++ со злыми многоуровневыми иерархиями типов, то C++ перестанет быть конкурентом rust'у. Вызовы через vtable -- это довольно дорогостоящая операция по меркам языков типа C/C++/Rust. Для python'а -- это быстро, для C -- это тормозно. В C/C++/Rust'е принято, например, осуществлять доступ к полю структуры/класса посредством непосредственной разадресации. Это дело инкапсулируют часто в вызов метода, но таким образом, чтобы компилятор мог бы этот вызов заинлайнить. Но это невозможно в случае если вместо объекта у нас есть указатель на базовый класс в иерархии.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	65. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноня (?), 14-Апр-19, 18:42
	Ну потому что классов нет намеренно. Есть трейты и обобщения.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

9. "Выпуск языка программирования Rust 1.34"	–17 +/–
Сообщение от developer (??), 14-Апр-19, 12:25
Какая разница производительный он или удобный? читаем "развиваемого проектом Mozilla" - то есть с учетом падения доли лисо-браузера под удар ставиться и само развитие и поддержка ражавчины. Следовательно энтузиастам поковыряться вечером дома - зеленый свет, но как-то ассоциировать это перспективой и ставить на это уже перебор.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Выпуск языка программирования Rust 1.34"	+1 +/–
	Сообщение от username (??), 14-Апр-19, 12:29
	Да ладно, вон уже амазон ставку сделал на длительную поддержу. А вы все не стоит да ни к чему.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	18. "Выпуск языка программирования Rust 1.34"	+2 +/–
	Сообщение от zo0M (ok), 14-Апр-19, 13:01
	ох уж эта диванная аналитка от местных икспердов... /facepalm
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	23. "Выпуск языка программирования Rust 1.34"	+8 +/–
	Сообщение от Аноним (23), 14-Апр-19, 13:20
	> ставиться http://tsya.ru/
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	52. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от мурзилла (?), 14-Апр-19, 16:36
	не переживайте, мы зарабатываем не на браузере, а на пилежке инвесторских бабок. инвесторы как раз одобряют их выкидывание в бездонные ямы типа хруста, а браузер...браузер как-нибудь бесплатные любители пусть напишут. Дизайнер для очередного изменения положения деталей интерфейса тоже недорого, в общем.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	128. "Выпуск языка программирования Rust 1.34"	+1 +/–
	Сообщение от Аноним (124), 15-Апр-19, 11:13
	> инвесторы как раз одобряют их выкидывание в бездонные ямы типа хруста не суди по своему совку об остальном мире. если тут пилёж и выкидывание, то это не означает, что этим занимаются инвесторы.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

11. "Выпуск языка программирования Rust 1.34"	–1 +/–
Сообщение от scor (ok), 14-Апр-19, 12:30
А там уже можно хоть в каком-то виде делать вот такие штуки http://www.opennet.dev/openforum/vsluhforumID3/112498.html#37 или пока так и не осилили?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	32. "Выпуск языка программирования Rust 1.34"	+1 +/–
	Сообщение от Ordu (ok), 14-Апр-19, 14:03
	Нет, по-моему, ещё не осилили. Трейты для [T; N], реализуются макросами для всяких разных N от 1 до 32 (или типа того). То есть, я не заглядывал в этот библиотечный код уже год или два, но это видно в доках, плюс я думаю, я бы заметил в release notes, если бы что-то изменилось.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

12. "Выпуск языка программирования Rust 1.34"	–7 +/–
Сообщение от Аноним (12), 14-Апр-19, 12:52
"Для распространения библиотек, обеспечения сборки и управления зависимостями проектом развивается пакетный менеджер Cargo, позволяющий получить нужные для программы библиотеки в один клик" - оно что, GUIвое?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	14. "Выпуск языка программирования Rust 1.34"	+1 +/–
	Сообщение от zo0M (ok), 14-Апр-19, 12:58
	нет
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	20. "Выпуск языка программирования Rust 1.34"	+5 +/–
	Сообщение от Аноним (20), 14-Апр-19, 13:08
	коммент, когда хочешь обгадить новость, но не знаешь как
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

21. "Выпуск языка программирования Rust 1.34"	–5 +/–
Сообщение от Аноним (21), 14-Апр-19, 13:14
Эталонное ненужно, никакой совместимости с C/C++ или чем нибудь другим, даже в 1.0 не было union, только сейчас добавили атомики (в С11/C++11 были уже, а с расширениями еще раньше). Уже мертвый язык.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	27. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от YetAnotherOnanym (ok), 14-Апр-19, 13:44
	> никакой совместимости с C/C++ У них что, нули и единицы разные?
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	48. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от Аноним (21), 14-Апр-19, 16:24
	#include <stdlib.h> не сделаешь.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	66. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноня (?), 14-Апр-19, 18:47
	https://doc.rust-lang.org/book/ffi.html
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	82. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от Аноним (21), 14-Апр-19, 22:08
	С помощью этого нельзя сделать #include <stdlib.h>
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	89. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноня (?), 14-Апр-19, 22:49
	> С помощью этого нельзя сделать #include <stdlib.h> Назавите причину, по которой компилятор раста должен работать с препроцессором СИ? Как вы вообще себе это представляете? Я в недоумении
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	126. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от Аноним (126), 15-Апр-19, 11:05
	>> С помощью этого нельзя сделать #include <stdlib.h> > Назавите причину, по которой компилятор раста должен работать с препроцессором СИ? Повторное использование кода. > Как вы вообще себе это представляете? https://ru.wikipedia.org/wiki/MLton#NLFFI http://people.cs.uchicago.edu/~blume/papers/nlffi-entcs.pdf > Я в недоумении Сочувствую.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	150. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноня (?), 15-Апр-19, 19:53
	> Повторное использование кода. Берёте библиотеку на сях, заворачиваете её в rust обёртку и используете из своего кода. Можно использовать кодогенерацию. Делов-то на пару часов. А то, что вы предлагаете - это как бы зачем вообще?
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	158. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от KonstantinB (ok), 16-Апр-19, 10:51
	А еще с помощью этого нельзя сделать const leftPad = require('left-pad'). Беда, огорчение!
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	30. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от zo0M (ok), 14-Апр-19, 13:48
	проходя проходите
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	39. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноним84701 (ok), 14-Апр-19, 14:36
	>  даже в 1.0 не было union, Вообще-то, растовый enum - это вполне себе "tagged union". Только вот проверку тэга там частенько можно сделать в компайлтайме, в отличие от …
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	49. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноним (21), 14-Апр-19, 16:25
	А простой union они добавили просто так? Напоминаю что язык для системщины.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	60. "Выпуск языка программирования Rust 1.34"	+1 +/–
	Сообщение от Аноним84701 (ok), 14-Апр-19, 17:33
	> Напоминаю что язык для системщины. И что вас так шокирует? В асме нет никаких union, да и в си без них можно вполне обойтись. Unon -  всего лишь "сборник" возможных типов, для удобства (в довольно специфичных случаях) чтобы не пихать все в глобальное пространство имен. Напоминаю, что в ржавчине есть дженерики, dynamic-dispatch  и привод куска памяти к определенному типу (хоть и в ансейфе). И вообще, когда начинается пляска "я точно знаю, что в этом куске памяти вооот этот вот тип будет" -- это все в unsafe. ЗЫ: посмотрел -- оно действительно в ансейфе :) https://doc.rust-lang.org/reference/items/unions.html
	Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

	61. "Выпуск языка программирования Rust 1.34"	+1 +/–
	Сообщение от Junior frontend developer (?), 14-Апр-19, 17:53
	Простой union небезопасен и потому был исключен из дизайна. Вроде позже добавили как часть небезопасного надмножества языка. Аналогично и с ООП. Это набор ~15 различных фич разной нужности и безопасности. В rust добавили/добавляют только те, что безопасны и не зарекомендовали себя как плохие практики.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	72. "Выпуск языка программирования Rust 1.34"	+1 +/–
	Сообщение от Аноним (113), 14-Апр-19, 20:00
	А безопасность памяти тебе тоже не нужна?
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	83. "Выпуск языка программирования Rust 1.34"	+1 +/–
	Сообщение от Аноним (21), 14-Апр-19, 22:09
	А для этого нужно было городить новый язычек?
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	85. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Анонн (?), 14-Апр-19, 22:40
	> А для этого нужно было городить новый язычек? А как ещё можно встроить нужную для этого семантику? Нет безусловно можно было взять за основу си,вот только на выходе все равно получился бы ЯП, лишь местами и неудачным синтаксисом напоминающий си, но с другими парадигмами и иным подходом к разработке. Т.е. по сути тот же "новый язычок". И толку тогда, тянуть все костыли и подпорки?
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	100. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от Аноним (101), 15-Апр-19, 00:40
	В Си++ семантика владения вроде растовской реализуется простым введением библиотечных типов-меток и обучением компилятора как их понимать. Только оказалось, что 80% таких проверок можно реализовать даже без меток, а растовская семантика переусложнена до невозможности.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

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

	110. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноним (113), 15-Апр-19, 05:49
	А как ты в старо сделаешь, чтобы компилятор строго все проверял? Сделать-то можно, да только это уже все равно будет другой язык
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

40. "Выпуск языка программирования Rust 1.34"	–2 +/–
Сообщение от Аноним (40), 14-Апр-19, 14:40
Эталонное "не нужно": * нет нормального ООП, ведь в new age программерских сектах принято хаять ООП * крайне отвратительный пакетный менеджер. Нет предсобраных пакетов. Вместо этого это говно пересобирает всё это. Правда пересобирает довольно быстро, но это пока в зависимостях нет чего-нибудь тяжёлого. * предлагается ставить язык с какого-то говносайта путём curl | bash вместо использования пакетов дистрибутива. В дистрибутиве есть какие-то пакеты, испражнённые мамонтом, но пакеты раста ими не соберёшь: в коде по-видимому захардкожено, что некоторые фичи языка можно использовать только на найтли, а большинство пакетов как раз зависит от пакетов, зависящих от ночных фич. * пакет для Qt какая-то недоделанная альфа: >This is work in progress, so the API will significantly change in the future. Some methods are missing, and some are inconvenient to use. Some methods are unsafe even though they are not marked as unsafe.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	44. "Выпуск языка программирования Rust 1.34"	+2 +/–
	Сообщение от Ordu (ok), 14-Апр-19, 15:26
	> нет нормального ООП, ведь в new age программерских сектах принято хаять ООП Что ты называешь "нормальным" ООП? Как в java? Как в C++? Как в Haskell? Как в gtk? Какой из ООП нормален? ООП -- это не язык, ООП -- это подход к программированию. Тебе никто не запрещает в rust'е писать ООП программы. Так же как никто тебе не может запретить писать ООП код на C или на ассемблере. Но при этом rust даёт тебе dyn Trait и Deref/DerefMut, то есть тебе не нужно возиться с vtable или её аналогом вручную. > крайне отвратительный пакетный менеджер. Нет предсобраных пакетов. Вместо этого это говно пересобирает всё это. Правда пересобирает довольно быстро, но это пока в зависимостях нет чего-нибудь тяжёлого. То есть единственная претензия к пакетному менагеру, что он не умеет бинарные пакеты таскать? По-моему, это недостаточная причина для того, чтобы характеризовать пакетный менагер как "крайне отвратительный". > предлагается ставить язык с какого-то говносайта путём curl | bash вместо использования пакетов дистрибутива. В дистрибутиве есть какие-то пакеты, испражнённые мамонтом, но пакеты раста ими не соберёшь: в коде по-видимому захардкожено, что некоторые фичи языка можно использовать только на найтли, а большинство пакетов как раз зависит от пакетов, зависящих от ночных фич. Да, это так. Проблема в том, что в nightly есть куча фишек, которые ещё не стабилизированы, но вкусны настолько, что растоманы не могут пройти мимо. Когда стабилизируется async/await, я подозреваю, завязки на nightly станет меньше. С дистрибутивами же, проблема в том, что использование системного пакетного менагера для установки rust'а и его библиотек, довольно затруднительно. Особенно если речь идёт о nightly. Можно, но сложно. Придётся разобрать rustup.sh на части, и написать реимплементацию к нему, каким-то образом отобразив на системный пакетный меганер его способность держать много toolchain'ов в системе одновременно (а их может быть много: количество версий rustc помножить на количество платформ и на количество архитектур), переключаясь между ними по любой прихоти. То есть тут не удастся тупо написать .deb, придётся строить целую инфраструктуру для rust'а и его библиотек. В gentoo, например, есть база для такой архитектуры, тут есть eselect, но eselect -- это не то, что нужно разработчику: я же не буду делать sudo eselect, каждый раз, когда я решаю пересобрать свой проект под другую архитектуру? И это проблема, которую mozilla не может решить. Её могут решить лишь индивидуальные дистрибутивы, решая задачи решаемые rustup'ом так, как они считают нужным их решать. Они не считают нужным. > пакет для Qt какая-то недоделанная альфа Оу, в cargo.io очень много недоделанных альф. Местами настолько недоделанных, что встаёт вопрос о том, что вообще сделано. Я сейчас ваяю обёртку над ffmpeg, потому что то, что есть в cargo.io -- это, по-сути, автосгенерённые bind'ы, то есть C'шный API, со всеми его проблемами, типа необходимости знать этот API и что под ним прячется, как свои пять пальцев, потому что ошибка использования этого API приведёт к сегфолту и никакой компилятор не защитит от этого. Чтобы это победить, надо, как минимум, прописать в API все лайфтаймы, а как максимум, скажем, сделать невозможным некоторые изменения AVFormatContext в процессе записи туда, потому что эти изменения могут привести к тому, что следующий вызов функции из ffmpeg API внезапно приведёт к сегфолту. То есть, если уж делать бинды, то эти бинды должны давать гарантии, которые даёт rust, а это требует глубокого знания ffmpeg и изложения этого знания на rust'е. А это время, которого всегда не хватает.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	47. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от хотел спросить (?), 14-Апр-19, 16:18
	> тебе не может запретить писать ООП код на C или на ассемблере Можно пожайлуста реализацию полиморфизама на C? Или инкапсуляции?
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	53. "Выпуск языка программирования Rust 1.34"	+2 +/–
	Сообщение от Ordu (ok), 14-Апр-19, 16:44
	>> тебе не может запретить писать ООП код на C или на ассемблере > Можно пожайлуста реализацию полиморфизама на C? Или инкапсуляции? В качестве примера инкапсуляции в C, ты можешь взять любую функцию любого C'шного API. Или, если ты под инкапсуляцией понимаешь сокрытие членов структуры так, чтобы клиентский код не имел бы к ним доступа, даже если захочет, то это делается очень просто: // myobject.h struct MyObject; struct MyObject* new_myobject(); void myobject_dance(struct MyObject*); void myobject_die(struct MyObject*); Ну и так далее. А насчёт полиморфизма... Ты, как я понимаю, веришь в то, что ООП -- это "инкапсуляция, наследование, полиморфизм"? Алан Кай же рассказывал, что это бред сивой кобылы и считать это определением ООП, это значит не уважать его копирайты на аббревиатуру ООП. Ну, то есть, я утрирую несколько, но суть примерно такая. В точности ты можешь почитать здесь: http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay... Требовать от ООП программы полиморфизма, это примерно то же самое, что требовать от ООП программы быть написанной на C++. Типа если не C++, значит не ООП. Полиморфизм по типу -- это попытка решить задачи диспатча в ООП статически. Без всякого полиморфизма ты можешь решать их динамически, это хуже только в том смысле, что иногда приводит к накладным расходам во время выполнения. Но это никак не противоречит ООП идеологически.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	107. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от хотел спросить (?), 15-Апр-19, 03:33
	>[оверквотинг удален] > уважать его копирайты на аббревиатуру ООП. Ну, то есть, я утрирую > несколько, но суть примерно такая. В точности ты можешь почитать здесь: > http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay... > Требовать от ООП программы полиморфизма, это примерно то же самое, что требовать > от ООП программы быть написанной на C++. Типа если не C++, > значит не ООП. Полиморфизм по типу -- это попытка решить задачи > диспатча в ООП статически. Без всякого полиморфизма ты можешь решать их > динамически, это хуже только в том смысле, что иногда приводит к > накладным расходам во время выполнения. Но это никак не противоречит ООП > идеологически. Что-то я не вижу тут инкапсуляции. Обрисуйте ход ваших мыслей. Я как-то в упор не понимю где тут что скрыто и к чему невозможно получить доступ извне (без чтения памяти процесса или какой-нибудь рефлексии). И где здесь можно получить доступ для ограниченного участка кода, которому принадлежит эта логика. --- ООП -- это "инкапсуляция, наследование, полиморфизм"? Нет я так не думаю... Я знаю, что эти 3 пункта как и многие другие дают определенный набор инструментов для реализации объектов и их взаимодействия. И мне как бы "накласть" на ваших сивых и бурых кобыл. И уж тем более "не сотвори себе кумира". Я смотрю в корень! При оперировании абстрактными сущностями в попытках декомпозиции реального мира - нужна виртуальность функций? - нужна... Нужно полиморфное поведение? - нужно. Нужно наследование (и реализация интефейсов туда же) - нужно. Нужны CAST операторы - офигеть как нужны (например один из вариантов реализаций адаптера). > Требовать от ООП программы полиморфизма, это примерно то же самое, что требовать от ООП программы быть написанной на C++. C++, C#, Java, Object Pascal (да да на нем еще пишут много софта, лично видел). Ну и мне не дадут соврать ребята, кто знаком с другими языками. Сдается мне что С++ для вас это разновидность личной психологической драмы ))) Но меня сюда не приплетайте, я считаю, что данная парадигма ООП при всей ее неидеальности абсолютно заслуженно получила такую популярность. И речь не о плюсах. > Без всякого полиморфизма ты можешь решать их динамически Во первых все равно динамический диспатч подразумевает полимофное поведение. Вот только в С++ и ему подобных языках это полморфное поведение объектов (моделей реального мира). А полиморфизм чего будет в необъектных языках? Сомнительная шоколадка... Во-вторых, а если я намеренно не хочу динамический диспатч? И считаю что его применение следует допускать только по мере крайней необходимости. Чтобы например банально не страдала самодокументируемость кода... и не только. > Но это никак не противоречит ООП идеологически. Вот именно.. всё красиво (но это неточно) в теории.. на бумаге. А я говорю о практическом применении. Я присматривался мельком к расту. И как замена С для реальных, практических задач - думаю у него есть все шансы. Как замена ООП языков типа плюсов, шарпы, или джавы - мое личное мнение - хрена с два.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	138. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от Ordu (ok), 15-Апр-19, 13:34
	> Что-то я не вижу тут инкапсуляции. Обрисуйте ход ваших мыслей. > Я как-то в упор не понимю где тут что скрыто и к чему невозможно получить доступ извне (без чтения памяти процесса или какой-нибудь рефлексии). И где здесь можно получить доступ для ограниченного участка кода, которому принадлежит эта логика. Там сокрыты все поля структуры MyObject. Ты даже не знаешь как они называются. Ты даже не замечаешь их существования, судя по твоей реакции непонимания. > Я смотрю в корень! При оперировании абстрактными сущностями в попытках декомпозиции реального мира - нужна виртуальность функций? - нужна... "Декомпозиция мира"... Забей на эти симуляции. Начни думать алгоритмически. Виртуальность функций и динамическая типизация тебе нужна тогда, когда ты не научился мыслить вне ООП парадигмы. Но, как бы это сказать, это дело вкуса. Ты любишь динамическую типизацию? Тогда тебе в раст лучше не соваться. Ты можешь тут собрать что-нибудь в стиле Vec<Box<dyn MyTrait>>, и потом дёргать методы этих трейтов, это не сложно. Но если ты мыслишь в стиле ООП, и по твоему любая типизация должна быть динамической, то тебе сюда не надо. Так же как тебе не стоит соваться в C. В C++ может быть, но лучше тоже не стоит. Твой выбор Java, Python, js, ruby, короче языки которые действительно дают динамическую типизацию, а не статическую плюс ещё немного, на случай когда в чисто статическую влезть не удаётся. > Как замена ООП языков типа плюсов, шарпы, или джавы - мое личное мнение - хрена с два. Во-во. Я о том же. Шарпы, жабы -- это удел ООП, тормозное нечто, в большинстве случаев ещё и интерпретируемое. rust'у нужна скорость.
	Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

	165. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от хотел спросить (?), 18-Апр-19, 12:11
	> Ты любишь динамическую типизацию? Я чуть ли не прямым текстом написал, что нет. Вот о чем мы тогда разговариваем? -- По какой причине у нас нет доступа к филдам MyObject?
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	166. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Ordu (ok), 18-Апр-19, 12:32
	>> Ты любишь динамическую типизацию? > Я чуть ли не прямым текстом написал, что нет. > Вот о чем мы тогда разговариваем? Но динамический диспатч -- это и есть динамическая типизация. У тебя есть Parent*, который, по-сути, объект неопределённого типа, конкретно что это за тип выясняется в рантайме. > По какой причине у нас нет доступа к филдам MyObject? Потому что у нас нет их декларации.
	Ответить | Правка | ^ к родителю #165 | Наверх | Cообщить модератору

	167. "Выпуск языка программирования Rust 1.34"	+1 +/–
	Сообщение от Junior frontend developer (?), 18-Апр-19, 19:03
	> Но динамический диспатч -- это и есть динамическая типизация. Dynamic dispatch — это средство для более обобщенного интерфейс-ориентированного программирования. В динамической типизации интерфейсов как понятия нет вообще.
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	168. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от хотел спросить (?), 18-Апр-19, 22:30
	> Но динамический диспатч -- это и есть динамическая типизация. не-не-не и я не говорил, что я за динамический диспатч или за динамические языки.. текст сверху имеется - можно перечитать > Потому что у нас нет их декларации. а как насчет типизации и самодокументрования кода? не получается ли, что решая одну проблему, создается другая?
	Ответить | Правка | ^ к родителю #166 | Наверх | Cообщить модератору

	169. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Ordu (ok), 18-Апр-19, 22:52
	>> Но динамический диспатч -- это и есть динамическая типизация. > не-не-не > и я не говорил, что я за динамический диспатч или за динамические > языки.. > текст сверху имеется - можно перечитать А, простите. Ну дык тогда rust самое то, что нужно вам. Там динамический диспатч возможен, можно даже сложные иерархии типов собирать, но бойлерплейта придётся писать много. Но если это надо раз в десять лет, то можно и потерпеть. >> Потому что у нас нет их декларации. > а как насчет типизации и самодокументрования кода? Единственное неудобство от такого подхода -- это то, что теперь мы не знаем размера struct MyObject, не можем выделить её на стеке, не можем передать в функцию по значению, не можем создать массив из struct MyObject, нам придётся работать исключительно с указателями на MyObject. А насчёт самодокументирования, дык это же инкапсуляция. Мы инкапсулируем внутреннюю реализацию, в частности поля этой структуры, а это значит что этим полям не место в документации на API. Она может быть в документации для разработчиков нашего API, но они имеют доступ к myobject.c, или к myobject.priv.h, там есть полная декларация структуры, там может быть и документация на неё. > не получается ли, что решая одну проблему, создается другая? Ядро успешно решает эти проблемы. Я тебе очень рекомендую поковыряться там, и попробовать сделать что-нибудь, что не предусмотрено, ты очень быстро упрёшся в подобные штуки, типа указатель на структуру ты можешь объявить, и даже получить, но прямого доступа к полям у тебя нет, есть некоторые "методы", которые позволяют работать со структурой, но их список чётко задан в .h файле. Ты можешь взять и скопировать определение структуры в свой сорец, и ещё код который с ней работает нужным образом, но это не скомпилируется, потому что тот код дёргает какой-то API, который не выставлен наружу из ядра, и чтобы его получить надо заинклюдить какой-то приватный .h (если он есть такой .h), но чтобы он заинклюдился как надо, надо задекларировать правильные значения каких-то #define'ов, и... Твой код превращается в такую мешанину, что с первого взгляда видно, что тут что-то не то намешано. Попробуй, это приключение, оно стоит того. Начинаешь понимать, что такое инкапсуляция.
	Ответить | Правка | ^ к родителю #168 | Наверх | Cообщить модератору

	170. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от хотел спросить (?), 19-Апр-19, 10:52
	> Единственное неудобство от такого подхода -- это то, что теперь мы не знаем размера struct MyObject, не можем выделить её на стеке, не можем передать в функцию по значению, не можем создать массив из struct MyObject, нам придётся работать исключительно с указателями на MyObject. > А насчёт самодокументирования, дык это же инкапсуляция. Мы инкапсулируем внутреннюю реализацию, в частности поля этой структуры, а это значит что этим полям не место в документации на API. Она может быть в документации для разработчиков нашего API, но они имеют доступ к myobject.c, или к myobject.priv.h, там есть полная декларация структуры, там может быть и документация на неё. Чем это проще/лучше, чем то что мы имеем в C++, C#, Java? Для меня этот подоход менее привлекателен, менее прозрачен и больше отвлекает. Более того он диктует мне файловую организацию, что например полностью отсутствует в C# или в Java. А это не менее проблемный момент, чем "как что-нибудь назвать".
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

	171. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Ordu (ok), 19-Апр-19, 12:55
	> Чем это проще/лучше, чем то что мы имеем в C++, C#, Java? Почему это должно быть проще или лучше?
	Ответить | Правка | ^ к родителю #170 | Наверх | Cообщить модератору

	179. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от хотел спросить (?), 27-Апр-19, 04:58
	>> Чем это проще/лучше, чем то что мы имеем в C++, C#, Java? > Почему это должно быть проще или лучше? Странный, может даже глупый вопрос.
	Ответить | Правка | ^ к родителю #171 | Наверх | Cообщить модератору

	181. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Ordu (ok), 27-Апр-19, 06:53
	>>> Чем это проще/лучше, чем то что мы имеем в C++, C#, Java? >> Почему это должно быть проще или лучше? > Странный, может даже глупый вопрос. Нисколько не странный и не глупый, если ты дашь себе труд освежить в памяти беседу целиком. Точнее даже не всю беседу, а самое её начало. Ты попросил примера инкапсуляции в C. Я тебе его привёл. Мы потом обсудили и пришли к выводу, что это действительно инкапсуляция. (Мы ведь пришли?) А теперь ты пытаешься произвести тактический манёвр "смещение темы обсуждения", обсуждать не возможность инкапсуляции, а удобство этой инкапсуляции для тебя лично или для какого-то класса задач. Я сопротивляюсь. Я ничего не имею против смещения темы, но если оно происходит явно и осознанно, а не исподтишка и на неосознаваемых рефлексах. Обсуждение удобства инкапсуляции в C -- это другой разговор. Для этого надо вернутся назад, понять что мы сравниваем уже не возможности языков, а скорее заточенность на те или иные задачи. А если мы начинаем говорить о заточенности, то тут выясняется, что инкапсуляция и её удобство -- это не единственный фактор, по которому язык следует оценивать. C в разы быстрее C# и Java. На C можно писать хоть под восьмибитную avr'ку, хоть под Ryzen. C может использовать возможности железа практически напрямую, в то время как C# с Java всегда вынуждены полагаться на то, что рантайм и библиотеки это каким-то образом делают, и что они смогут применить свои умения в данном случае. C++ не столь отличается от C, как Java/C#, но и здесь у C есть свои преимущества. Скорость компиляции, простота языка (проще найти обезьяну, которая будет набирать код), документированный ABI, обилие компиляторов и простота написания своего компилятора. Что из этого важнее? А мы не можем ответить на этот вопрос, до тех пор, пока мы не определимся с тем, зачем нам нужен язык. Что мы собираемся на нём писать, какие требования к скорости/потреблению ресурсов/надёжности/безопасности, какой бюджет у нас есть.
	Ответить | Правка | ^ к родителю #179 | Наверх | Cообщить модератору

	173. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Junior frontend developer (?), 21-Апр-19, 19:20
	> А, простите. Ну дык тогда rust самое то, что нужно вам. Там > динамический диспатч возможен, можно даже сложные иерархии типов собирать, но бойлерплейта > придётся писать много. Но если это надо раз в десять лет, > то можно и потерпеть. Rust позволяет куда более гибко организовывать горизонтальную композицию, вместо вертикальных неповоротливых иерархий.
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

	180. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от хотел спросить (?), 27-Апр-19, 04:59
	>> А, простите. Ну дык тогда rust самое то, что нужно вам. Там >> динамический диспатч возможен, можно даже сложные иерархии типов собирать, но бойлерплейта >> придётся писать много. Но если это надо раз в десять лет, >> то можно и потерпеть. > Rust позволяет куда более гибко организовывать горизонтальную композицию, вместо вертикальных > неповоротливых иерархий. Это типа отношение has? О какой "горизонтальной композиции" идет речь, и чем это лучше упомянутых ранее языков?
	Ответить | Правка | ^ к родителю #173 | Наверх | Cообщить модератору

	182. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Ordu (ok), 27-Апр-19, 08:26
	> Это типа отношение has? > О какой "горизонтальной композиции" идет речь, И отношение типа has тоже. Но мерками ООП невозможно оценивать не-ООП подход к программированию. Как ты опишешь монад в ООП терминах? Монады можно использовать в ООП программе, но нельзя описать их в ООП терминах. Раст -- это статическая типизация, это параметризованные типы, это ближе к Ocaml, Haskell и C++, чем к Java и C#. Я тут читал статью-туториал про комбинаторы парсеров[1] -- вынос мозга. Правда в процессе развития событий в туториале rust'у стало плохо, когда дело дошло до парсинга атрибутов со значениями, а когда парсинг атрибутов был объединён с парсингом тега, то rust'у просто сорвало планку, потому что создаваемые рекурсивные типы оказались слишком безумны в своей вложенности, и автору пришлось переходить к Box<dyn Trait>, для того чтобы ценой некоторых (несущественных в том случае) потерь производительности в рантайме обойти ограничения компилятора как по памяти, так и по времени компиляции. Понятно, что парсер можно написать классически на конечном автомате, и не нужно никаких виртуальных вызовов для этого, но я не к тому, что парсеры надо писать именно так, а в ответ на вопрос "что такое горизонтальная композиция". В туториале пример тому. Но если это действительно интересно, я бы рекомендовал повтыкать в ocaml или в haskell. Или в rust, но rust насоздаёт тебе дополнительных проблем изучения, которые напрямую не относятся к горизонтальной композиции, типа лайфтаймов с borrowing'ом. Или в "современный" C++[2]. И я в целом рекомендую это сделать, даже если это не очень интересно: знать другие подходы к программированию полезно, потому что это даёт возможность думать о создаваемом коде несколько иначе. [1] https://bodil.lol/parser-combinators/ [2] https://github.com/rigtorp/awesome-modern-cpp > и чем это лучше упомянутых ранее языков? Больше статических гарантий относительно кода. Работает быстрее. Гибче, то есть не прибито гвоздями к ООП и даёт больше выразительных возможностей, для описания своего замысла.
	Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

	183. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от хотел спросить (?), 28-Апр-19, 13:58
	>[оверквотинг удален] > не относятся к горизонтальной композиции, типа лайфтаймов с borrowing'ом. Или в > "современный" C++[2]. И я в целом рекомендую это сделать, даже если > это не очень интересно: знать другие подходы к программированию полезно, потому > что это даёт возможность думать о создаваемом коде несколько иначе. > [1] https://bodil.lol/parser-combinators/ > [2] https://github.com/rigtorp/awesome-modern-cpp >> и чем это лучше упомянутых ранее языков? > Больше статических гарантий относительно кода. Работает быстрее. Гибче, то есть не прибито > гвоздями к ООП и даёт больше выразительных возможностей, для описания своего > замысла. Я так и не увидел нечто, что делает это "гибче". Для кого гибче? Для меня? - нет. Есть какие-то объективные критерии? - нет. Вот например накой черт мне монад не в функциональных языках?
	Ответить | Правка | ^ к родителю #182 | Наверх | Cообщить модератору

	184. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Ordu (ok), 29-Апр-19, 01:26
	> Я так и не увидел нечто, что делает это "гибче". Это не удивительно. Именно поэтому я рекомендую взять Haskell и изучить его. Я когда-то слушал про то, что ассемблер позволяет лучше приспособиться к архитектуре железа, кивал головой, но не понимал о чём речь. Я задавал вопросы и всё равно не понимал. Только когда я сам начал писать на асме, я понял о чём речь. Здесь примерно то же самое. Пока ты думаешь о написании программ в терминах ООП, ты не увидишь зачем тебе нужны функциональные приёмы программирования, потому что твоя голова не умеет эти приёмы использовать. Она умеет использовать только ООП приёмы. И поэтому функциональные приёмы для тебя выглядят бесполезными.
	Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

	185. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от хотел спросить (?), 01-Май-19, 03:09
	>> Я так и не увидел нечто, что делает это "гибче". > Это не удивительно. Именно поэтому я рекомендую взять Haskell и изучить его. > Я когда-то слушал про то, что ассемблер позволяет лучше приспособиться к > архитектуре железа, кивал головой, но не понимал о чём речь. Я > задавал вопросы и всё равно не понимал. Только когда я сам > начал писать на асме, я понял о чём речь. Здесь примерно > то же самое. Пока ты думаешь о написании программ в терминах > ООП, ты не увидишь зачем тебе нужны функциональные приёмы программирования, потому > что твоя голова не умеет эти приёмы использовать. Она умеет использовать > только ООП приёмы. И поэтому функциональные приёмы для тебя выглядят бесполезными. Я не писал на ассемблере, но я знаю о чем это, просто не знаю большинства инструкций. Т.е. реально опыта нет.. Однако я прекрасно понимаю почему он лучше для работы с железом. Но не думаю что Си или C++ с ассемблерными вставками чем-то хуже. Сказать того же о функциональных языках я не могу. > потому что твоя голова не умеет эти приёмы использовать это так, но если я не умею их использовать, это еще не значит, что они полезны/проще/лучше и т.д. я точно знаю, что ООП стройно (почти) ложится на окружающую действительность по-крайней мере так как мыслит об окружающей действительности бизнес и большинство людей (утрирую: на фирме есть автомобиль и у него есть бензобак, а в нем есть топливо, которое является статьей расходов... и меня мало интересует функция "жрать бензин" или "посчитать расход" в контексте "бензобак" или "предприятие" (ведь очевидно что это разные функции), меня интересует объект "расходы на топливо", который живет в башке финдиректора и директора ГСМ) не то чтобы пример хороший, но дает понять что правильный ООП ближе к реальности (воспринимаемой людьми) и поэтому я не хочу описывать бизнес и окружающую действительность в математических терминах... Я не сторонник Макса Тегмарка.
	Ответить | Правка | ^ к родителю #184 | Наверх | Cообщить модератору

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

	187. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от хотел спросить (?), 02-Май-19, 02:04
	> Не значит. Точно так же это не значит, что они хуже. Просто > для тебя это закрытая дверь. Я и не говорил что хуже (хотя я не вижу применения в реальном секторе для ФЯ). Математические вычисления - пожалуйста, алгоритмы, обработка процессов - само то. Но декомпозиция предметной области функциями - ад. Если ты не понимаешь этого, то с чего ты решил что ООП для тебя не закрытая? > Да я слышал об этом. Но ты веришь, что это хорошо, только > потому, что не знаешь никакого другого подхода к програмированию кроме наиболее > очевидного для большинства людей. За все время моей работы, сложнее всего было писать код, который прочитает любая обезьяна. А у тебя это не в приоритете. А вот для меня с точностью до наоборот - это прям главное (и я знаю почему). Если ООП хоть на 10% улучшит этот показатель, то я буду поддерживать эту парадигму. И не то что верю.. нет.. Я просто точно это знаю. Давай так.. ООП помогает мне размышлять при проектировании "ассоциативно". Есть некий аспект, я его реализую объектно и все штуки запихиваю "где-то там" (ассоциация в моей голове). Ты знаком с ФЯ, как он помогает мне думать ассоциативно? Насколько я себе представляют - почти никак. Получается, чтобы писать на подобных языках, я должен стать чуть большим математиком и породить новые абстракции у себя в голове, чтобы точно также эффективно писать на ФЯ. А что будет с теми, кто будет устраиваться ко мне на работу? Их мне тоже "ломать"? Притом если я их "ломаю" для корректной реализации ООП, то это проще, потому что интуитивнее. Таким образом для ООП мне проще готовить кадры, мне проще писать почти безбажный код, мне проще устанавливать правила разработки, которые понимаются интуитивно всеми членами команды. Бизнес не будет ждать тех, кто прям писает кипятком от своеобразного математического подхода в разработке. И мое личное мнение, что в том виде, в каком это сейчас существует, оно и останется на около-научных задворках. И поэтому мне абсолютно неинтересна эта сфера, поэтому я и не рискую использовать ее и не инвестирую туда время и деньги. Возможно когда-нибудь, когда ФЯ станут ближе к образу мышления людей (или наоборот образ мышления) на порядок, то мы еще вернемся к этому вопросу и будем обсуждать очередную версию какого-нибудь "торта". Но а пока не впечатляет. Как-то так...
	Ответить | Правка | ^ к родителю #186 | Наверх | Cообщить модератору

	188. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Ordu (ok), 02-Май-19, 08:07
	>> Не значит. Точно так же это не значит, что они хуже. Просто >> для тебя это закрытая дверь. > Я и не говорил что хуже (хотя я не вижу применения в > реальном секторе для ФЯ). Как ты можешь видеть или не видеть, если ты не понимаешь, что такое ФЯ? Естественно, ты не видишь применения в "реальном секторе", потому что ты вообще никаких применений не видишь, потому что не владеешь ФЯ. > Давай так.. ООП помогает мне размышлять при проектировании "ассоциативно". Откуда ты знаешь помогает тебе ООП или мешает, если ты не пробовал иначе?
	Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

	189. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от хотел спросить (?), 02-Май-19, 10:13
	>[оверквотинг удален] >>> для тебя это закрытая дверь. >> Я и не говорил что хуже (хотя я не вижу применения в >> реальном секторе для ФЯ). > Как ты можешь видеть или не видеть, если ты не понимаешь, что > такое ФЯ? Естественно, ты не видишь применения в "реальном секторе", потому > что ты вообще никаких применений не видишь, потому что не владеешь > ФЯ. >> Давай так.. ООП помогает мне размышлять при проектировании "ассоциативно". > Откуда ты знаешь помогает тебе ООП или мешает, если ты не пробовал > иначе? ясно...
	Ответить | Правка | ^ к родителю #188 | Наверх | Cообщить модератору

	190. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Ordu (ok), 02-Май-19, 10:53
	> ясно... Нет, не ясно. Если тебе кажется, что тебе стало что-то понятно, то это иллюзия понимания. Есть вещи, которые можно понять только через практику, и программирование -- одна из таких вещей.
	Ответить | Правка | ^ к родителю #189 | Наверх | Cообщить модератору

	191. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от хотел спросить (?), 02-Май-19, 16:24
	>> ясно... > Нет, не ясно. Если тебе кажется, что тебе стало что-то понятно, то > это иллюзия понимания. Есть вещи, которые можно понять только через практику, > и программирование -- одна из таких вещей. Я имел ввиду, что ты пургу несешь. И с последним сообщением было совсем мимо. Настолько что нечего тут больше обсуждать.
	Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

	58. "Выпуск языка программирования Rust 1.34"	+2 +/–
	Сообщение от Аноним (57), 14-Апр-19, 17:13
	> Или инкапсуляции? Вот в этом месте растофанатикам лучше бы молчать в тряпочку.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	67. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноня (?), 14-Апр-19, 19:00
	https://doc.rust-lang.org/stable/book/ch17-01-what-is-oo.html
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	125. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Челодой моловек (?), 15-Апр-19, 11:03
	Я бы посмотрел в сторону GObject, например вот здесь: https://developer.gnome.org/gobject/stable/howto-gobject-met... Это что касается полиморфизма Или вот что касается инкапсуляции: https://github.com/GNOME/glib/blob/14e90e34a432cc3b11115aa8f... здесь они объявляют паблик структуру struct _GArray {   gchar *data;   guint len; }; а вот приватная структура в https://github.com/GNOME/glib/blob/14e90e34a432cc3b11115aa8f...: struct _GRealArray {   guint8 *data;   guint   len;   guint   alloc;   guint   elt_size;   guint   zero_terminated : 1;   guint   clear : 1;   gatomicrefcount ref_count;   GDestroyNotify clear_func; }; т.е. снаружи доступно только два поля, остальные  - закрыты Еще вот здесь наверняка можно найти много интересного (о том как запилить ООП на Си самостоятельно): https://www.cs.rit.edu/~ats/books/ooc.pdf
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	54. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноним (40), 14-Апр-19, 16:47
	> Что ты называешь "нормальным" ООП? Как в java? Как в C++? Как > в Haskell? Как в gtk? Какой из ООП нормален? ООП с наследованием, где методы и свойства наследуются автоматически. > ООП -- это не язык, ООП -- это подход к программированию. Тебе > никто не запрещает в rust'е писать ООП программы. Так же как > никто тебе не может запретить писать ООП код на C ил > на ассемблере. Но при этом rust даёт тебе dyn Trait и > Deref/DerefMut, то есть тебе не нужно возиться с vtable или её > аналогом вручную. Нет. ООП - это не столько подход, сколько средства для его поддержки, встроенные в язык. Иначе выяснится, что посоны то и не знали, что используют ООП тогда, когда и выражения такого не было. ООП в низкоуровневых языках - это всего лишь синтаксический сахар. > То есть единственная претензия к пакетному менагеру, что он не умеет бинарные > пакеты таскать? По-моему, это недостаточная причина для того, чтобы характеризовать пакетный > менагер как "крайне отвратительный". А по-моему - достаточная. Потому что я не гентушник, свой комп на помойке нашёл, и тратить своё время на сборку всякого мусора, которое понатаскали авторы зависимостей в свои библиотеки мне совершенно нет никакого желания, а некоторые вещи у меня на компе вообще не соберутся, выжрав всю оперативу. Современный язык должен уметь в бинарные пакеты-модули. Без исходника, без многочасовой сборки. При этом линарные пакеты должны быть обязательно подписаны приватным ключём автора. >> предлагается ставить язык с какого-то говносайта путём curl | bash вместо использования пакетов дистрибутива. В дистрибутиве есть какие-то пакеты, испражнённые мамонтом, но пакеты раста ими не соберёшь: в коде по-видимому захардкожено, что некоторые фичи языка можно использовать только на найтли, а большинство пакетов как раз зависит от пакетов, зависящих от ночных фич. > Да, это так. Проблема в том, что в nightly есть куча фишек, которые ещё не стабилизированы, но вкусны настолько, что растоманы не могут пройти мимо. >С дистрибутивами же, проблема в том, что использование системного пакетного менагера для установки rust'а и его библиотек, довольно затруднительно. Особенно если речь идёт о nightly. Можно, но сложно. Придётся разобрать rustup.sh на части, и написать реимплементацию к нему, каким-то образом отобразив на системный пакетный меганер его способность держать много toolchain'ов в системе одновременно (а их может быть много: количество версий rustc помножить на количество платформ и на количество архитектур), переключаясь между ними по любой прихоти. > То есть тут не удастся тупо написать .deb, придётся строить целую инфраструктуру для rust'а и его библиотек. В gentoo, например, есть база для такой архитектуры, тут есть eselect, но eselect -- это не то, что нужно разработчику: я же не буду делать sudo eselect, каждый раз, когда я решаю пересобрать свой проект под другую архитектуру? > И это проблема, которую mozilla не может решить. Её могут решить лишь индивидуальные дистрибутивы, решая задачи решаемые rustup'ом так, как они считают нужным их решать. Они не считают нужным. ИМХО: * сделать пакеты не так уж и трудно. У дебиана конечно просто отвратительный инструментарий для пакетирования, но есть на ГХ один репозиторий с лучшим инструментарием, который дёргается из питона, а не из баша. * различные версии лежат в различных папках, так напр. в дебиане с JVM сделано. Если есть код, помещающий 1 компилятор в одну папку, почти ничего не стоит его модифицировать так, чтобы он в название папки включил версию. Но по-моему смысла нет никакого - в случае  нестабильных версий последняя версия всегда есть наилучшая версия: в ней пофикшены все регрессии, которые смогли пофиксить. Почему они вообще держат тучу тулчейнов, вместо того чтобы держать llvm-фронтэнд, я не понимаю.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	59. "Выпуск языка программирования Rust 1.34"	+2 +/–
	Сообщение от Ordu (ok), 14-Апр-19, 17:19
	>> Что ты называешь "нормальным" ООП? Как в java? Как в C++? Как >> в Haskell? Как в gtk? Какой из ООП нормален? > ООП с наследованием, где методы и свойства наследуются автоматически. Deref/DerefMut тебе в помощь. > ООП в низкоуровневых языках - это всего лишь синтаксический сахар. Дайте мне определение синтаксического сахара. Всё это синтаксический сахар. asm -- это синтаксический сахар над бинарным представлением машинного кода, позволяющий не считать адреса и смещения вручную. Python -- это синтаксический сахар над интерпретатором, позволяющий дёргать те или иные функции интерпретатора. >> То есть единственная претензия к пакетному менагеру, что он не умеет бинарные >> пакеты таскать? По-моему, это недостаточная причина для того, чтобы характеризовать пакетный >> менагер как "крайне отвратительный". > А по-моему - достаточная. Потому что я не гентушник, свой комп на > помойке нашёл, и тратить своё время на сборку всякого мусора, которое > понатаскали авторы зависимостей в свои библиотеки мне совершенно нет никакого желания, > а некоторые вещи у меня на компе вообще не соберутся, выжрав > всю оперативу. Если ты нашёл свой комп на помойке, то что ты вообще делаешь в разработке ПО? Не, ну реально. Тут вполне нормально и регулярно приходится пересобирать половину системы только для того, чтобы иметь отладочную информацию к ней, и иметь возможность протрейсить выполнение программы внутрь библиотеки, чтобы понять почему оттуда вылетает сегфолт. Я пользуюсь генту, потому что тут без проблем можно отладочную информацию складывать рядышком с библиотеками и бинарями и подгружать её по мере необходимости, если я нечаянно закопался в какую-то библиотеку, про которую впервые слышу. Если бы этого не было, я бы давно забил на всё и вернулся бы в слакварь устанавливать программы при помощи make install. > Современный язык должен уметь в бинарные пакеты-модули. Без исходника, > без многочасовой сборки. При этом линарные пакеты должны быть обязательно подписаны > приватным ключём автора. А, ты о том, чтобы _пользоваться_ компьютером, быть пользователем и ставить программы себе в систему? Не о том чтобы разрабатывать? В задачи cargo не входит быть системным пакетным менагером. Чтобы устанавливать программы тебе следует пользоваться apt или что у тебя там стоит. То есть cargo -- это просто другой инструмент, если он попадает в класс пакетных менагеров, это не значит, что он задуман как замена для apt или emerge. > * сделать пакеты не так уж и трудно. У дебиана конечно просто > отвратительный инструментарий для пакетирования, но есть на ГХ один репозиторий с > лучшим инструментарием, который дёргается из питона, а не из баша. Может быть и не трудно. Я не готов вступать в дискуссию о смысле слова "трудно". > Но по-моему смысла нет никакого - в случае  нестабильных версий последняя версия всегда есть наилучшая версия: в ней пофикшены все регрессии, которые смогли пофиксить. В случае rust'а -- это не так. Nightly, beta и stable сосуществуют. Фиксы идут во все три ветки. Stable лучше чем nightly в плане стабильности и надёжности. Более того, ты можешь столкнуться с проектом, который под nightly не работает. Последнее время таких breaking changes немного, и как правило работает, но всё же есть вполне неиллюзорные шансы. И поэтому rustup/cargo должны позволять работать как минимум с этими тремя ветками. Позапрошлогодние версии они могут и не поддерживать, но nightly/beta/stable должны. > Почему они вообще держат тучу тулчейнов, вместо того чтобы держать llvm-фронтэнд, я > не понимаю. Потому что есть много чего зависимого от тулчейна. Все библиотеки, например, должны быть перекомпилированы под каждый тулчейн: windows сборка пакета для x86 бесполезна для unix'а на arm64. Затем, разные версии rustc имеют разные возможности. У них есть общности, типа llvm (в смысле той прослойки llvm которая между фронтендом и бекендом), но это маленькая прослойка, на фоне всего остального. Но тут, я скажу, я вроде где-то читал недавно, что у них есть планы дать возможность использовать системный llvm для сборки rust'а. Хотя... что-то попуталось у меня в голове: это, по-моему, и так можно сделать и очень давно, если собирать rust вручную, без rustup'а. Точно можно было, пока я пользовался гентушным оверлеем в rust'е, я засылал туда патчи на ебилд, фиксящие сборку с системным llvm. То есть, наверное, я читал о том, что они планируют rustup научить использовать системный llvm. И если это так, то тебя это не должно касаться, поскольку тебе нужно чтобы всё ставилось через apt, а если через apt, значит мимо rustup'а.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	63. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от Аноним (40), 14-Апр-19, 18:31
	>>> Что ты называешь "нормальным" ООП? Как в java? Как в C++? Как >>> в Haskell? Как в gtk? Какой из ООП нормален? >> ООП с наследованием, где методы и свойства наследуются автоматически. > Deref/DerefMut тебе в помощь. И где тут автоматическое наследование? Всё же руками приходится делать, не? >> ООП в низкоуровневых языках - это всего лишь синтаксический сахар. > Дайте мне определение синтаксического сахара. Всё это синтаксический сахар. asm -- это синтаксический сахар над бинарным представлением машинного кода, позволяющий не считать адреса и смещения вручную. Да. >Python -- это синтаксический сахар над интерпретатором,  позволяющий дёргать те или иные функции интерпретатора. Нет. поскольку питон - язык интерпретируемый. > Если ты нашёл свой комп на помойке, то что ты вообще делаешь в разработке ПО? Не, ну реально. Так и запишем - "вход только для потреблятелей". > Тут вполне нормально и регулярно приходится пересобирать половину системы только для того, чтобы иметь отладочную информацию к ней, и иметь возможность протрейсить выполнение программы внутрь библиотеки, чтобы понять почему оттуда вылетает сегфолт. > Я пользуюсь генту, потому что тут без проблем можно отладочную информацию складывать рядышком с библиотеками и бинарями и подгружать её по мере необходимости, если я нечаянно закопался в какую-то библиотеку, про которую впервые слышу. Если бы этого не было, я бы давно забил на всё и вернулся бы в слакварь устанавливать программы при помощи make install. Так и запишем - "не смогли реализовать хранение отладочной информации во внешних файлах и подгрузку по мере надобности, даже имея перед глазами готовую и отполирванную реализацию от Microsoft". >> Современный язык должен уметь в бинарные пакеты-модули. Без исходника, без многочасовой сборки. При этом линарные пакеты должны быть обязательно подписаны приватным ключём автора. > А, ты о том, чтобы _пользоваться_ компьютером, быть пользователем и ставить программы себе в систему? Не о том чтобы разрабатывать? Нет, я и о разработке, и о пользовании. Потому что разработка включает в себя использование. И пересобирать мир для этого не надо. Проприетарасты это поняли и реализовали первыми, почему до адепты СПО страдают фигнёй, пересобирая мир, мне тоже понятно: потому что в отличии от проприетарастов, которым клиенты платят деньги в том числе за сервис, у спошников каждый сам за себя и некоторым даже бинарные пакеты через спонсируемый корпорациями CI распространять западло. > В задачи cargo не входит быть системным пакетным менагером. Чтобы устанавливать программы тебе следует пользоваться apt или что у тебя там стоит. То есть cargo -- это просто другой инструмент, если он попадает в класс пакетных  менагеров, это не значит, что он задуман как замена для apt или emerge. По-моему все пакетные менеджеры, которые я встречал, глубокь ущербны. >> * сделать пакеты не так уж и трудно. У дебиана конечно просто >> отвратительный инструментарий для пакетирования, но есть на ГХ один репозиторий с лучшим инструментарием, который дёргается из питона, а не из баша. > В случае rust'а -- это не так. Nightly, beta и stable сосуществуют. > Фиксы идут во все три ветки. Stable лучше чем nightly в плане стабильности и надёжности. Более того, ты можешь столкнуться с проектом, который под nightly не работает. Последнее время таких breaking changes немного,  и как правило работает, но всё же есть вполне неиллюзорные шансы. Именно поэтому надо выпилить стейбл и бету - они развращают разработчиков. Если что-то сломалось в пакетах в результате запланированного изменения API, значит это проблема пакета. И её по любому придётся исправлять, если пакет не выброшен на свалку истории: когда-то nightly станет stable, stable станет obsolete dino shit, и пакет - вместе с ним, потому что с новым stable он будет несовместим, с новым nightly и подавно, и править всё это придётся пользователям, которым больше всех нужно, при этом создавая свой форк, потому что остальные предпочтут не закрывать свою гору технического долга, а объявить дефолт и сказать "мы сидим на на старой версии, новая не нужна". Проходили уже с python 2 такую хрень. В отличие от раста в питоне есть 2to3 и изменения косметические, пофиксить элементарно, в расте скорее всего либа так и останется непофикшенной, то есть фактически исчезнет, соответственно будет ещё один аргумент в пользу "в гробу я видал этот хипстерский раст". Поэтому фиксить несовместимости с самой новой версией нужно как можно раньше и пользоваться преимуществами nightly. > Потому что есть много чего зависимого от тулчейна. Все библиотеки, например, должны быть перекомпилированы под каждый тулчейн: windows сборка пакета для x86 бесполезна для unix'а нarm64. Библиотеки-то да, я говорю про тулчейн. > Затем, разные версии rustc имеют разные возможности. > У них есть общности, типа llvm (в смысле той прослойки llvm которая между фронтендом и бекендом), но это маленькая прослойка, на фоне всего остального. Я имею в виду что со CLangом не нужен десяток тулчейнов, нужен 1 шланг + стандартная библиотека для платформы. Один и тот же шланг строит и под винду используя MinGW, и под винду, используя msvcrt, и под линукс x86, используя мюсл, и под ведро, и под карты NVidia, и под карты AMD и под айфоны. Почему так не сделано для раста?
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	71. "Выпуск языка программирования Rust 1.34"	+2 +/–
	Сообщение от Ordu (ok), 14-Апр-19, 19:42
	>>>> Что ты называешь "нормальным" ООП? Как в java? Как в C++? Как >>>> в Haskell? Как в gtk? Какой из ООП нормален? >>> ООП с наследованием, где методы и свойства наследуются автоматически. >> Deref/DerefMut тебе в помощь. > И где тут автоматическое наследование? Всё же руками приходится делать, не? Написать метод deref(&self) -> &ParentType? Да надо. >>Python -- это синтаксический сахар над интерпретатором,  позволяющий дёргать те или иные функции интерпретатора. > Нет. поскольку питон - язык интерпретируемый. И что? Интерпретатор -- это по сути API, с кучей методов. Python -- это по-сути read-eval-print в цикле, который в процессе evel дёргает этот самый API. Таким образом python как язык -- это синтаксический сахар над тем API. >> Если ты нашёл свой комп на помойке, то что ты вообще делаешь в разработке ПО? Не, ну реально. > Так и запишем - "вход только для потреблятелей". Отказ от первого пня в пользу i7 не сделает из тебя потребляти. Так же как отказ от i7 в пользу первого пня не позволит тебе прекратить быть потреблятью. > Так и запишем - "не смогли реализовать хранение отладочной информации во внешних > файлах и подгрузку по мере надобности, даже имея перед глазами готовую > и отполирванную реализацию от Microsoft". Гента смогла. Поэтому я ей и пользуюсь. > Нет, я и о разработке, и о пользовании. Потому что разработка включает > в себя использование. И пересобирать мир для этого не надо. Проприетарасты > это поняли и реализовали первыми, почему до адепты СПО страдают фигнёй, > пересобирая мир, мне тоже понятно: потому что в отличии от проприетарастов, > которым клиенты платят деньги в том числе за сервис, у спошников > каждый сам за себя и некоторым даже бинарные пакеты через спонсируемый > корпорациями CI распространять западло. Не, просто у пропиерастов, как правило, нет опции пересобрать. Пересобрать gtk с assert'ами? Заинжектить код в gtk, чтобы посмотреть, что из этого выйдет? Отключить/подключить опциональные депендансы? Сменить версии библиотек, уйти от stable, уйти от unstable и поставить себе последний коммит из git репо, который даже тегом не помечен, и поэтому идентифицируется лишь хешом? > По-моему все пакетные менеджеры, которые я встречал, глубокь ущербны. Ну если в философию нырять, то да. Они все ущербны. dll-hell нерешённая проблема, а все попытки её решить -- костыли, а не решения. > Именно поэтому надо выпилить стейбл и бету - они развращают разработчиков. Если > что-то сломалось в пакетах в результате запланированного изменения API, значит это > проблема пакета. Да. Но вот у меня крутится сайт на rust'е -- я его поднимал год назад под проведение психологического эксперимента. Он не нужен уже, но по инерции крутится. И если мне сейчас приспичит что-то там поменять, то я поменяю и пересоберу его, без того, чтобы нырять на несколько часов в код, обновляя его, обновляя все депендансы и всё остальное. Причём соберётся как http-сервер, так и websockets сервер, так и wasm модуль (ещё через emscripten собранный). Наверное, это признак развращения, но это удобно. Это значит, что я могу не трогать сайт, откладывая все крупные изменения, собирая их в TODO лист, с тем чтобы если придёт время менять сайт, то я сделал бы это всё за раз. > В отличие от раста в питоне есть 2to3 и изменения > косметические, пофиксить элементарно, в расте скорее всего либа так и останется > непофикшенной, то есть фактически исчезнет, соответственно будет ещё один аргумент в > пользу "в гробу я видал этот хипстерский раст". Поэтому фиксить несовместимости > с самой новой версией нужно как можно раньше и пользоваться преимуществами > nightly. Это хорошо звучит в теории, а на практике очень удобно иметь долю свободы, чтобы цикл разработки одной программы не был бы жёстко прибит гвоздями к циклу разработки другой программы. > Я имею в виду что со CLangом не нужен десяток тулчейнов, нужен > 1 шланг + стандартная библиотека для платформы. Один и тот же > шланг строит и под винду используя MinGW, и под винду, используя > msvcrt, и под линукс x86, используя мюсл, и под ведро, и > под карты NVidia, и под карты AMD и под айфоны. Почему > так не сделано для раста? Потому что не всё сразу. Вот реально, что важнее, чтобы rust компилировал бы, или чтобы он компилировал быстро? Или чтобы он использовал бы одну и ту же сборку llvm под все платформы? Я ещё раз тебе говорю: возможность собрать rust на одном системном llvm есть. Но не в rustup. Не, ладно бы rust закончил бы своё развитие, и при застрял бы в том состоянии, в котором он сейчас находится. Но это ведь не так, развитие продолжается, в том числе и развитие оптимизатора, то есть взаимодействие с llvm изменяется со временем. Вносить в систему на этом этапе дополнительные сложности, значит во-первых тратить на это время сейчас, когда есть более важные задачи, во-вторых, создавать себе потенциально проблем потом, когда выснится, что эти дополнительные сложности были решены субоптимальным образом, и теперь не позволяют внести какие-то изменения в rust, и поэтому их надо переделывать.
	Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

	81. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от Аноним (40), 14-Апр-19, 21:55
	> Написать метод deref(&self) -> &ParentType? Да надо. Спасибо за наводку, но я её правда не до конца ещё осознал. Не могли бы вы привести ссылку на обучающий материал, где этот трюк используется именно для нормального наследования и нормального полиморфизма? > И что? Интерпретатор -- это по сути API, с кучей методов. Python  -- это по-сути read-eval-print в цикле, который в процессе evel дёргает этот самый API. Таким образом python как язык -- это синтаксический сахар над тем API. Новый язык разрабатывается ради нового look&feel, и дёргание питоньего апи из C++ не даёт look&feel, который задумал его создатель. > Отказ от первого пня в пользу i7 не сделает из тебя потреблятелем. Так же как отказ от i7 в пользу первого пня не позволит тебе прекратить быть потреблятелем. Разумеется. Потому что потреблятель - это образ мыслей. Есть люди,  считаюшие, что допустимо дискриминировать людей по наличию/отсутствию определённых вещей и что люди без определённых вещей достойны презрения. Я с этим в корне не согласен. > Гента смогла. Поэтому я ей и пользуюсь. Это хорошо. Значит ничего не мешает распространять бинарные пакеты и отладочную информацию к ним. > Не, просто у пропиерастов, как правило, нет опции пересобрать. Пересобрать gtk с assert'ами? Заинжектить код в gtk, чтобы посмотреть, что из этого выйдет? Отключить/подключить опциональные депендансы? Сменить версии библиотек, уйти от stable, уйти от unstable и поставить себе последний коммит из git репо, который даже тегом не помечен, и поэтому идентифицируется лишь хешом? В случае тяжёлых зависимостей я бы этого избегал настолько, насколько имеет смысл. В большинстве случаев пересборка мира ради возможности вставить отладочный вывод не оправдана. И тем более не имеет смысла заставлять всех разработчиков собирать все зависимости самостоятельно. > Ну если в философию нырять, то да. Они все ущербны. dll-hell нерешённая проблема, а все попытки её решить -- костыли, а не решения. Да дело не в dll-hell, который решается описанным мною правилом использования последних версий для всего. Проблема в бардаке и зоопарке, когда в системе несколько менеджеров, дублирующих функциональность друг друга, и одни пакеты в одном, а другие - в другом, а третьи - в третьем, и у каждого менеджера свои закидоны. > Да. Но вот у меня крутится сайт на rust'е -- я его > поднимал год назад под проведение психологического эксперимента. Он не нужен уже,  но по инерции крутится. И если мне сейчас приспичит что-то там поменять, то я поменяю и пересоберу его, без того, чтобы нырять на несколько часов в код, обновляя его, обновляя все депендансы и всё остальное. Причём соберётся как http-сервер, так и websockets сервер, так и wasm модуль (ещё через emscripten собранный). Несколько часов на обновление используемого API в своём коде - как-то многовато. > Это значит, что я могу не трогать сайт, откладывая все крупные изменения, собирая их в TODO лист, с тем чтобы если придёт время менять сайт, то я сделал бы это всё за раз. > Это хорошо звучит в теории, а на практике очень удобно иметь долю свободы, чтобы цикл разработки одной программы не был бы жёстко прибит гвоздями к циклу разработки другой программы. Не к циклу разработки, а к изменениям API, используемых в конкретной программе/библиотеке. И изменение нутра библиотеки зависимые от неё проекты скорее всего вообще не затронет. >> Я имею в виду что со CLangом не нужен десяток тулчейнов, нужен >> 1 шланг + стандартная библиотека для платформы. Один и тот же >> шланг строит и под винду используя MinGW, и под винду, используя >> msvcrt, и под линукс x86, используя мюсл, и под ведро, и >> под карты NVidia, и под карты AMD и под айфоны. Почему >> так не сделано для раста? >возможность собрать rust на одном системном llvm есть. Но не в rustup. Решит ли это проблему зоопарка тулчейнов?
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	95. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Ordu (ok), 15-Апр-19, 00:14
	>> Написать метод deref(&self) -> &ParentType? Да надо. > Спасибо за наводку, но я её правда не до конца ещё осознал. > Не могли бы вы привести ссылку на обучающий материал, где этот > трюк используется именно для нормального наследования и нормального полиморфизма? https://doc.rust-lang.org/book/ch15-02-deref.html Там правда примеры с умными указателями, но это позволяет, например, иметь Vec, который -- динамический массив, и при этом расширение типа slice, который нединамический массив. Но это, я так подумал, статический полиморфизм. Чтобы его пользовать ещё неплохо было бы AsRef/AsMut освоить, чтобы передавать в функцию slice или Vec, или всё что угодно ещё, что может быть приведено к типу slice. Но вся типизация должна быть разрешена до конкретных типов на этапе компиляции. И если это интересно, то я бы рекомендовал вообще посмотреть на borrow Для динамического полиморфизма придётся комбинировать это с &dyn Trait. То есть писать не функцию: fn foo<T: AsRef<BaseType>>(arg: T); а динамическую: fn foo(arg: &dyn BaseType); Примеров же реального применения я не знаю. Как правило, народ уворачивается от dyn Trait, в пользу статического диспатча. >> Отказ от первого пня в пользу i7 не сделает из тебя потреблятелем. Так же как отказ от i7 в пользу первого пня не позволит тебе прекратить быть потреблятелем. > Разумеется. Потому что потреблятель - это образ мыслей. Есть люди,  считаюшие, > что допустимо дискриминировать людей по наличию/отсутствию определённых вещей и что люди > без определённых вещей достойны презрения. Я с этим в корне не > согласен. Тут речь не о презрении. На мой взгляд, заниматься разработкой и боятся компиляции -- это волков боятся в лес не ходить. За счёт чего при этом ты будешь снимать страх -- за счёт Ryzen'а на 64Гб оперативки или за счёт философского подхода к компиляции, идущей в бекграунде -- это уже не столь важно. >> Не, просто у пропиерастов, как правило, нет опции пересобрать. Пересобрать gtk с assert'ами? Заинжектить код в gtk, чтобы посмотреть, что из этого выйдет? Отключить/подключить опциональные депендансы? Сменить версии библиотек, уйти от stable, уйти от unstable и поставить себе последний коммит из git репо, который даже тегом не помечен, и поэтому идентифицируется лишь хешом? > В случае тяжёлых зависимостей я бы этого избегал настолько, насколько имеет смысл. > В большинстве случаев пересборка мира ради возможности вставить отладочный вывод не > оправдана. И тем более не имеет смысла заставлять всех разработчиков собирать > все зависимости самостоятельно. Ну мне это удобно. Когда сорцы вот они здесь, тут, и я не понимаю что происходит, я всегда могу заглянуть туда. Можно конечно и в браузере посмотреть -- в документации есть ссылки на сорцы, -- но это не всегда удобно. >> Ну если в философию нырять, то да. Они все ущербны. dll-hell нерешённая проблема, а все попытки её решить -- костыли, а не решения. > Да дело не в dll-hell, который решается описанным мною правилом использования последних > версий для всего. Это _теоретическое_ решение. Практически оно не работает из-за масштабов. Ну прикинь, допустим мы всем разработчикам навтыкали пистонов, и они теперь как миленькие в темпе вальса обновляют свой код под все новые библиотеки. Но есть ненулевая вероятность того, что кто-нибудь из них всё равно не обновит -- потому что у него на работе завал из дедлайнов, потому что он в больнице лежит с запором, потому что жена не дала и он ушёл в запой. Список возможных причин можно продолжить. Пускай эта вероятность 0.01, это значит, что при обновлении glibc, от которой зависят все пакеты debian'а, каждый сотый разработчик пропустит дедлайны на обновление своего пакета. И все пакеты которые зависят от этих пакетов тоже пропустят дедлайны. При наличии тысячи пакетов в системе, даже если рядом с каждым разработчиком стоит чекист с наганом, мы будем обновлять glibc месяц, два, а то и полгода, из-за всех этих депендансов. А у нас нет нужного количества чекистов и наганов? В реальности ситуация доходит до того, что невозможно создать систему, которая на всех распоследних версиях софта. Потому что когда мы дождались самых слоупоков из разработчиков, и закончили обновление пакетов, самые резкие разработчики уже успели выпустить новые версии своих пакетов, и может быть не по одной. > Проблема в бардаке и зоопарке, когда в системе > несколько менеджеров, дублирующих функциональность друг друга, и одни пакеты в одном, > а другие - в другом, а третьи - в третьем, и > у каждого менеджера свои закидоны. Эмм... а чё поделаешь? Вот у меня стоит emerge, cargo плюс emacs'овый пакетный менагер. Я ещё со времён когда Common Lisp'ом увлекался понял, что полагаться на системный пакетный менагер в плане  вытягивания каких-то очень специфичных многих депендансов -- это пустое дело. Всё равно придётся собирать руками. Можно писать ebuild'ы. Но кто ж за ними следить будет? А если взять quicklisp или что-нибудь в этом роде, то -- хоп -- и всё установлено. Если техническая проблема, называемая dll-hell. А есть социальная проблема -- как всех задействованных в создании dll-hell собрать и сорганизовать так, чтобы они, не слакая, следили бы за всеми пакетами, и чтобы при этом не надо было бы к каждому ставить по чекисту с наганом. Ну или если ставить, то где взять чекистов и наганы. И вот тут начинается фрагментация, потому что в каких-то сообществах удобнее часто-часто обновлять всё, в каких-то редко, но метко, третьим надо multilib, четвёртые хотят релизиться только по вторникам нечётного числа, и нет никаких реалистичных правил, которые бы устроили всех. Так что фрагментация эта не только вредна, но и полезна: она позволяет разным сообществам иметь более подходящие им правила, вместо одних правил для всех, которые никому не подходят. Растущие масштабы разработки СПО приводят к этой самой фрагментации. Она неизбежна. И как бы я не сочувствовал аутистичным асоциальным хакерам, которые создали себе нишку для существования, где они могли вести себя так, как им удобнее, и жить себе неплохо, а тут их начинают всякие мимопроходилы организовывать CoC'ами, я не могу не понимать при этом, что это неизбежно рано или поздно должно было бы случиться в процессе роста масштабов СПО как социального явления. Социум он вообще такой -- есть вещи, которые не нужны или не возникают или не проблема в группе из 10 человек, но которые становятся занозой в заднице, когда группа разрастается до 1000 или до миллиона. Всё что можно было бы сделать сейчас -- это собрать разработчиков всех сколь-нибудь популярных пакетных менагеров в кучу, пригласить так же и всех остальных интересующихся, и начать обсуждать общие для всех стандарты, так чтобы снизить остроту проблем возникающих из-за фрагментации. Но эта такая штука, которой по идее должны были бы заняться debian и redhat, как ведущие дистры. Но redhat'у это не особо надо, а debian'у бы со своими внутренними проблемами разобраться бы. О! Шигорин! Ты читаешь эту стену текста? У альта нет желания выйти на мировой уровень, проработав эту проблему теоретически, организовав конференцию, пригласив туда представителей redhat, debian, ..., разработчиков pip, gem, cargo, meson, ...? С тем чтобы решить проблемы поддержки пакетов и минимизировать по возможности дублирование работ, выполняемыми мейнтейнерами разных дистрибутивов и разработчиками софта (которые собирают гемы для руби или крейты для раста), упростить и стандартизовать общение между мейнтейнерами одного пакета из разных дистров и разработчиками этого пакет. То есть, я не знаю как это делается, но я уверен, что не так уж и сложно будет найти человека, который скажет что надо сделать до конференции (разработать демку платформы кооперации?), и как надо подойти к написанию приглашений (обязательно ли использовать гербовую бумагу, или можно на простой), обращаться ли к ним Dear sir or madam, или можно написать Hi, nigga. Причём у вас там в альте ведь должно быть достаточно людей, которые в теме и которые, в отличие от меня, могут не теоретически рассуждать о проблемах, но вполне конкретно, с конкретными примерами, со ссылками на списки рассылки и тд, и тп. Подготовить пяток докладов от Alt'а (продуманных, осмысленных, отрецензированных десятикратно, с красивыми содержательными презентациями и вообще демонстрирующих высокий профессионализм Alta, увлечённость СПО, и все прочие положительные качества тоже демонстрирующих (хипстерство, как открытость новым технологиям и новым идеям -- это положительное качество (это я на всякий случай))), объявить регистрацию любых других докладчиков, и надеятся на то, что их наберётся хотя бы часа на три-четыре докладов. Не факт что сработает, но мне кажется, что шансы есть. Особенно если не забыть про печеньки в перерыве. ... Хотя... санкции... они всё испортят, да? Или у вас нет эффективных менагеров, с шилом в заднице, которые подобные вопросы проворачивают на завтрак? >> Да. Но вот у меня крутится сайт на rust'е -- я его >> поднимал год назад под проведение психологического эксперимента. Он не нужен уже,  но по инерции крутится. И если мне сейчас приспичит что-то там поменять, то я поменяю и пересоберу его, без того, чтобы нырять на несколько часов в код, обновляя его, обновляя все депендансы и всё остальное. Причём соберётся как http-сервер, так и websockets сервер, так и wasm модуль (ещё через emscripten собранный). > Несколько часов на обновление используемого API в своём коде - как-то многовато. Я этот код не видел год. Это значит надо сходу положить полчаса на чтение кода и выяснение того, как оно работает. Плюс у кода есть зависимости, обновление которых, может привести к непредсказуемым последствиям для моего кода. Планируя такое я бы не закладывал менее двух часов ни при каких обстоятельствах, как бы эффективный менагер с чекистом не кричали бы на меня, а вообще я бы закладывал бы на это время с утра и до обеда, с оговоркой, что возможно это затянется до вечера. Впрочем если речь только об обновлении ради обновления и перехода на более новые версии пакетов, то до вечера не затянется. К обеду справлюсь, по-любому. >> Это значит, что я могу не трогать сайт, откладывая все крупные изменения, собирая их в TODO лист, с тем чтобы если придёт время менять сайт, то я сделал бы это всё за раз. >> Это хорошо звучит в теории, а на практике очень удобно иметь долю свободы, чтобы цикл разработки одной программы не был бы жёстко прибит гвоздями к циклу разработки другой программы. > Не к циклу разработки, а к изменениям API, используемых в конкретной программе/библиотеке. Выкатывание новых версий в серьёзных проектах делают по расписанию. Согласно циклу разработки, типа окно для принятия новых фичей, потом мы окно закрываем, вылизываем код, тестируем, и выкатываем релиз. Опять открываем окно для принятия новых фичей. В несерьёзных проектах это происходит менее предсказуемо, но это не упрощает жизнь зависимым проектам, а усложняет. > И изменение нутра библиотеки зависимые от неё проекты скорее всего вообще > не затронет. Опять же, закон больших чисел. Скорее всего не затронет, это значит что с вероятностью 10% всё пройдёт гладко. А теперь у нас есть 100 пакетов в депендансах, и матожидание нам подсказывает, что с десятью пакетами не заладится. Опять же, когда у нас в депендансах awk, который не меняет своих API веками, мы можем быть спокойны, но когда у нас в депендансах gfx-rs, чьи авторы активно экспериментируют с разными подходами создания API для программирования видеокарт, которое одевается поверх OpenGL, DirectX, Vulkan, Metal, ..., и при этом не создаёт никаких накладных расходов в рантайме, то практически наверняка что-нибудь сломается, и может быть сломается так, что мы чинить будем неделю. > Решит ли это проблему зоопарка тулчейнов? В каком смысле "решит"? Тулчейны никуда не денутся уже, они плотно вошли в терминологию cargo и они там будут всегда. Но, с другой стороны, разные тулчейны могут использовать один и тот же llvm. Причём установленный системно, а не в $HOME. Теоретически они могут даже использовать один и тот же бинарь rustc, который будет уметь работать как nightly, как beta или как stable. Но я не знаю ничего о таких планах: разные версии rustc разрабатываются в разных ветках git. Сливать их в одну ветку перед релизом будет слишком заморочно и надеятся на это не приходится.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	106. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от Аноним (40), 15-Апр-19, 02:53
	>[оверквотинг удален] > конкретных типов на этапе компиляции. И если это интересно, то я > бы рекомендовал вообще посмотреть на borrow > Для динамического полиморфизма придётся комбинировать это с &dyn Trait. То есть писать > не функцию: > fn foo<T: AsRef<BaseType>>(arg: T); > а динамическую: > fn foo(arg: &dyn BaseType); > Примеров же реального применения я не знаю. Как правило, народ уворачивается от > dyn Trait, в пользу статического диспатча. > Тут речь не о презрении. На мой взгляд, заниматься разработкой и боятся компиляции -- это волков боятся в лес не ходить. На мой же взгляд компиляцию не всегда имеет смысл делать, и если делать её смысл не имеет, её лучше не делать > Ну мне это удобно. Когда сорцы вот они здесь, тут, и я не понимаю что происходит, я всегда могу заглянуть туда. Вытянуть и посмотреть сорцы и пересобрать мир - разные вещи. > Это _теоретическое_ решение. Практически оно не работает из-за масштабов. Отлично работает. Обновляю питоньи библиотеки из гита, убрав локи на версии, и ... ничего не ломается. Ну прикинь, допустим  мы всем разработчикам навтыкали пистонов, и они теперь как миленькие в темпе вальса обновляют свой код под все новые библиотеки. Но есть ненулевая вероятность того, что кто-нибудь из них всё равно не обновит -- потому что у него на работе завал из дедлайнов, потому что он в больнице лежит с запором, потому что жена не дала и он ушёл в запой. Список возможных причин можно продолжить. Он не обновит - обновят другие. У популярных библиотек больше одного контрибьютера. > Пускай эта вероятность 0.01, это значит, что при обновлении glibc, от которой зависят все пакеты debian'а, каждый сотый разработчик пропустит дедлайны на обновление своего пакета. И все пакеты которые зависят от этих пакетов тоже пропустят дедлайны. Или хотя бы один из них пришлёт PR и либу пофиксят и дедлайны не пропустят. А если у популярной либы один мейнтейнер, который внезапно скончался, и теперь сливать PR некому, то срыв сроков всем сообществом вполне заслужен, раз они не смогли создать "организацию" и перевести репизиторий в коллективное управление. > А у нас нет нужного количества чекистов и наганов? В реальности ситуация доходит до того, что невозможно создать систему, которая на всех распоследних версиях софта. Потому что когда мы дождались самых слоупоков из разработчиков, и закончили обновление пакетов, самые резкие разработчики уже успели выпустить новые версии своих пакетов, и может быть не по одной. ... которые совместимы со старыми версиями. Ещё раз - далеко не каждое изменение ломающее. Если бы хотя бы 25% изменений (каждый 4й мердж в мастер) были ломающими, мы бы тут все уже давно свихнулись бы. > Всё что можно было бы сделать сейчас -- это собрать разработчиков всех сколь-нибудь популярных пакетных менагеров в кучу, пригласить так же и всех остальных интересующихся, и начать обсуждать общие для всех стандарты, так чтобы снизить остроту проблем возникающих из-за фрагментации. ИМХО: проблема больше техническая. Все пакетные менеджеры делают примерно одно и то же: распаковывают архивы, раскидывают файлики по папкам, разрешают зависимости, создают симлинки, ведут базу данных, вызывают хуки, - значит проблема решается введением middleware, frontendов и backendов, где фронтэнды - это фактически переписанные поверх фреймворка пакетные менеджеры. Как LLVM, только для пакетных менеджеров. После запила и доведения до ума оригинальные пакетные менеджеры объявляются не нyжными и выкидываются на свалку истории. Спасибо за дискуссию, про полиморфизм я так и не понял (и не нагуглил), как его запилить с помощью derefа.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	68. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноня (?), 14-Апр-19, 19:03
	Deref антипаттерн
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	117. "Выпуск языка программирования Rust 1.34"	–2 +/–
	Сообщение от Банда Четырёх (?), 15-Апр-19, 09:40
	Так и наследование антипаттерн.
	Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

	159. "Выпуск языка программирования Rust 1.34"	+2 +/–
	Сообщение от KonstantinB (ok), 16-Апр-19, 18:49
	Наследование наследованию рознь. Наследование от абстрактного класса при четко выраженном отношении "is-a" - абсолютно ок. В Расте трейты с дженериками - вполне себе полноценная замена (при этом намного мощнее).
	Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

	157. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от KonstantinB (ok), 16-Апр-19, 05:55
	"ООП с наследованием" - это и есть "как в C++ и Java". К ООП концепция наследования прямого отношения не имеет (см. Smalltalk).
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	45. "Выпуск языка программирования Rust 1.34"	–2 +/–
	Сообщение от Вы забыли заполнить поле Name (?), 14-Апр-19, 16:07
	> предлагается ставить язык с какого-то говносайта путём curl | bash вместо использования > пакетов дистрибутива патамушта разработчики сидять под Б-жественной Десяточкой, у них все так ставится. > в коде по-видимому захардкожено, что некоторые фичи языка можно использовать только на найтли, > а большинство пакетов как раз зависит от пакетов, зависящих от ночных фич. патамушта не обмазаться наисвежайшим у этого поколения не принято, ага. > пакет для Qt какая-то недоделанная альфа ну это-то как раз единственное, что нормально. И может даже со временем альфа превратится в бету. "зато у них разработчики дешовенькие!"
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	56. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноним (20), 14-Апр-19, 16:56
	>в коде по-видимому захардкожено, что некоторые фичи языка можно использовать только на найтли, а большинство пакетов как раз зависит от пакетов, зависящих от ночных фич   найтли чаще всего требуется для низкоуровневых вещей вроде ассемблерных вставок, конпеляния чего-то специфического с no_std, работы с аллокаторами и т.п. Про "большинство пакетов" конечно чушь. Большинство пакетов, которыми ты интересовался.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	129. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от Ретроград (?), 15-Апр-19, 11:24
	Вот это, кстати, вообще ядерная пушка. Язык системного программирования, в котором нельзя делать ассемблерные вставки и собрать бинарник без стандартной библиотеки. Особенно веселила ситуация с no_std, который спустя несколько лет слезных просьб эмбеддед-разработчиков таки попал в stable, а необходимый для него panic_handler еще +много лет висел за feature gate и в итоге в стабильном компиляторе была фича, которую невозможно использовать. Кажется, буквально в декабре 2018 года это дело наконец-то пофиксили и теперь можно собирать standalone бинарники. Спустя 8 лет!
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	103. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от FHD (?), 15-Апр-19, 01:44
	>> Нет предсобраных пакетов Ты совсем кретин, раз не понимаешь, что на выходе нужен нативный код под конкретную платформу! В текущем виде ты можешь компилировать под платформы, который могут выйти позже
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

79. "Выпуск языка программирования Rust 1.34"	–1 +/–
Сообщение от Аноним (-), 14-Апр-19, 21:30
> а теперь возможно использование перечислений ('#[range(0..10)]') и конструкций вида "#[bound(T: MyTrait)]"; О да! Вот увидит какой-нибудь непосвященный шпион такой код и нихрена поймёт! Круто!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	84. "Выпуск языка программирования Rust 1.34"	+1 +/–
	Сообщение от Аноним (84), 14-Апр-19, 22:34
	Это да. Вообще, из того, что в расте цикл for x in 0..L означает, что x принимает значения от 0 до L-1 (хотя 0..L как раз выглядит СИММЕТРИЧНЫМ диапазоном, в отличие от 0..=L) уже говорит о том, что язык был мучительно придуман во время сидения на унитазе. Или, например, я могу создать range целых чисел и проитерировать по нему. При этом range char'ов я создать тоже могу, но проитерировать по нему - нет. Сюрпрайз! Спасибо, жрите сами.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	105. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от kiwinix (?), 15-Апр-19, 02:12
	Не встречал надобности итерировать буквы ни в расте ни в других языках. А значит претензия не засчитана. П.С. Скорее всего не так уж и хотелось итерировать буквы
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	115. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноним (115), 15-Апр-19, 07:33
	Отличительная черта фанатиков чего бы то ни было (будь то смартфон, DE/тайловый менеджер или язык программирования) - кричать НИНУЖНА, если в их объекте фанатизма нет того, что оказалось нужным обычным людям, не фанатикам. Зачастую после крика НИНУЖНА следуют далеко идущие выводы о собеседнике.
	Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

	111. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноним (20), 15-Апр-19, 06:44
	>При этом range char'ов я создать тоже могу, но проитерировать по нему - нет   for c in b'a'..=b'z' {}
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	114. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноним (115), 15-Апр-19, 07:29
	Не-не, дружок. Интересует юникод.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	118. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от Аноним (20), 15-Апр-19, 09:51
	ясно. Ты не нашел в доках rust функцию char::from_u32 и правильные диапазоны в стандарте utf-8, и побежал жаловаться на форумы, какой плохой этот rust. Дай угадаю - ты веб-макака, да?
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	119. "Выпуск языка программирования Rust 1.34"	+1 +/–
	Сообщение от Аноним (115), 15-Апр-19, 09:58
	Не-не, дружок. Я её нашёл и мне ПРИШЛОСЬ её использовать - преобразовывать range char'ов в range int'ов, и итерировать уже по нему. Что в C я мог, кстати, сделать без всяких преобразований. Но ты не отвлекайся. Скажи, пожалуйста, зачем в прекрасном расте есть возможность создать range символов, если по нему нельзя итерировать?
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	121. "Выпуск языка программирования Rust 1.34"	+1 +/–
	Сообщение от scor (ok), 15-Апр-19, 10:22
	> Не-не, дружок. Интересует юникод. Вообще, да, странная ситуация. С одной стороны есть вполне вменяемое объяснение почему нет итератора для чаров https://internals.rust-lang.org/t/iterating-over-range-char/... С другой стороны Ord таки задефайнен для чаров и ничто не мешало приделать итератор, раз уж определён порядок. Но с третей стороны, например, в том же хаскеле такое делать можно, но совершенно не очевидно, чего хотел программист делая какой-нибудь ``` map f ['а' ..'я'] ``` Это в рамках какого алфавита должно происходить? Или вот это что значит? ``` λ> 'е' < 'ё' True λ> 'ё' < 'ж' False ``` Понятно, что это из-за: ``` λ> 'е' '\1077' λ> 'ё' '\1105' λ> 'ж' '\1078' ``` Но если принять, что это нормальное поведение и так и должно быть, то получается, что мы хотим работать тупо с интами и чары тут ни при чём, а если хотим работать с каким-то конкретным алфавитом, то придётся его задавать руками (или брать из готовых библиотек) и работать уже не с Char, а явно с RusAbc, EngAbc или IcelandicAbc. Возможно, что в расте хотели избежать этой неопределённости и намеренно не реализовали итераторы для чаров. Но зачем тогда там можно делать range для них, тоже не ясно. Выглядит как логическая дырка.:) ЗЫ. Я вообще не специалист по расту. А выше мысли по мотивам нагугленного за десять минут материала.:)
	Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

	131. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от Ретроград (?), 15-Апр-19, 11:50
	Раст целиком и состоит из таких "логических дырок". Этот "язык системного программирования" спустя почти десятилетие своего развития до сих пор не определился со своей моделью памяти, что уж говорить о таких мелочах.
	Ответить | Правка | ^ к родителю #121 | Наверх | Cообщить модератору

	162. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от burjui (ok), 17-Апр-19, 11:42
	Будьте добры пояснить, что вы имеете ввиду. Выглядит так, будто вы высосали это из пальца/бутылки.
	Ответить | Правка | ^ к родителю #131 | Наверх | Cообщить модератору

87. "Выпуск языка программирования Rust 1.34"	–1 +/–
Сообщение от Аноним (-), 14-Апр-19, 22:42
В одной плюсовой библиотеке изменений больше, чем во всём вашем расте: https://www.boost.org/users/history/version_1_70_0.html
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

94. "Выпуск языка программирования Rust 1.34"	–1 +/–
Сообщение от Аноним (94), 14-Апр-19, 23:54
А всё же, есть ли альтернативы Расту? С более адекватным синтаксисом, с нулевой абстракцией, +- такой же скоростью, и не unsafe? И да, более-менее популярный.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	98. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от Аноним (101), 15-Апр-19, 00:31
	Чувак, если ты считаешь, что раст безопасен, то ты просто ничего не понимаешь в Computer Science.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	151. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноня (?), 15-Апр-19, 20:19
	> Computer Science. Computer Science - это наука о компьютере, если кто не знал. Продолжайте, пожалуйста
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	102. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от Аноним (101), 15-Апр-19, 01:05
	Вот тебе простой пример: переполнение стека. Чем в этом плане Раст лучше современных реализаций Си/Си++? Да ничем! А растоманы продолжают думать, что Раст гарантирует им безопасность. Не гарантирует он её на самом деле даже про память. А кроме памяти есть ещё куча разных опасностей.
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	112. "Выпуск языка программирования Rust 1.34"	+4 +/–
	Сообщение от Аноним (20), 15-Апр-19, 06:56
	раст гарантирует отсутствие неопределенного поведения за пределами блоков unsafe. Падения после переполнений стека, деления на ноль и т.п. не приводят к порче памяти. В общем, иди учи уроки и никогда не кидайся терминами, значение которых не понимаешь. (не говоря уже про "C/C++" - одно это выдает в тебе человека, который никогда ничего не писал ни на том, ни на другом)
	Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

	120. "Выпуск языка программирования Rust 1.34"	–2 +/–
	Сообщение от Аноним (-), 15-Апр-19, 10:20
	Ха-ха, типичный растофан не слышал про устройство ржавчины и обход stack guard-page. Вот тебе один примерчик, хоть и старый, но актуальный в контексте данного спича: https://ldpreload.com/blog/stack-smashes-you Можешь продолжать проецировать свои комплексы на меня.
	Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

	130. "Выпуск языка программирования Rust 1.34"	+1 +/–
	Сообщение от анонн (?), 15-Апр-19, 11:34
	> Ха-ха, типичный растофан не слышал про устройство ржавчины и обход stack guard-page. А сказать нерастофан хотел что? https://internals.rust-lang.org/t/getting-rid-of-stack-guard... > We currently detect the address of the stack guard page and even try to create one if it’s not created by the operating system.
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	133. "Выпуск языка программирования Rust 1.34"	–2 +/–
	Сообщение от Аноним (-), 15-Апр-19, 11:57
	Читай пост №102 по буквам. Лупу возьми. Потом ещё раз читай по моей ссылке до понимания что такое обход stack guard page.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	134. "Выпуск языка программирования Rust 1.34"	+3 +/–
	Сообщение от анонн (?), 15-Апр-19, 12:12
	> Читай пост №102 по буквам. Лупу возьми. Потом ещё раз читай по > моей ссылке до понимания что такое обход stack guard page. Т.е. ничего внятного? Понятно.
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

Часть нити удалена модератором

	140. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от анонн (?), 15-Апр-19, 13:44
	> Я не знаю как идиотам объяснять. Т.е. вы не знаете как объяснить то аморфное нечто, что вы, возможно, имели в виду, но идиот почему-то я? > Ищите по словам stack guard page > на опеннэте что ли... Как раз недавно была новость про обход > оной в systemd. https://www.opennet.dev/openforum/vsluhforumID3/116269.html > но для успешной атаки требуется обойти применяемую в ядре технику защиты > "stack guard-page", суть которой в подстановке граничных страниц памяти, > обращение к которым приводит к генерации исключения (page-fault). > Для обхода данной защиты из параллельно выполняемого потока systemd-journald было инициировано состояния гонки > состояния гонки Ой, да? > Там ещё растофанатики предлагали переписать systemd  на > rust, чтобы такого не было. Ну-ну... Нефанатики лучше бы почитали оригинал и что там на самом деле было: https://seclists.org/oss-sec/2019/q1/54 - because the attacker-controlled alloca() can be very large (several megabytes of   command-line arguments); only Steps 3 (Jump over the stack guard page,   into another memory region) and 4 (Smash the stack, or another memory   region) are needed. - In Step 4 (Smash), the alloca() is fully written to (the vulnerability   is essentially a stpcpy(alloca(strlen(cmdline) + 1), cmdline)), and   the stpcpy() (a "wild copy") will therefore always crash into a   read-only or unmapped memory region: Ну и как там гвард обошли почитайте, для общего развития полезно будет.
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	164. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноним (164), 17-Апр-19, 19:25
	Где там код на Расте упырь?
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

108. "Выпуск языка программирования Rust 1.34"	–1 +/–
Сообщение от Аноним (108), 15-Апр-19, 05:43
Мужики, этот язык можно использовать без использования сети aka dependence hell? Тупо поставил, и пишешь как в devc++, без всякой прочей хрени.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	132. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от Ретроград (?), 15-Апр-19, 11:53
	Внезапно можно, просто придется писать для каждой С-функции extern-обертку.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	146. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от JustCurious (?), 15-Апр-19, 16:45
	Очень странно слышать аргумент про dependency hell в пользу С++, да еще и против Rust. Но на всякий случай, если не троллите, для использования стандартной библиотеки интернет не нужен, и она тут побогаче чем в С++ (как минимум есть модули fs и net для работы с файловой системой и сетью соответственно, в С++ std::filesystem появился только в С++17, а сетевых примитивов до сих пор нет). Так что можете тупо поставить и писать, как в С++. А для загрузки зависимостей - так и в С++ мы же их все с интернета загружаем, просто в линуксе мы привыкли это делять системным пакетным менеджером, а на других платформах свои велосипеды. Если уж нужно указать зависимость с локального хранилища, конечно же Cargo это умеет: https://doc.rust-lang.org/cargo/reference/specifying-depende...
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

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

	154. "Выпуск языка программирования Rust 1.34"	–1 +/–
	Сообщение от Аноним3 (?), 15-Апр-19, 22:58
	у меня схожие ощущения были когда читал по D. там тоже все странно.
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	160. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Junior frontend developer (?), 16-Апр-19, 22:13
	> От синтаксиса блевать тянет, даже книжку дочитать не смог... Никак не могу понять чем людям синтаксис не угодил? Типичный сиподобный язык с современными влияниями из ML. Самый же что ни на есть дружелюбный и современный синтаксис, как тот же TypeScript или Kotlin
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	163. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от burjui (ok), 17-Апр-19, 11:51
	Понимаете, есть такая категория людей - приплюснутые. У них в череп только один вид синтаксиса влазит. Вот этот товарищ даже книжку дочитать не смог - так мозг от напряжения раздуло. Таких от Lisp нужно держать подальше во избежание порчи имущества разлетающейся мозговой тканью.
	Ответить | Правка | ^ к родителю #160 | Наверх | Cообщить модератору

172. "Выпуск языка программирования Rust 1.34"	+/–
Сообщение от Аноним (-), 20-Апр-19, 19:45
Я Раст "ниасилил", что мне делать? Синтаксис очень сложный. Зачем нужны 2 вида переменных: которые можно изменять и, которые нельзя изменять. Это что за наркота? Разве не достаточно на все случаи жизни иметь всего 2 квалификатора типа: пременная (потенциально изменяемая) и константа (совершенно не изменяемая).
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	174. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноним (149), 22-Апр-19, 16:41
	пиши на питоне, там вообще констант нет
	Ответить | Правка | ^ к родителю #172 | Наверх | Cообщить модератору

	175. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Junior frontend developer (?), 23-Апр-19, 00:36
	> Зачем нужны 2 вида переменных: которые можно изменять и, которые нельзя изменять. > Это что за наркота? Разве не достаточно на все случаи жизни > иметь всего 2 квалификатора типа: пременная (потенциально изменяемая) и константа (совершенно > не изменяемая). В расте так и есть. Неизменяемая по умолчанию, так как она проще и хорошая практика, поэтому изменяемая использует 2 слова, вместо const. Есть конечно отличие в том, что этот модификатор изменяет поведение не только самой переменной, но и всего контента. Язык построен вокруг идеи контролируемой изменяемости.
	Ответить | Правка | ^ к родителю #172 | Наверх | Cообщить модератору

	176. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноним (-), 24-Апр-19, 04:29
	>В расте так и есть... Стоп! Погоди, а для чего нужен модификатор по имени "const", который имеется в в языке? По моему он должен быть на месте "неизменяемой по умолчанию" переменной. Растаманы плодят сущности?
	Ответить | Правка | ^ к родителю #175 | Наверх | Cообщить модератору

	177. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Аноним84701 (ok), 24-Апр-19, 11:58
	>>В расте так и есть... > Стоп! Погоди, а для чего нужен модификатор по имени "const", который имеется в в языке? > По моему он должен быть на месте "неизменяемой по умолчанию" переменной. Растаманы плодят сущности? Глупые и самонадеянные потому что - не спросили заранее на опеннете, как нужно правильно :( Вместо этого сделали и написали что-то, зачем-то в документацию, где даже разъяснили разницу : https://doc.rust-lang.org/reference/items/constant-items.html https://doc.rust-lang.org/stable/book/ch03-01-variables-and-... > Like immutable variables, constants are values that are bound to a name and are not allowed to change, but there are a few differences between constants and variables. > First, you aren’t allowed to use mut with constants. Constants aren’t just immutable by default—they’re always immutable. > You declare constants using the const keyword instead of the let keyword, and the type of the value must be annotated. > Constants can be declared in any scope, including the global scope, which makes them useful for values that many parts of code need to know about. > The last difference is that constants may be set only to a constant expression, not the result of a function call or any other value that could only be computed at runtime. > Хипстота, что с нее взять.
	Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

	178. "Выпуск языка программирования Rust 1.34"	+/–
	Сообщение от Junior frontend developer (?), 24-Апр-19, 18:16
	> Стоп! Погоди, а для чего нужен модификатор по имени "const", который имеется > в в языке? По моему он должен быть на месте "неизменяемой > по умолчанию" переменной. Растаманы плодят сущности? Это вообще специфический случай для полностью статического значения как по значению, так и по памяти.
	Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

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

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