Драма tokio vs async-std

Какие-то инфантильные они в этих ваших америках.

А, так патч прислал русский. Ну тут всё понятно. На них diversity не распространяется.

Да в принципе патч не важен, он был только поводом того, что информация о наличии конфликта между разрабами tokio и async-std была фактически официально объявлена. И хочется деталей чисто технических. Надо ведь знать, на чем писать софт с async/await.

First of all, the users who find themselves unable to interact with this repo find themselves such because the repo is mine and I have personally blocked them from interacting with me further on GitHub. I cannot speak to any situation involving async-std, because I am not a contributor to that project.

I blocked these users because I do not believe they were acting in good faith in making and supporting this PR. It seems obvious that when a minor readme change to a deprecated project receives dozens of thumbs up within hours that something unusual is going on. In the larger context of known tensions betweens async-std (which shares contributors with this project) and tokio, and in my personal context of having found kpp to be an aggressive and unpleasant person to engage with, what has happened here is obvious to me. That kpp has gone on to use this PR on reddit to claim async-std’s maintainers are not «kind and open» is the most disingenuous horseshit imaginable, one wonders if that was his initial hope for this PR, or just a happy outcome for him.

То есть «он сюда полез, чтобы я его забанил и он смог жаловаться»?

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

Как это альтернатив нет? собственно tokio/async-std и есть пара альтернатив, которые во многом выполняют одну задачу.

кстати, а в чем суть срача с актикс была?

пулреквест замёржен, мудаки пробанены

Всё правильно сделали же.

Там у какого-то завистливого петушка горит, ясен же пень, нет никакого конфликта.

vertexua, а за что авторов async-std зовут васянами и чем tokio лучше?

А почему async-std не в стандартной библиотеке вообще? Раз Rust такой весь асинхронный, то и функции должны как минимум иметь асинхронную альтернативу.

UPD: It appears that ALL commenters have been banned from both this repo and async-std.

А вот и причина против async-std. Его мейнтейнеры — истерички.

Я имел ввиду actix-web.

Сложный вопрос. Как я понял, некоторые особо рьяные личности пытались выпилить все unsafe, что приводило к просадке производительность. Автор либы их вежливо посылал. А они начинали кидаться какашками, мол ты CoC и вообще. В итоге он выложил 1.0 и сказал что забивает на либу, ибо достали. Но вроде по-прежнему пилит потихоньку.

Не надоело тупить в каждой теме про раст?

https://www.reddit.com/r/rust/comments/dpjlkt/comment/f5yaqz9

Вот тут чувак описывает что futures-rs могут быть основанием для всего асинхронного, но тут-же говорит, что оно так не реализованно в реальности. Короче я нифига не понял:

The odd difference to python is that an effort to build shared interfaces in Rust does exist and it is old: futures-rs. It comes with a ton of traits that help you effectively write software without relying on the type of stream that hands you the data. Maybe, at some point, someone will figure out to also unify those types effectively, but my point is that we’re really not as bad off.

Also, this is a similar problem to ORMs and their support with databases: as a library, you want to be rather generic over all, while in any concrete application, you will make a choice which will last for a while. The futures crate is the way to ensure a common ground.

So, weirdly, we have foundations early where others have none and no common ground at places where you’d imagine people would have just ported community practices over

Вся нить обсуждения: https://www.reddit.com/r/rust/comments/dpjlkt/comment/f5vy4tg

Надо ведь знать, на чем писать софт с async/await.

На ЖС А что, кто-то мешает и дальше пользоваться той же самой библиотекой, что и до этого?

Может, я чего не понимаю, в Расте ни бум-бум.

Походу та же бадяга, что и с node.js. Нормального async для ФС неть ни для одной ОС. Токио делает какую-ту хитрую конструкцию на тредпулах, которая несовместима с реализацией async-std

Токио неторопливо мигрирует со старой версии futures-rs на новую. async-std уже

Токио и async-std оба пытаются следовать API стандартной библиотеки, но нескольно по разному

В это время, на crates.io полно библиотек, зависящих от разных 0.0.x версий и альфа-версий токио. А async-std, несмотря на свою юность, хайпует и вот-вот выпустит версию 1.0 чтоб дать всем какие-то гарантии по API

https://github.com/withoutboats/romio/pull/106#issuecomment-550413977

Больные дети же. Чтобы досадить одним, побежали помогать конкурентам. Не такая редкая логика, кстати.

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

странно, я думал в любой непонятной ситуации нужно делать форк

Скандалы, интриги, расследования.(цы)

Нормального async для ФС неть ни для одной ОС.

Вроде в линуксе сделали какой-то io_uring недавно. В винде всегда был, хз, насколько нормальный.

Нормального async для ФС неть ни для одной ОС.

Потому что в 99% случаев и нахер не надо, например. Гошечка точно так же юзает треды для файловых операций. Только гошники мужики простые и не ноют, и всё у них работет. В 90% случаев тебе вообще никакой асинронный ввод-вывод нахер не нужен. Разнылись тут.

Потому что в 99% случаев и нахер не надо, например

А как тогда делать сервер, отдающий статику?

винде всегда был, хз, насколько нормальный

Где-то давно читал нытье автора libuv. Писал что нигде нормального нет

Как всю жизнь делали, ёпта. Как, по-твоему, nginx под линуксом работает?

Через некий os-специфичный костыль, о котором я подумал?)

Смысл в этом есть. Современные SSD нормально разгоняются ближе к 32 потокам. Т.е. твоя программа должна пускать 32 потока, чтобы выжимать максимум из оборудования. Если при этом у тебя асинхронная программа, которая работает в одном потоке, то выглядит это всё глупо. Конечно 32 потока много ресурсов не сожрут, но зачем это всё, если по факту оборудование асинхронное, процессор работает асинхронно. Т.е. получается, что ОС поверх асинхронного оборудования имитирует синхронное АПИ, а твоя программа поверх синхронного АПИ имитирует асинхронное АПИ, лол. В общем ни к чему это.

Да хоть 1024 потока, в чём твоя проблема?

Асинхронный ввод вывод жизненно необходимо для сетевых соединений, коих могут быть сотни тысяч, и запускать 100000 тредов становится дорого. А диск всего один. Или два. У тебя не будет столько дисков, чтобы это стало проблемой. Поэтому асинхронный ввод-ввывод для сокетов реализовали ещё до твоего рождения, а асинхронный ввод-ввывод для дисков никому особо нахер не нужен. В линуксе io_submit добавили сто лет назад - и до сих пор не допилили до юзабельного состояния, потому что никому оно нахер не интересно. Даже nginx его зачем-то поддерживает - и оно выключено по дефолту, потому что нахер не нужно, когда обычный тредпул работает лучше. И даже если включить, всё равно надо использовать тредпул, потому что операции типа fopen() или fstat() всё равно остаются блокирующеми. Сейчас сделали io_uring, но неблокирующих аналогов fopen() или fstat() и там нет и не будет, потому что тупо выделки не стоит при нынешних дисках.

Tokio старее, работает вполне.

async std начали пилить заново, может сделали что-то лучше. Но само имя как по мне запутывает людей и они думают что это связано с Rust Async Workgroup. По сути получили хайп нагару, но проект сторонний и в нем куча ещё за флагом unstable

Я не против обеих, будем смотреть как проекты выживут.

Конечно в идеале чтобы сам Rust на чем-то стандартизировался, на том или ином

Это сторонний проект, который так себя назвал чтобы все думали что это кусок стандартной либы. (В Rust часто библиотеки вроде генерации случайных чисел от core команды кладут в crate)

NVME выдает 500k iops. Один. Удачи утилизировать без асинхронного IO в том или ином виде.

И сколько из этих IOPS он умеет выполнять параллельно?

Достаточно, чтобы синхронное выполнение write() в один поток не могло его утилизировать. Даже саташные ssd в один поток не утилизировать, лол. Поэтому начинается огород с тредпулами и прочей глупостью, когда напрашивается обычная асинхронка, которую в итоге сперва сделали коряво (linux aio), а теперь кошерно (io uring).

В чём глупость-то, лол? Недостаточно молодёжно?

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

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

Ты понимаешь, что такое глубина очереди и почему это важный параметр?

Тож CrystalDiskMark юзаеш? ;-)

Когда понадобится больше 1000 параллельных операций, чтобы насытить твой диск, тогда и придёшь сюда ныть про асинхронный ввод-вывод.

Тож CrystalDiskMark юзаеш? ;-)

Нет, fio.

Когда понадобится больше 1000 параллельных операций, чтобы насытить твой диск, тогда и придёшь сюда ныть про асинхронный ввод-вывод.

Ты понимаешь, что write() в один поток не справляется даже на SATA? Хотя речь о глубине очереди в 32/64 запроса-то всего?

Гошечка точно так же юзает треды для файловых операций

Горутины — это не треды.

Ну так запусти больше потоков, ёпт.

Кот-то утверждал обратное?

Ну так запусти больше потоков, ёпт.

Приходится либо так, либо с помощью Linux AIO. А теперь делаем еще один шаг и понимаем, что те механизмы, которые мы используем для отправки данных в сеть, можно использовать и для отправки данных в диск. И приходим к тому же linux aio, только с более годной архитектурой. И теперь используя один epoll() можно менеджить весь I/O. Бомбит-то от чего?

Ты хочешь сказать, что на работе с файлом горутина блокируется и занимает поток?

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

Никак не пойму, тебе IO или поныть? Потому что с IO проблем нет.

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

Вот тут стена плача: https://github.com/golang/go/issues/6817

То есть кроме ДЕДЫ ЗАВЕЩАЛИ У МЕНЯ ВСЕ РАБОТАЕТ РЯЯЯЯ мы от тебя ничего не дождемся, верно?

Повторюша дядя Хрюша.