Rust 1.21

Шото старый for мне как-то нравился больше 8)

Почему в прошедшем времени?

Шо, опять? Еще старый срач не остыл.

(0..10).for_each(|i| println!(«{}», i));

Ну пипец, кто-то обкололся рубями.

Лол. Нахуа в языке системного программирования говно вроде этого for_each, а также всяких map, filter и иже с ними? Чтобы задавать побольше тупых вопросов об аллокациях при использовании этого шлака на собеседованиях?

let x = &5;

rvalue-ссылки из c++?

Каких аллокациях?

Почему в прошедшем времени?

Плохо построил предложение.

Мне это почему-то напоминает перл, с его чудными

die("we are so fucking dead oh noes fatal errors herp derp") unless ($everything_is_ok);

Нахуа в языке системного программирования говно вроде этого for_each, а также всяких map, filter и иже с ними? Чтобы задавать побольше тупых вопросов об аллокациях при использовании этого шлака на собеседованиях?

У них «ненастоящий» map, если под настоящим понимать map из функциональных языков (откуда он и пришёл).

Rust-овский map это mapM из хаскеля. А новый for_each это mapM_.

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

Я только закончил 1.20 собирать.

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

Насколько я знаю, rustc - однопоточный. Cargo собирает крейты параллельно, но не модули.

В чем причина - хз.

Какая-то смесь Руби и Си++.

Авторов^W Компилятор в спешке делали.

Какая-то смесь Руби и Си++.

Ты вообще не в курсе, как язык работает, да?

https://www.ncameron.org/blog/how-fast-can-i-build-rust/

There is a disadvantage, however: using multiple codegen units means the program will not be optimised as well as if a single unit were used. This is analogous to turning off LTO in a C program.

The compilation unit in Rust is a crate; that is, the Rust compiler analyses and compiles a single crate at a time.

7 лет - это в спешке? ~50% времени все равно отжирает llvm.

7 лет - это в спешке? ~50% времени все равно отжирает llvm.

Я думаю, что большая часть времени у них ушла на проектирование языка и прототипы. Вопросами параллельной сборки они вряд-ли тогда заморачивались.

Ты вообще не в курсе, как язык работает, да?

Да. Но мне не стыдно, я ж не пишу на нём ;) А что ты имел ввиду?

Да. Но мне не стыдно, я ж не пишу на нём ;) А что ты имел ввиду?

То, что от руби этот язык далек настолько, насколько это вообще возможно.

Обычно пишут, что смысла от распараллеливания мало. Мол проще не заморачиваться.

Они пытаются выехать на инкрементальной сборке.

Языки ассемлера или Фортран - дальше.

А на Руби похоже такой записью:

(0..10).for_each(|i| println!(«{}», i));

Обычно пишут, что смысла от распараллеливания мало. Мол проще не заморачиваться.

Не работает — не нужно :D С другой стороны, если не быть ослом и разбивать на мелкие crate'ы (а не как в C++), то действительно пофиг.

Они пытаются выехать на инкрементальной сборке.

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

Он видит похожий (на самом деле нет) синтаксис и думает, что языки похожи.

Смысл собирать в контейнере при разработке? А билд сервер пусть шуршит. Он для этого и нужен.

Не работает — не нужно

Эксперименты были, профита - нет.

Он видит похожий (на самом деле нет) синтаксис

А на самом деле что? Вот это говно

(0..10).for_each(|i| println!("{}", i));

О, вспомнил, на самом деле раст это окамл. Так сказал ребе тылганер. Веруйте!

А на Руби похоже такой записью:

Как будто синтаксис Руби — это что-то плохое.

Лол. Нахуа в языке системного программирования говно вроде этого for_each, а также всяких map, filter и иже с ними?

Ты забыл объяснить, почему все эти комбинаторы — говно.
Нужны они (и остальные замечательные и полезные комбинаторы) чтобы работать с итераторами. Итератор выдаёт итемы типа Option<T>: или Some(T), или None. Чтобы не пердолиться в цикле (псевдокод):

let mut v = Vec::new();
for i in <Iterator> {
    match i {
        Some(T) => v.push(func(i)),
        None => break
    }
}

используем элегантный map, который выполняет матчинг за нас:

let v: Vec<T> = <Iterator>.map(|i| func(i)).collect(); // здесь вдобавок вектор `v` можно создать неизменяемым, в отличие от ручного пердолинга в первом варианте

Теперь код let x = &5 будет эквивалентен этому:

static FIVE: i32 = 5;
let x = &FIVE;

Хорошо хоть этот код не запускает ядерную бомбу. Локальная привязка создает глобальную, мда.

Ты забыл объяснить, почему все эти комбинаторы — говно.

А хотя бы возьми свой «элегантный» пример, но не тупо пропускай None-ы, а считай их число. Цикл останется почти неизменным, а комбинатор твой?

Потому что вы, функциональщики, не особо понимаете, что такое программирование, а вместо этого считаете строчки. Только это как спички, один в один. В реальном мире мы просто пишем компоненты с фиксированными интерфейсами и потом соединяем их.

А когда функциональщики добираются до реальных задач, получается Spark, в котором даже нельзя в один проход раскидать разные данные по разным приёмникам, как раз из-за вашего (прямого аналога) map.

А в чём проблема? Константная ссылка на константу. Внезапно, питон точно так же поступает для небольших чисел.

Ты забыл объяснить, почему все эти комбинаторы — говно.

А хотя бы возьми свой «элегантный» пример, но не тупо пропускай None-ы, а считай их число. Цикл останется почти неизменным, а комбинатор твой?

Извини, я забыл, что критиканы хаят Rust, не зная его. None сигнализирует о том, что итерация закончилась, поэтому кол-во None всегда равняется 1.

Я не знаю, кто такие функциональщики, и почему я один из них, и тем более мне нет дела до какого-то там Spark и твоей попаболи относительно его существования, но могу констатировать, что факт того, что в приведенных мною примерах map способствует сокращению кода, ускользнул от твоего внимания.

Внезапно, питон точно так же поступает для небольших чисел.

Знаю. Кажется диапазон захватывает значения от -5 до 255. Но тот факт, что на Филиппинах еще 50 лет назад кушали людей, не оправдывает людоедства вообще, к примеру. В Питоне так сделали оптимизации ради, уменьшить накладные расходы для наиболее используемых чисел, в качестве, например, индексов.

А хотя бы возьми свой «элегантный» пример, но не тупо пропускай None-ы, а считай их число.

А когда функциональщики добираются до реальных задач, получается Spark, в котором даже нельзя в один проход раскидать разные данные по разным приёмникам, как раз из-за вашего (прямого аналога) map.

Давай ты нормально поставишь задачу? Посмотрим, как она будет решаться в функциональном стиле. Только не забудь написать её решение в императивном стиле, чтобы было понятно, о чём же всё-таки речь. Иначе всё это останется необоснованным набросом.

using multiple codegen units means the program will not be optimised as well as if a single unit were used.

Т.е. они не осилили whole program optimization. Грустно, что. Надеюсь, это когда-нибудь починят.

Языки ассемлера или Фортран - дальше.

Ассемблер — не язык. Это формат записи. В Fortran таки к Ruby поближе будет. В них обоих, в отличии от Rust, есть это ваше ООП из коробки, например.

используем элегантный map

Ладно map, это бывает удобно. Но foreach бредовый зачем? Теперь вся хипстота будет именно так писать везде вместо скучного фора, вот увидишь.

Так wpo как раз по умолчанию.

Кстати, что там с моим любимым перлизмом, не запилили еще такое:

do_this && do_that && do_yet_another_cool_trick || do_something_else unless puk

используем элегантный map

Ладно map, это бывает удобно.

Иногда? Угу.

Зачем for_each? Для единообразия:

// old
for i in (0..100).map(|x| x + 1).filter(|x| x % 2 == 0) {
    println!("{}", i);
}

// new
(0..100)
    .map(|x| x + 1)
    .filter(|x| x % 2 == 0)
    .for_each(|i| println!("{}", i));

Люблю такие примеры арифметические. Где еще применишь эти дурацкие цепочки. Правильно, нигде. Нужно слегка усложнить логику и ты уже бежишь переделывать красоту на пердольный цикл.

Эти операции нельзя перегрузить в Rust, поскольку они вычисляют правый операнд, только если это необходимо. Например, если в do_this && do_that do_this не является истиной, то do_that вычисляться не будет. Поскольку на это поведение нельзя повлиять, то и перегружать их нет смысла, а значит нельзя.

Доколе! Уже и до C++ добралась эта хипстота! C 98 года разлагают C++, но он выстоит!

Дошло, что ерунду написал :). В for на самом деле никакого match тоже не будет. Но ручное заполнение вектора останется,от этого map освобождает действительно.

Там сначала хвостовой unless вычисляется, и если никто не пукнул, то мегаоднострочник вообще не исполнится. Такая кулфича.

С 98 года разлагают C++, но он выстоит!

Не выстоял. Современый цепепе уже на всю голову хипстанутый. А добавляет угару возможность писать одновременно в олдовом стиле. Можно чередовать: хипстофункция, одфажкофункция. Прикольно, особенно под веществами.

Люблю такие примеры арифметические. Где еще применишь эти дурацкие цепочки. Правильно, нигде. Нужно слегка усложнить логику и ты уже бежишь переделывать красоту на пердольный цикл.

Давай конструктив. Пили пример «усложнённой логики» в императивном стиле, а мы тебе постараемся в функциональном стиле это переписать. Иначе останется набросом.

Чоо

Серьёзно, вместо того, чтобы заканчивать итерацию, когда закончилась итерация, они каждый раз возвращают Option?

вместо того, чтобы заканчивать итерацию, когда закончилась итерация

А когда закончилась итерация? Как итератору подать сигнал, что всё, хватит меня дергать, я всё отдал, что было? Option это как раз удобный способ подавать сигнал конца итерации.