Дочекалися!

Нормальный sum type, вменяемая модульная система, неубогие макросы и стандартный пакетный менеджер.

У меня последние месяцы не хватает сил на LOR. А на тег rust у меня стоит извещение, и я всё-таки захожу посмотреть.

Нормальный sum type

Что это?

вменяемая модульная система

Уже есть. Даже есть тулза modularize. Просто посмотри на llvm.

неубогие макросы

В чём убогость макросов C++? Чем ржавые лучше?

стандартный пакетный менеджер

Ненужно. У нас тут не пхп и не сайт-визитка.

Переходи к нам на js

Эээ, чтобы не дебажить стековерфлоу?

Собрал на stable. /me плачет. Конечно версия Tokio еще альфа

async fn add10(a:i32) -> i32 {
   a + 10
}

async fn f(a:i32, b:i32) -> i32 {
   add10(a).await + add10(b).await
}

#[tokio::main]
async fn main() {
    println!("{}", f(2, 3).await);
}

Просто посмотри на llvm.

Зачем? Я говорил о Си++, а не об LLVM.

Уже есть

Ненужно

Как скажешь.

Ну вот что ты практически будешь с этим делать?

А ты думал. Надо же сбить зарплатные ожидания очкастых задротов

Что это?

Всего лишь современный ЯП

Уже есть. Даже есть тулза modularize

А царь говорил, что модули не нужны

Там пока разброд и шатание, все свою херню проталкивают. Я бенчмаркил это всё (таска по работе была официальная). Очень не однозначно всё, я там целый отчёт на овердохера страниц написал, но он под NDA.

Sum types были еще в Паскале (variant records) :) Действительно нового в Rust - только borrow checker.

Действительно нового в Rust - только borrow checker.

Важно что нового одновременно, а в таких разговорах обычно обсуждают что нового по-отдельности. Так вот кроме борроу чекера, в языке одновременно пакетный менеджер как в NPM, одновременно не нужен сборщик мусора, одновременно защита от data-race, одновременно еще и еще. Так что комбинация неплохая

Никто не спорит. Просто язык с sum types нельзя считать современным только за sum types - они есть в разных языках уже 50 лет.

Ну наконец-то. Синтаксис await конечно странноват, но сойдет.

Как-то под эмбеды медленно инфраструктуру пилят. Я уже плюнул надеяться, на сишечке одним пальцем левой ноги корябаю как умею.

И как это работает?

Он превращает цепочки async вычислений в машину состояний, которую если потянуть за веревочку, то она будет выдавать результаты пока они не закончатся. В данном случае одно число. Если бы было IO, то выдавало бы результаты, пока IO не закончилось. Когда закончилось бы, то оно поставило себя в очередь еще на больше IO. Когда новое IO пришло, оно бы уведомило вызывающего что еще результаты готовы.

Теоретически можно писать такой код, чтобы машина состояний была без аллокаций совсем, сугубо в фиксированой памяти. Конечно редко нужно так упарываться, но Rust единственный язык, где комбинации futures - zero alloc.

https://www.youtube.com/watch?v=skos4B5x7qE

Я умею в JS, но JS на серверах — это провал.

А твой пример что делает? add10 вызываются в отдельном потоке? Или просто при вызове await в том же потоке всё вызывается, т.е. реально в этом примере никакой асинхронности нет?

Кооперативная многозадачность же. Просто тут все сразу финиширует. Но сама форма кода асинхронная.

А как модифицировать, чтобы задачи в отдельные потоки уходили в тред-пул какой-нибудь и два вызова add10 считались параллельно?

Не больший провал, чем любая другая скриптуха на сервере. Крутятся сервисы на koa + pg, полет нормальный

Не знаю, я по растам не спец. Но async/await точно не про это. Оно про один поток. В основном чтобы ты мог написать свою бизнес-логику «с ожиданиями ответов» в линейном виде, и не сойти с ума.

В моем примере есть асинхронность и конкурентность как абстракция. Например это бы уже было полезно в IO, штопало бы данные без блокировок как nginx.

Rust не делает потоки если его не просят. Например для того чтобы сделать несколько асинхронных операций синхронизировать потоки может быть слишком дорого и не нужно. Все тяжелые операции нужно делать на отдельном thread pool и потом только получать результаты оттуда

Никак. Запустить несколько реакторов, по реактору на ядро

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

Рантайм позволяет распихать задпчи по разным тредам / воркерам. Но это уже зависит от рантайма :)

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

Ну можно же blocking какой-то прикрутить.

Токио разве умеет?

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

Нет, так было бы в Java/Scala. Тут не, тут хотят чтобы таких async/wait можно было бесплатно прицепить по 100 штук друг другу через три фреймворка, а оно схлопнулось в просто в машину состояний в структуре

Напротив, безумие это отдавать тонны мелких json стандартным скриптушным подходом (через тредпул, fcgi, uwsgi и проч)

Вот выпукивать html-ки нодой да, безумие

Так у него же нет и не может быть async api?

Только токио и умеет ЕМНИП. Но мне он не нра.

Legioner

use async_std::task;

fn hello_sync(a: i32) -> i32 {
    println!("Thread: {:?}", std::thread::current().name());
    a + 10
}

async fn hello(a: i32) -> i32 {
    println!("Thread: {:?}", std::thread::current().name());
    a + 10
}

async fn f(a: i32, b: i32) -> i32 {
    let res = task::spawn_blocking(move || hello_sync(a)).await;
    res + hello(b).await
}

fn main() {
    task::block_on(async {
        println!("Hello, world!: {}", f(2, 3).await);
    });
}

Thread: Some("async-blocking-driver")
Thread: Some("main")
Hello, world!: 25

И это async_std - фреймворк от Васянов, ему еще долго фичи добавлять. У них блокирующий пул то один на все про все.

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

А в каких языках есть вёб-сервер в стандартной библиотеке?

Go

То-то он мне сразу не понравился.

Ну очень удобно, а в чем проблема?

https://golang.org/pkg/net/http/

Конечно альтернативные реализации уже сделали

Поздравляю растовиков и желаю им больше вакансий.

Java

На коленке набросать что-то может быть и удобно.
Вполне может быть и в продакшен гонять.
Но мне не нравится сам подход «ein volk».
Мне как-то ближе подход со стандартизацией интерфейса, а реализации можно было выбирать какие нравятся.

Где O_o?

И это async_std - фреймворк от Васянов, ему еще долго фичи добавлять. У них блокирующий пул то один на все про все.

Ну практика показывает, что для highload IOPS лучше один пул на тред. В tokio к этому в итоге пришли через три года страданий. При этом сам tokio всю свою историю страдает от дичайшего количества багов разной степени упоротости.

https://docs.oracle.com/javase/8/docs/jre/api/net/httpserver/spec/com/sun/net/httpserver/package-summary.html

Можно будет реализовать нормальный smallvec.

один пул на тред

Один пул на тред? В смысле? Прямо создавать пул из нескольких тредов на каждый IO тред? Что-то я не догнал. Или ты опечатался?

Хотя нет, это вроде const generics. Я уже запутался в этих RFC.

Тю-ю-ю.
А разве 'com' является частью стандарта?
Насколько я помню это часть сановской, а нынче оракловской реализации.