LINUX.ORG.RU

Rust 1.27

 


3

10

Команда разработчиков языка Rust рада представить новую версию Rust 1.27.0. Rust — системный язык программирования, ориентированный на безопасность, скорость и параллельность.

Основные изменения:

  • SIMD — наиболее значимое и ожидаемое нововведение: стабильная версия Rust обзавелась базовой поддержкой SIMD.
    Для примера использования рассмотрим следующий сниппет:
    pub fn foo(a: &[u8], b: &[u8], c: &mut [u8]) {
        for ((a, b), c) in a.iter().zip(b).zip(c) {
            *c = *a + *b;
        }
    }
    
    Здесь мы берем два слайса, складываем числа в них и помещаем результат в третий слайс. Самый простой способ, описанный выше — это проход в цикле по каждому слайсу, сложение и сохранение результата. Впрочем, это можно сделать быстрее и в LLVM может автовекторизовать такой код, подставив SIMD инструкции автоматически.

    Стабильный Rust уже давно использует возможности автовекторизации LLVM, но, к сожалению, компилятор может использовать подобные оптимизации не всегда. В Rust 1.27.0 добавлен модуль std::arch, включающий базовую поддержку использования инструкций SIMD напрямую из кода на Rust. Кроме того, добавлены соответствующие директивы условной компиляции:

    #[cfg(all(any(target_arch = "x86", target_arch = "x86_64"),
          target_feature = "avx2"))]
    fn foo() {
        #[cfg(target_arch = "x86")]
        use std::arch::x86::_mm256_add_epi64;
        #[cfg(target_arch = "x86_64")]
        use std::arch::x86_64::_mm256_add_epi64;
    
        unsafe {
            _mm256_add_epi64(...);
        }
    }
    
    В примере выше флаги cfg позволяют выбрать правильную версию функции в зависимости от целевой архитектуры во время компиляции. Также мы можем это сделать в рантайме:
    fn foo() {
        #[cfg(any(target_arch = "x86", target_arch = "x86_64"))]
        {
            if is_x86_feature_detected!("avx2") {
                return unsafe { foo_avx2() };
            }
        }
    
        foo_fallback();
    }
    

    Примитивы, включенные в стандартную библиотеку обеспечивают минимальную поддержку и весьма низкоуровневы, но их включение позволяет развивать более выкокоуровневые примитывы в библиотеках. К примеру, крейт faster предоставляет удобный интерфейс, основанный на концепции итераторов.

    Без SIMD

    let lots_of_3s = (&[-123.456f32; 128][..]).iter()
        .map(|v| {
            9.0 * v.abs().sqrt().sqrt().recip().ceil().sqrt() - 4.0 - 2.0
        })
        .collect::<Vec<f32>>();
    

    С SIMD (faster)

    let lots_of_3s = (&[-123.456f32; 128][..]).simd_iter()
        .simd_map(f32s(0.0), |v| {
            f32s(9.0) * v.abs().sqrt().rsqrt().ceil().sqrt() - f32s(4.0) - f32s(2.0)
        })
        .scalar_collect();
    

  • dyn Trait

    Изначальный синтаксис трейт-объектов в Rust — одна из тех вещей, о введении которых мы жалеем: для некоторого трейта Foo, его трейт-объект будет выглядеть так: Box<Foo>

    И если Foo является структурой, синтаксис аллокации структуры в «куче» будет выглядеть точно так же.

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

    То же самое справедливо для случая impl SomeTrait for SomeOtherTrait, что является корректным синтаксисом, но интуитивно понимается как реализация трейта SomeTrait для всех типов, реализующих SomeOtherTrait, но на самом деле это записывается как impl<T> SomeTrait for T where T: SomeOtherTrait, в то время как первый вариант является реализацией трейта для трейт-объекта.

    Кроме того, появление impl Trait в противовес Trait ввело некую неконсистентность при обучении языку.

    Исходя из этого, в Rust 1.27 мы стабилизируем новый синтаксис dyn Trait.
    Теперь трейт-объейты выглядят так:

    // old => new
    Box<Foo> => Box<dyn Foo>
    &Foo => &dyn Foo
    &mut Foo => &mut dyn Foo
    

    То же самое применимо к другим типам указателей:
    Arc<Foo> теперь объявляется как Arc<dyn Foo>.

    Исходя из требований к обратной совместимости, мы не можем удалить старый синтаксис, но мы добавили предупреждение компилятора, призывающее обновить синтаксис для трейт-объектов. Пока что оно выключено по умолчанию.

  • #[must_use] для функций
    Наконец, атрибут #[must_use] получил новые возможности: теперь он применим к функциям.

    Раньше он использовался только на типах, таких как Result<T, E>, где возвращаемое значение должно быть использовано, но теперь возможно такое применение:

    #[must_use]
    fn double(x: i32) -> i32 {
        2 * x
    }
    
    fn main() {
        double(4); // warning: unused return value of `double` which must be used
    
        let _ = double(4); // (no warning)
    }
    

    Также этот атрибут был добавлен к некоторым функциям в стандартной библиотеке, таким как Clone::clone, Iterator::collect и ToOwned::to_owned, теперь компилятор предупредит в случае, если их результат останется неиспользованным, что поможет заметить и предотвратить случайный вызов затратных операций.

Стабилизация стандартной библиотеки

Новые возможности Cargo

В текущем релизе в Cargo включены два маленьких нововведения:

Во-первых, Cargo теперь принимает флаг --target-dir.

Во-вторых, Cargo теперь будет пытаться автоматически найти тесты, примеры и исполняемые файлы (прим. бинарные подпроекты в библиотечных крейтах) в проекте, но явная конфигурация всё же будет требоваться в некоторых случаях.

Для помощи в конфигурации мы добавили несколько ключевых слов в Cargo.toml.

Обновить Rust можно с помощью команды:

curl https://sh.rustup.rs -sSf | sh # если у вас еще не установлен rustup
rustup update stable

>>> Подробности

★★★★★

Проверено: tailgunner ()
Последнее исправление: cetjs2 (всего исправлений: 5)
Ответ на: комментарий от RazrFalcon

Ну стандартная вещь — какой-нибудь скрипт для бекапа, что ты делаешь? В баше ты поперемещал файлики, запустил tar, всё ок. В питоне ты импортишь shutil, импортишь tarfile / subprocess, пишешь ненужную херню всякую...

WitcherGeralt ★★
()
Ответ на: комментарий от WitcherGeralt

Я не пишу скрипты бекапа, тем более на баше. Мне rsync хватает.

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

RazrFalcon ★★★★★
()
Ответ на: комментарий от WitcherGeralt

А завтра захотел бэкапить несколько папок в разные архивы, причем раскладывая эти архивы по дням недели. А инфу о неудавшихся бекапах складывать в лог вместе с выводом stderr. И отправлять результат на почту если ошибки были

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

Имелось ввиду, что дата в имени файла присутствует.

С таким туманным требованием - man sort. А вообще, проектирование структур данных решает. Даже в шелл-скриптах.

tailgunner ★★★★★
()
Ответ на: комментарий от RazrFalcon

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

anonymous
()
Ответ на: комментарий от RazrFalcon

Ну на внешний носитель я тоже с rsync копирую (не руками), плюс кое чего-то упаковать нужно, чтобы меньше весило и сохранялись версии, а часть уходит в проприетарное облако, куда rsync не пускают. Ничего такого, всё простенько.

На баше?

Крон, файнд, где проблема-то?

WitcherGeralt ★★
()
Ответ на: комментарий от RazrFalcon

Имелось ввиду, что дата в имени файла присутствует.

С таким туманным требованием - man sort

sort умеет сортировать по произвольному формату данных?

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

tailgunner ★★★★★
()
Ответ на: комментарий от WitcherGeralt

Крон, файнд, где проблема-то?

Читер! Давай на баше без внешних команд, иначе нещитово!!!11

anonymous
()
Ответ на: комментарий от tailgunner

С чего такие выводы? Я даже функции на нём писал когда-то. Помнится был скрипт на строк 400.

Ну и тут извечный вопрос что считать башем: сам язык или unix утилиты + bash.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

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

С чего такие выводы?

Вот с^Wиз таких высказываний:

RazrFalcon> Ну и тут извечный вопрос что считать башем: сам язык или unix утилиты + bash.

Просто в рамочку и на стену: шелл - это баш, Unix-утилиты - нечто отдельное. Вендовое прошлое (и настоящее)?

Я даже функции на нём писал когда-то

Что такое «функции» -

myfunc() { чототам; }
? Ну да, это показатель.

tailgunner ★★★★★
()
Ответ на: комментарий от RazrFalcon

Вендовое прошлое (и настоящее)?

Опять мимо. 8 лет на лине. 6 на генту.

Я имел в виду твою основную работу.

tailgunner ★★★★★
()
Ответ на: комментарий от WitcherGeralt

Зато сколько мусора в питоне, когда просто нужно пустить сабпроцесс.

воспользуюсь случаем попиарить xonsh

MyTrooName ★★★★★
()
Ответ на: комментарий от RazrFalcon

Тогда я не могу объяснить очевидный факт :)

tailgunner ★★★★★
()
Ответ на: комментарий от WatchCat

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

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Тем, что bash,sh,zsh,etc. это языки командной строки.
И если ты пишешь my_cool_prog param1 param2, то ты передаёшь в программу строки «param1» и «param2», а не значения переменных param1 и param2.
Так исторически сложилось. Так удобнее большинству кто работает в командной строке.
Можно конечно написать свой шелл с БДиШ, где задавать строки только через «» или ", но кому он нафиг сдался будет?

WatchCat ★★★★★
()
Ответ на: комментарий от WatchCat

К экранированию строк и переменных у меня вопросов нет. На убогую работу со списками это не влияет.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Не-не-не, Дэвад Блейн.
Ты говорил про синтаксис, который «может быть проще».
Чем a=( 1 2 3 ) сложнее a=[ 1, 2, 3]?
А echo ${a[1]} сложнее print(a[1])? С учётом того, что «К экранированию строк и переменных у меня вопросов нет.»(цы)

WatchCat ★★★★★
()
Ответ на: комментарий от WatchCat

Чем echo ${a[1]} сложнее print(a[1])?

тем, что в первом случае это echo и ${a[1]}, а во втором - print() и a[1], очевидно же

и еще ты заставил цикл for исчезнуть

MyTrooName ★★★★★
()
Последнее исправление: MyTrooName (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

А что тебе в том цикле?
Обычный for in.
${a[@]} обозначает все записи в массиве.
Взятие в кавычки - экранирование пробелов, чтобы "a b" не превратилось в "a" "b"
Хотя в том случае это и не обязательно.
Или у тебя претензии к for i in ...; do :; done; ?

WatchCat ★★★★★
()
Последнее исправление: WatchCat (всего исправлений: 2)
Ответ на: комментарий от tailgunner

find . -atime +30 | xargs rm

ага, особенно директория (чтобы пораньше выдалась) "-r" + файл: "... /полезная-директория"

anonymous
()
Ответ на: комментарий от WatchCat

Моя претензия к количеству синтаксического мусора.

a=( 1 2 3 )
echo ${a[1]}
for i in "${a[@]}"; do
    echo ${i}
done

vs

a = [ 1, 2, 3 ]
print(a[1])
for v in a:
    print(v)

RazrFalcon ★★★★★
()
Ответ на: комментарий от MyTrooName

Т.е. синтаксис 'for' ты не в курсе?

Всё ясно - никаких обоснованных претензий нету, но прикопаться хочется.

WatchCat ★★★★★
()
Ответ на: комментарий от RazrFalcon

Моя претензия к количеству синтаксического мусора

К экранированию строк и переменных у меня вопросов нет

Ты уж определись.

WatchCat ★★★★★
()
Ответ на: комментарий от WatchCat

Всё ясно - никаких обоснованных претензий нету, но прикопаться хочется.

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

MyTrooName ★★★★★
()
Ответ на: комментарий от WatchCat

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

anonymous
()
Ответ на: комментарий от MyTrooName

Нет. Запишем то, что ты дурак и не знаешь предмет спора.

WatchCat ★★★★★
()
Ответ на: комментарий от anonymous

Ты не выпендривайся. Ты пальцем покажи.

WatchCat ★★★★★
()
Ответ на: комментарий от RazrFalcon

в bash синтаксис шагает от командно-строчной природы - понимать надо. он никогда не задумывался как полноценный ЯП

anonymous
()
Ответ на: комментарий от anonymous

Еще и изворачивались, чтоб сохранить обратную совместимость с sh. Прям как VimL — уродливый наследник командного режима vi.

makoven ★★★★★
()
Ответ на: комментарий от makoven

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

anonymous
()
Ответ на: комментарий от tailgunner

ЯННП, но у меня в rm точно нет опции -r.

touch 'dir ' ./' -r'; find . | xargs printf '%s\n' — а rm может удалить что-нибудь левое (выше у меня криво, но не принципиально)

anonymous
()
Ответ на: комментарий от anonymous

И только раст вырвиглазен просто так, без особых причин.

Нужно прокачать IQ немножко и всё станет понятно.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Нужно прокачать IQ немножко и всё станет понятно.

Так и про брейнфак можно сказать. Но ты вот почему то питон выбрал, а не перл. Странно, ведь если прокачать IQ на полшишечки, то в перле все понятно. Наверно ты тупой.

anonymous
()
Ответ на: комментарий от anonymous

Если производительность не важна - можно озаботится чистотой синтаксиса.

Надеюсь сам сможешь развить мысль.

RazrFalcon ★★★★★
()
Ответ на: комментарий от anonymous

Можно ли сказать, что раст такой уродский, от того, что создавался, чтобы быть совместимым с древней процессорной архитектурой и устаревшим как гуано мамонта C ABI?

Вон, java c C# сделали себе уютненькие виртуальные машины и резвятся в них как душе угодно

makoven ★★★★★
()
Ответ на: комментарий от makoven

При чём тут архитектура и C ABI? Rust «компилируется» в LLVM IR. А остальное - проблемы llvm (за редким исключением).

Вон, java c C# сделали себе уютненькие виртуальные машины и тормозят в них как душе угодно

fixed

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Зачем тебе прокачивать IQ? Действительно.
Больше вопросов не имею.

anonymous
()
Ответ на: комментарий от makoven

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

Скорее он создавался, чтобы быть совместимым с затейливыми извилинами мозга крестокодера. Но оказался недостаточно совместимым...

anonymous
()
Ответ на: комментарий от RazrFalcon

Ну когда речь идет про удобные языки, всегда говорят «фуу с программой на этом языке идет „рантайм“». Этот рантайм типа полифилов в js: реализует более лучшую, более современную архитектуру ПК(или ОС?). С более лучшими потоками, с крутым ABI,рефлексией, простым управлением памятью.. От того и языки удобнее

makoven ★★★★★
()
Ответ на: комментарий от makoven

Вебмакаки все такие?

При чём тут архитектура и где это вы нашли «лучшие потоки»? Только не говорите Go.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Я понимаю, что звучит как дичь) Просто хочу донести мысль, что если б такой «рантайм» был общий для всего, от ядра до юзерспейс програм, то язык был бы проще. Ограничения архитектуры накладывают уродливый отпечаток на язык, который создан, чтобы выполняться на этой архитектуре безо всяких рантаймов. Либо уродский аналог C#, зато с современными абстракциями и парадигмами. Либо без парадигм, всё ручками, как в сишке

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 7)
Ответ на: комментарий от makoven

Либо уродский аналог C#, зато с современными абстракциями.

Это в C# более лучшие потоки?

Либо без абстракций, но всё ручками как в сишке

А в Rust нет абстракиций?

tailgunner ★★★★★
()
Ответ на: комментарий от makoven

Архитектуры уже существуют. Остаётся к ним приспосабливаться.

Либо без парадигм, всё ручками, как в сишке

В сишке тоже есть рантайм.

Rust - это попытка показать, что можно современные вкусности сделать без накладных расходов. Есть ещё Zig и Jai, которые ближе к Си.

современными абстракциями и парадигмами

Чего конкретно вам не хватает в Rust?

RazrFalcon ★★★★★
()
Ответ на: комментарий от tailgunner

В C# более чистый синтаксис, в т.ч. из-за GC. А рантайм зеленых потоков в ерланге и го. Так-то ничего не мешает все это ***ьмо, в том или ином виде, запихнуть в ядро или в процессор. Вместе с нормальным форматом dll-ок

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от makoven

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

Если не знать, как оно внутри работает - конечно, ничто не мешает.

tailgunner ★★★★★
()
Ответ на: комментарий от makoven

PS: Вот вы тут рассказываете про современные парадигмы и абстракции, которые есть в языках с рантаймом, а я такой найти не могу.

Мне нужно:

  • GC
  • Рантайм в бинаре. Java, C# отпадают.
  • Функциональщина. Хотя бы на уровне раста.
  • Поддержка всех современных платформ, а не как в Swift.
  • Исключения. Прощай убогий Go.
  • Стабильный. Nim отпадает.

Ваши предложения?

RazrFalcon ★★★★★
()
Последнее исправление: RazrFalcon (всего исправлений: 1)
Ответ на: комментарий от makoven

Тормоз.

Забыл самое главное: строгая, статическая типизация.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Слишком наркоманский. Не мой уровень.

Многие о Rust'е так же говорят только от того, что он слишком непривычный. Для оперденей ничего лучше Haskell не придумали и вряд-ли ближайшие лет 10 придумают.

Nexmean
()
Ответ на: комментарий от Nexmean

Для оперденей ничего лучше Haskell не придумали
оперденей

Шта?!

RazrFalcon ★★★★★
()
Ответ на: комментарий от Nexmean

Для оперденей ничего лучше Haskell не придумали и вряд-ли ближайшие лет 10 придумают.

Для оперденей (и всех остальных прикладных задач) ленивость Хаскела не нужна. Так что лучше Хаскеля придуман как минимум Ocaml.

tailgunner ★★★★★
()
Ответ на: комментарий от Crocodoom

Туторил пробежал, но времени пока нет его детально изучить.

RazrFalcon ★★★★★
()
Ответ на: комментарий от tailgunner

PyPy - это ни разу не функциональщина

А раст это сколько раз функциональщина?

anonymous
()
Ответ на: комментарий от makoven

Тыжпрограмист

Именно поэтому я понимаю сложность задачи и знаю историю вопроса.

неможешь чтоли гринтреды в ядро запихнуть?

Erlang-овые, с инструкциями VM и счетчиком редукций? Не могу.

tailgunner ★★★★★
()
Ответ на: комментарий от RazrFalcon

Я бы предложил Scala Native, но он еще более Preview, чем Kotlin.

Scala Native 0.3.7 released this on Mar 29

theLastOfCats
()
Ответ на: комментарий от Nexmean

C++ привычнее программистам, чем Rust, значит ли это что Rust не следует использовать?

Может быть. Но у Rust есть нужные возможности, отсутствующие в Си++. У Haskell vs Ocaml таких возможностей нет.

tailgunner ★★★★★
()
Ответ на: комментарий от RazrFalcon

Знаешь, таких матерых отполированных язычков как ты хочешь всего 2 (два). И оба managed, чего ты не желаешь по религиозным что-ли мотивам. Так что пока укладывайся в криокамеру на десяток лет, единственно что можно тут посоветовать. Чем D не угодил я так и не вкурил. «Он мертвый кококо» это не аргумент.

anonymous
()
Ответ на: комментарий от anonymous

Чем D не угодил я так и не вкурил.

Я его даже не упоминал. Утихомирите своих тараканов.

Но несмотря на то, что Ди мёртв, у него нет паттерн матчинга.

RazrFalcon ★★★★★
()
Ответ на: комментарий от tailgunner

Может быть. Но у Rust есть нужные возможности, отсутствующие в Си++.

Это какие возможности, можно перечислить? Я в Rust не шарю, но после прочтения части доки он наводил только уныние

navrocky ★★
()
Ответ на: комментарий от navrocky

Но у Rust есть нужные возможности, отсутствующие в Си++.

Это какие возможности, можно перечислить?

Memory safety, ADT + pattern matching, трейты и impl, модули, Cargo.

в Rust не шарю, но после прочтения части доки он наводил только уныние

Тогда оно тебе не нужно.

tailgunner ★★★★★
()
Ответ на: комментарий от Nexmean

C++ привычнее программистам, чем Rust, значит ли это что Rust не следует использовать?

Растоманы начинают что-то подозревать. Правда мазила честно пыталась сделать похоже на C++, но инопланетный гость Гра Йдо Нхоар им поднасрал таки.

anonymous
()
Ответ на: комментарий от tailgunner

У Haskell vs Ocaml таких возможностей нет.

Подробнее, пожалуйста!

Если что, то к «продакшему» haskell сейчас гораздо больше имеет отношения, чем ocaml. И между прочим, в haskell есть и строгие вычисления. Это для тех, кто не в курсе, а таких процентов 98%, или 99%, что влечет за собой как минусы, так и плюсы (да-да, «avoid success at all costs»).

dave ★★★★★
()
Ответ на: комментарий от dave

У Haskell vs Ocaml таких возможностей нет.

Подробнее, пожалуйста!

Ээээ... я не могу рассказать подробнее. А если ты видишь у Haskell перед Ocaml такие же преимущества, как у Rust перед Си++ - расскажи об этом подробнее.

И между прочим, в haskell есть и строгие вычисления. Это для тех, кто не в курсе, а таких процентов 98%, или 99%

И об этом тоже подробнее, пожалуйста. Как же «Being lazy with class»?

tailgunner ★★★★★
()
Ответ на: комментарий от RazrFalcon

ПМ подразумевался под функциональщиной.

У тебя странное представление о функциональщине. Если нужна развитая система типов, то выбор сужается до неприличия. Прямо скажем придется сидеть в петушином углу, зато с крутыми типами. Пиши на жабе/крестах и не выеживайся, петушиная возня не принесет счастья.

anonymous
()
Ответ на: комментарий от tailgunner

Ленивость по умолчанию, а строгие вычисления опциональны. Их надо руками проводить. Это и seq, и deepseq. Это и bang patterns, и прагма UNPACK. Многие типы, такие как ByteString (последовательность байт), имеют две версии - ленивую и строгую. Даже мапы (Map / IntMap) имеют такие версии. Я не говорю про UArray (массивы без боксинга) и соответствующую вещь Data.Vector.Unboxed из нового, но очень популярного пакета vector.

Если брать тип Double, то внутри тела функции он вполне может быть и строгим (как в лиспе), а вот на выходе из функции скорее всего будет thunk, да и то, если эта функция не инлайнится, что далеко не факт. Ну, а если нужен именно строгий вариант, то я бы посмотрел в сторону CDouble - аналог сишного типа double. Подозреваю, что он как раз таки строгий.

Ну, да. Обычно разумно использовать ленивые структуры данных. У них есть свои плюшки, как например, мемоизация и те же fix или mfix, что позволяют задавать рекурсивные вычисления. А в узких по производительности местах вполне можно использовать строгие вычисления, что и успешно делают на Haskell.

dave ★★★★★
()
Ответ на: комментарий от dave

Про лисп я имел в виду, что там на выходе из функции будет тегированное значение, а в haskell - thunk. Такая аналогия.

dave ★★★★★
()
Ответ на: комментарий от dave

Ленивость по умолчанию, а строгие вычисления опциональны. Их надо руками проводить.

Т.е. «если тебе надо, ты можешь сделать eager». Не совсем то, что надо прогерам оперденей - у них и так будет хватать когнитивного диссонанса.

И кстати, ты не ответил на вопрос.

Я ответил, как мог.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Так, Haskell определяют как «программируемую математику». Для средних программистов он не подходит. Что есть, то есть. Но я не вижу в этом ничего плохого.

Кстати, Rust тоже не так прост. Но для новых проектов я лично выбрал бы Rust вместо C++, если бы выбор стоял между ними.

dave ★★★★★
()
Ответ на: комментарий от dave

Кстати, Rust тоже не так прост.

Так в том и дело, что Си тоже не прост. Rust «всего лишь» заставляет явно формулировать всё, что Си-прогер должен гарантировать и так :)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Ну, да, как бывший прогер на C++ могу сказать, что довольно нервозное дело было писать системный код на C++, который еще и работает в режиме 24/7 на серверах. В Rust я вижу, что компилятор может снизить уровень нервозности, если так можно выразиться. Я попробовал Rust, и мне очень понравились его сообщения об ошибках. Часто страхует (конечно, не всегда).

dave ★★★★★
()
Ответ на: комментарий от dave

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

i36_zubov
()
Ответ на: комментарий от i36_zubov

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

Чистейший, незамутнённый здравым смыслом, бред.

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

Crocodoom ★★★★★
()
Ответ на: комментарий от Crocodoom

И с течением времени ситуация шла в обратном направлении: больше абстракций, дальше от железа — чтобы именно человеку было проще и эффективнее думать.

И зачем тогда придумывать новые ЯП бера за основу С/С++ ? Один ЯП ассемблер на стероидах с фичами типа запишем «==» вместо «=» чтобы укоротить количество символов в коде, а другой ну просто образец простоты думанья, для его компиляния и железо нужно выше среднего, чтобы комп сутки не думал.

Napilnik ★★★★★
()
Ответ на: комментарий от i36_zubov

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

Nexmean
()
Ответ на: комментарий от Nexmean

строгий порядок вычислений это намного удобнее и естественнее для человека чем ленивый

может ты еще и код в микрофон начитываешь?

MyTrooName ★★★★★
()
Ответ на: комментарий от WitcherGeralt

Ты видимо перепутал с D. Там по умолчанию наоборот есть GC, но его можно отключить в режиме «Better C»

А в Rust как раз весь цимес в том, что GC становится не нужен, так как есть линейные типы

Crocodoom ★★★★★
()
Последнее исправление: Crocodoom (всего исправлений: 1)
Ответ на: комментарий от Crocodoom

Не перепутал. Я следил за растом когда он только ещё появился, разговоры о gc тогда точно были, и мне казалось, что он в каком-то виде есть. Перестал следить, когда осознал что раст окончательно скатился в функциональщину.

WitcherGeralt ★★
()
Ответ на: комментарий от Crocodoom

но его можно отключить в режиме «Better C»

Чем же он Better, если памятью жонглировать вручную придется

makoven ★★★★★
()
Ответ на: комментарий от Crocodoom

как есть линейные типы

Означает ли это, память потом не нужно вычищать руками?

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

WitcherGeralt ★★
()
Ответ на: комментарий от RazrFalcon

подразумевая отсутствие необходимости рукоблудия с памятью

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

WitcherGeralt ★★
()
Ответ на: комментарий от WitcherGeralt

Перестал следить, когда осознал что раст окончательно скатился в функциональщину.

Где? Где вы все видите функциональщину в раст? Лямбды что ли?

bread
()
Ответ на: комментарий от WitcherGeralt

Он накладывает определенные ограничения. Ваш КО.

RazrFalcon ★★★★★
()
Ответ на: комментарий от bread

Где вы все видите функциональщину в раст?

ADT + pattern matching, HOF, иммутабельность. И лямбды, да.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от makoven

Не бесплатно, что характерно. Производительность ниже чем у Rust.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Связь? Я про нужность исключений. «try!» — это, конечно, не проброс сквозь стек, но ведь обеспечивает же возможность не обрабатывать ошибку на месте.

WitcherGeralt ★★
()
Ответ на: комментарий от makoven

Что оптимизируют? Атомарные операции? Лучше бы сразу с нормальным GC, рантаймом и гринтредами делали, получился бы более-менее нормальный язык, не без проблем вроде ООП конечно, но хотя-бы не то ненужно, что есть сейчас.

Nexmean
()
Ответ на: комментарий от WitcherGeralt

Анонимные функции во всех их видах я как раз очень люблю.

Дык а что тогда не нравится? Я не вижу, чтобы в расте страдали функциональной декомпозицией головного мозга. Внутри функций вообще галимая императивщина с циклами и мутациями.

bread
()
Ответ на: комментарий от RazrFalcon

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

С failure и оператором ? это так сложно делать? Да и вообще для некоторых задач проще взять динамически типизированный Python и ...

Забавно, когда от языка просят типов, а потом - «А ЧТО, А ЗАЧЕМ ЕМУ ТИПЫ, НЕ ХОЧУ ТИПОВ, ХОЧУ КАК В ПИТОНЕ».

Nexmean
()
Ответ на: комментарий от bread

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

WitcherGeralt ★★
()
Ответ на: комментарий от Nexmean

Казалось бы, при чём тут питон?

С failure и оператором ? это так сложно делать?

Это всё равно не исключения.

Мне не нужны исключения в расте, ибо я их в принципе не люблю. Но есть задачи (быдлокод), где удобнее кидать исключения.

RazrFalcon ★★★★★
()
Ответ на: комментарий от makoven

Ловить нужно.

PS: я знаю, что в расте панику можно отловить.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Мой КО почему-то постоянно несёт бредятину не в тему.

Уточню для КО, который почему-то в очевидность как раз таки не умеет:

быдлокод

питон

Питон идеально подходит для наколеночных, либо не очень наколеночных, но при этом простых, вещей.

WitcherGeralt ★★
()
Ответ на: комментарий от WitcherGeralt

Да, линейные типы и синтаксис параметров времени жизни. Ничего нового в этой претензии нет. Тем не менее за все время никто адекватного решения так и не предложил.

Nexmean
()
Ответ на: комментарий от RazrFalcon

Ничего сложнее «Привет, Мир» на расте не писал. Хотел спросить, насколько муторно составлять эти enum-ы в реальных програмах?

Если либ много, у всех разные виды ошибок. Написать функцию, в которой вызываются функции из разных либ наверное то еще удовольствие? Наверное нехилый такой объем кода придется написать чтобы всё это обработать?

makoven ★★★★★
()
Последнее исправление: makoven (всего исправлений: 1)
Ответ на: комментарий от makoven

Муторность - понятие субъективное. Кода больше, чем при использовании исключений. Но это плата за статические гарантии.

Если вам нужен надёжный софт - приходится страдать.

RazrFalcon ★★★★★
()
Ответ на: комментарий от makoven

Если либ много, у всех разные виды ошибок. Написать функцию, в которой вызываются функции из разных либ наверное то еще удовольствие? Наверное нехилый такой объем кода придется написать чтобы всё это обработать?

Собственно в функции придётся писать ? после каждого вызова функции, которая может вернуть ошибку. Определить этот enum не проблема при условии использования error-chain или failure. Будет у тебя один модуль на 20 строк кода для определения своего типа ошибки, к которому преобразуются все ошибки из сторонних либ и всё, думаю это не так много.

Nexmean
()
Ответ на: комментарий от makoven

хотел спросить, насколько муторно составлять эти enum-ы в реальных програмах?

В быдлокодинге такой подход вообще не катит. Видел стеки вызовов типичной жабской проги? А теперь представь, что мы протаскиваем ошибки вручную по всему этому стеку. Немножко жесть. Вот на го не пишут особо навороченной фигни и то там треть кода портянки с обработкой ошибок. В расте уж как плясали вокруг ошибок, придумали уже несколько способов борьбы с этой сложностью, все равно получается уныло. Зато надежно. Если у тебя глубина стека не превышает 2, то норм конечно. Только либы и писать на таких языках.

bread
()
Ответ на: комментарий от bread

Вот на го не пишут особо навороченной фигни и то там треть кода портянки с обработкой ошибок. В расте уж как плясали вокруг ошибок, придумали уже несколько способов борьбы с этой сложностью, все равно получается уныло. Зато надежно. Если у тебя глубина стека не превышает 2, то норм конечно.

А ты практикующий программист на Go или на Rust?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

А ты практикующий программист ...?

Нет конечно же. Смотри профиль.

bread
()
Последнее исправление: bread (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.