Актуально ли сейчас изучать раст для написания игры на Amethyst? У них на главной странице уже больше недели визуальный баг, на самом верху, коммиты вроде бы не очень частые, создается такое впечатление, что работают над ним не очень активно. В roadmap огромное количество нереализованных фич, назначенных на конец прошлого года.

Автор написанного на языке Rust web-фреймворка actix-web удалил репозиторий после того, как на него обрушилась критика за «неправильное использование» языка Rust. Фреймворк actix-web, пакет с которым был загружен более 800 тысяч раз, позволяет встраивать в приложения на языке Rust функциональность http-сервера и клиента, при разработке ориентирован на достижение максимальной производительности и лидирует во многих тестах web-фреймворков.

Незадолго до инцидента в issues на GitHub было сообщено о выявлении неопределённого поведения (Undefined Behaviour) в коде сервера actix-web, возникающего в блоке, выполняемом в режиме unsafe (допускает выполнение небезопасных действий с указателями). Автор actix-web не стал убирать блок unsafe, но переделал вызов этого блока, чтобы неопределённое поведение не возникало. Предложения убрать unsafe автор отклонил, ссылаясь на возможную потерю производительности и заявив, что он не использует unsafe без необходимости и уверен в безопасности работающих в данном режиме блоков.

Участник команды RustSec, который выявил неопределённое поведение, не согласился и предположил, что применение многих unsafe-блоков в actix-web неоправданно. После этого он опубликовал статью о недопустимости использования unsafe, в которой, среди прочего было упомянуто, что применяемый в actix-web приём работы с указателями (несколько изменяемых указателей на одни и те же данные) потенциально может стать причиной возникновения уязвимостей use-after-free и не соответствует парадигме разработки на Rust.

После обсуждения статьи на Reddit, в issues на GitHub набежали тролли и автор actix-web был подвергнут шквалу критики и оскорблений за неправильное использование Rust. Автор не выдержал психологического давления, удалил репозиторий и написал, что завязал с Open Source.

http://www.opennet.ru/opennews/art.shtml?num=52208

вот ещё текст на ангельском если кому интересно: https://github.com/actix/actix-web

Log удаленной issue из-за которой всё началось: https://gist.github.com/pcr910303/d7722a26499d0e9d2f9034a06f2433b4

Обсуждение на английском:

1. https://news.ycombinator.com/item?id=22073908
2. https://news.ycombinator.com/item?id=22075076

Статья: https://words.steveklabnik.com/a-sad-day-for-rust

У меня есть структура с f64 и я хочу сортировать структуры, почему Ord не реализован для f64? В документации написано, что PartialOrd это «Trait for values that can be compared for a sort-order.». Этот трэйт реализован для f64, но вектор не хочет сортировать даже чистые f64. Получается, что PartialOrd не достаточно для сортировки, тогда зачем PartialOrd? И какой есть простой способ реализовать Ord для f64?

Дорогие юзеры OpenBSD. из-за того, что слишком сложно сделать пакет для Firefox (благодаря cbindgen и раст зависимостям) на стабильной ветке (так как это потребует тестирования всех потребителей раста) стабильная ветка 6.6 не будет получать обновления для www/mozilla-firefox..

https://undeadly.org/cgi?action=article;sid=20200109141600

Понятия не имею, что за «потребители раста» и зачем их тестировать

Доброго времени суток.

Примерно полгода назад, когда я начинал изучать Rust, я обнаружил в нем фатальный недостаток - отсутсвие крейта, который бы реализовывал удобный и кроссплатформенный UI. Хотелось поддержки Linux/Windows/MacOS/WASM-web/Android/iOS и удобства использования уровня Qt с их сигналами-слотами.

В ходе парочки бессоных ночей (на самом деле намного больше) появилась некоторое количество крейтов, которые позволяет писать UI вот так:

#[derive(UWidget)]
struct MyWidget {
    #[uwidget]
    layout: LinearLayout,

    #[public_slot] // у структуры будет публичный метод, через который слот будет доступен снаружи
    #[uprocess(on_text_updated)]
    slot_set_text: SlotImpl<String>,

    slotproxy_set_text: SlotProxy<String>,

    #[uprocess(on_button_clicked)]
    slot_button_clicked: SlotImpl<()>,
}

impl MyWidget {
    pub fn new(placeholder: String) -> MyWidget {
        let slotproxy_set_text;
        let slot_button_clicked = SlotImpl::new();

        let mut layout = LinearLayout::new(Orientation::Horizontal);
        layout.push_widget({
           let textedit = TextEdit::new(placeholder);
           slotproxy_set_text = textedit.slot_set_text().proxy();
           textedit
        });

        layout.push_widget({
            let mut button  = Button::new("Push me");
            button.signal_clicked().connect(&slot_button_clicked);
            button
        });

        return MyWidget{
            layout,
            slot_set_text: SlotImpl::new(),
            slotproxy_set_text,
            slot_button_clicked,
        };
    }

    fn on_text_updated(&self, s: String) {
        self.slotproxy_set_text.exec_for(s);
    }

    fn on_button_clicked(&self, _:()) {
        info!("button clicked!");
    }
}

pub fn new(placeholder: String) -> MyWidget {
    let layout = layout!(
        orientation: Horizontal,
        widget: text_edit!(
        	placeholder: placeholder,
        	slot_set_text: proxy!(slotproxy_set_text),
        ),
        widget: button!(
        	signal_clicked: connect!(slot_button_clicked),
        ),
    );

    return MyWidget{
        layout,
        slot_set_text: SlotImpl::new(),
        slotproxy_set_text,
        slot_button_clicked,
    };
}

Комрады, очень интересно - почему так не популярен Dlang и хайпится Rust?

https://www.beeflang.org/

Особенности:

• По заявлению автора, представляет собой смесь C++ и C#, с небольшими вкраплениями Rust.
• Без GC, JIT и тому подобного.
• Развивается параллельно с IDE (написана на самом beef и собственном тулките). Дизайн языка развивается с учётом удобства разработки IDE.
• Автор делает упор на удобную отладку с помощью дебаггера, а не print.
• Умеет все модные фичи: ADT, pattern matching, лямбды, дженерики, миксины, кортежи, опциональные типы и тд. Но не гарантирует null-safety.
• Поддерживает рантайм рефлексию.
• Не использует исключения. Используется тот же подход что и в Rust: Result + panic.
• Проверяет проблемы с памятью в рантайме в отладочной сборке. В релизной сборке всё как в C/C++.
• Предоставляет лёгкое взаимодействие с C/C++ кодом (не уверен в каком виде).
• Основан на ворованном LLVM. Как будто кто-то сомневался.
• Автор пилит язык последние 5 лет full-time.

Простой пример:

static Result<uint> GetMinusOne(uint i)
{
    if (i == 0)
        return .Err;
    return .Ok(i - 1);  
}

void Use()
{
    /* Handle result via a switch */
    switch (GetMinusOne(i))
    {
        case .Ok(let newVal): Console.WriteLine("Val: {}", newVal);
        case .Err: Console.WriteLine("Failed");
    }

    /* This invokes an implicit conversion operator, which will be fatal at runtime if an error is returned */
    int newVal = GetMinusOne(i);

    /* Result<T> contains a special "ReturnValueDiscarded" method which is invoked to facilitate failing fatally on ignored returned errors here */
    GetMinusOne(i);
}

В целом ближе к D, чем к Rust, так как содержит намного меньше гарантий.

Вот минимальный пример с проблемой: playground

Этому Rust фанатику не хватало результатов чтобы Rust обошёл C++, и он удалил царский код и другие которые использовали mmap. Зато теперь Rust быстрее С++.

Встречайте новость: https://habr.com/ru/post/480608/

Элементарный код.

use std::collections::HashMap;

fn main() {
    let mut test = HashMap::new();

    test.insert(1, "first line");
    test.insert(2, "second line");
    test.insert(3, "third line");
    test.insert(4, "fourth line");


    for (key, value) in &test {
        println!("{}: {}", key, value);
    }
}

Почему-то на выходе:

2: second line
1: first line
4: fourth line
3: third line

Тут выложили обзор фич C# 9, и там очень много ФП и странного синтаксиса (привет WitcherGeralt).

Sum Types:

enum class MixedType  
{  
  Person P;  
  ByteOrBool U;  
}

var person = new Person()  
{  
  Firstname = "Bassam";  
  Lastname = "Alugili";  
};  
  
var unionRecord = new MixedType.P(person);
var unionType1 = new MixedType.U(B true);
var unionType2 = new MixedType.U(Y 86uy);

Pattern matching:

public class GenericClass<T> where T : T1 | T2 | T3 

var crazyCollectionFP = new List<int|double|string>{1, 2.3, "bassam"}; 

var result = x switch { true => "Successful", false => 0 }; 

Типы аля Rust:

public class None {}  
public typealias Option<T> = T | None; 
public typealias Result<T> = T | Exception; 

Некое чудо-юдо для автоматической проверки на null:

void M(List<int> list, uint? u)  
{  
  IEnumerable<int> x = list ?? new[] { 1, 2 };  
  var l = u ?? -1;
}  

Что значит uint? - без понятия.

Проверка аргумента на null:

void DoSomething (string txt!)  
{  
  …  
} 

Lambda discard parameters (хз как перевести):

Func zero = (_,_) => 0;  
(_,_) => 1, (int, string) => 1, void local(int , int);

Атрибуты аргументов (опять как в rust):

static bool LocalFunc([NotNull] data)  
{  
  return true;  
} 

Нативный int:

nint nativeInt = 55; // take 4 bytes when I compile in 32 Bit host.  
nint nativeInt = 55; // take 8 bytes when I compile in 64 Bit host with x64 compilation settings.

nuint nativeUnsignedInt = 55; 

А eao197 говорил, что u32 - это дно. Оказывается нет.

Указатели на функцию (неужели до этого не было?):

unsafe class Example  
{  
  void Example(Action<int> a, delegate*<int, void> f)  
  {  
    a(42);  
    f(42);  
  }  
} 

В целом радует, что идут в сторону ФП и null-safety, но в итоге получаем второй C++, в котором на любой чих есть с десяток конструкций. Что в конечном итоге убивает экосистему.

NIH синдром навсегда? Или что-то реально хотят улучшить?

http://www.opennet.ru/opennews/art.shtml?num=51966

Добрый день.

Недавно начал изучать Rust и вот мне очень нравится писать простенькие интерфейсы. Выбрал для себя sciter.

Собственно пытаюсь скомпилировать dom example. (https://github.com/sciter-sdk/rust-sciter/blob/master/examples/dom.rs)

Все скомпилировалось - запускаю - белое окно.

Далее я просто скопировал исходный код url в файл (http://httpbin.org/html) и поменял функцию c load_file на load_html :

let html = include_bytes!("minimal.htm");
frame.load_html(html, Some("example://minimal.htm"));

Заработало - Т.е. из памяти он отображает html контент. Пробовал запускать с root - тоже самое. Интернет на хосте есть, сайт пингует. Писал на форум sciter - там три дня пост на модерации уже. помогите пожалусто!!!

Наконец в споре производительности языков программирования поставлена точка. Участвовали Haskell, Rust, Go, Standard ML, APL и даже ассемблер. Но программа, написанная на Brainfuck, побеждает в соревновании, показывая производительность C и оставляя далеко позади остальных конкурсантов в лаконичности.

>>,+><[-----------[----------------------[>+<<-[<+>+]>[-]][-]]<[-]>>[<<+>>-]<,+]<[-]<[>>+>+<<<-]>>>[<<<+>>>-]<<+>[<->[>++++++++++<[->-[>+>>]>[+[-<+>]>+>>]<<<<<]>[-]++++++++[<++++++>-]>[<<+>>-]>[<<+>>-]<<]>]<[->>++++++++[<++++++>-]]<[.[-]<]>++++++++++.

https://kiwec.net/blog/posts/beating-c-with-brainfuck/

Немного поизучал Rust, и решил собрать все преимущества заявляемые адептами.

1. Из-за знания компилятором, что & mut - это уникальная ссылка, то параметры функции не будут алиаситься с обычной ссылкой:

fn f(s: & mut str, s2: & str) -> type // s и s2 указывают на разную память, 100% компилятор знает об этом
// в стандарте С++ нет restrict

2. Возможно, большие возможности в compile-time чем у С++, в частности упоминается возможность прочитать файл во время компиляции:

const IMAGE: &[u8] = include_bytes!("/path/some_file.png");

3. Map в rust реализован с помощью алгоритма BTreeMap, а в С++ - std::map красно-чёрное дерево, BTreeMap быстрее…

4. HashMap в rust - открытая адресация, в С++ std::unordered_map - метод цепочек, открытая адресация быстрее…

5. В rust нет объектов, везде используется memcpy, а тот же resize вектора делается через realloc, бысрее чем move конструкторы в С++

помогите дополнить список.

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

Что-то странное происходит. В одном из устаревших проектов для асинхронного ИО в rust romio появился pull request, который добавил в ридми проекта упоминание tokio как более современной альтернативы поддерживающей новый синтаксис async/await (до этого там было лишь упоминание async-std). Спустя некоторое время, автор pull request’а, и все, кто поставил ему палец вверх оказались в бане. Спустя некоторое время реквест таки замержили, и автор репозитория написал пространный коммент, которые среди прочего упоминает о конфликте между разработчиками tokio и async-std.

Pull request https://github.com/withoutboats/romio/pull/106 Коммент - https://github.com/withoutboats/romio/pull/106#issuecomment-548947560

Кто-то в курсе, в чем вообще суть конфликта между tokio и async-std? Очень любопытно об этом узнать. визаутбоатс пишет, что конфликт непубличный, но в эпоху интернета хотя бы часть инфы должна была просочиться. А я тут в танке сидел за новостями не следил.

PS: «My code is written for people of better character than you, go away.» - фонд золотых цитат прямо)

https://parallel-rust-cpp.github.io/introduction.html

Для Ъ. Ржавые пока сливают, но не так чтоб уж совсем.

В этот тихий и спокойный вечер порелизился Rust 1.39.0 с поддержкой async/await.

https://blog.rust-lang.org/2019/11/07/Rust-1.39.0.html

https://blog.rust-lang.org/2019/11/07/Async-await-stable.html

Ещё tokio с actix-ом дождаться, и вообще ждать будет нечего.

Можно ли запустить программу, написанную на языке rust, на компьютерах с процессорами Эльбрус?

Как я понимаю, llvm не рассчитан на такую архитектуру. Правда, есть двоичная трансляция кода. Можно ли рассчитывать хотя бы на 80% скорости по сравнению с тем, как если бы был оптимизирующий родной компилятор с языка rust для Эльбруса?

https://twitter.com/migueldeicaza/status/1188790947934621702

Чё-то мне как-то ссыкотно.