Введение в низкоуровневые асинхронные интерфейсы rust tokio в сократовском стиле

https://fasterthanli.me/articles/pin-and-suffering

Вчера запилил долгожданный и вечнооткладываемый диалог с @alexdemchenko о языках, и вот его текстовая версия.
Все начинается с вопроса: зачем создавался язык Х ?
Возьмем пхп. Автор его делал для работы с швблонами, про веб-сервера и прочие свистелки речи не шло, да и не было возможности и необходимости. Зачем создавался питон? Для обучения студла с минимальной мозговой активностью. О создании на нем дропбокса и гугла речи не шло(как и о сплите экосистемы на 2 и 3 лол). Зачем делалась ява? Да чтобы закрыть костыли плюсов, решив, что давайте все абстрагируем и сядем на этот кактус. Зачем была создана скала? Да еще проще - защитить пхд и забить на реализацию компилятора, спасибо жвм. Речи об инженерных вещах тоже не было. А выстрелила только потому, что жава убога и медлительна в развитии(даже сейчас), но экосистема обширна. Зачем был груви? Да от балды, ведь это проблема жвм интерпретировать эти байты. Из всего, что я видел - груви хорош для тестов, из-за текучего синтаксиса. Кложура туда же, делалась любителем лиспа cause I can. Котлин был решением проблем жавы: а давайте больше фич, а почему бы не сделать кофескрипт для жвм. Ну и расширить этим аудиторию медлительного редактора от той же конторы. Кстати, я отчетливо помню хайп по кофескрипт в 2010-11. Он нужен был везде и всегда. Сейчас о нем и писка нет. Ничего это язык-решение не решал, да. Хаскелл это песочница ученых. О бизнес-пользе можно не заикаться даже.
Но что насчет языков поновее? Возьмем всеми любимый и уютный раст. Язык решал проблему написания безопасного, низкоуровневого кода, к примеру как драйвер или даже браузер. И в этой нише он хорош и таки решает боль. Зачем делался тайпскрипт и/или дарт? Просто избавить нас от ежедневного рака под названием жс. Зачем был эликсир? Дать хорошую и читабельную обертку над ерлангом, который ох как неплох. Свифт? - убрать очередной рак ака обж-с и улучшить жизнь разрабов яблочной фирмы. Моя любимая гошечка? - начать использовать ядра проца с максимальной эффективностью и уменьшить латенси новых сотрудников(за счет маленького количества фич).
Оставив факты о фичах и прочем на след статью, хочу упомянуть, что сравнивать языки по синтаксису это как спорить что лучше: французский или все же японский. Дело не в написании слов, а в том, какие проблемы язык может решить и таки решает.

Great article that shows what will happen if you do not design asynchronous programming features in low-level language from scratch https://tomaka.medium.com/a-look-back-at-asynchronous-rust-d54d63934a1c

It turns out that everything is kind of works, but there are a handful of annoying nuances that you have to put up with or fix with some dirty hacks. And it is similar in most languages and most runtimes. It seems to me that the industry is trying to solve the problem of expensive OS threads and context switches, not where it needs to be solved. Why can't we make OS threads more lightweight? That would be great, and we already know how to use treads in our streams and work with queues, semaphores, and mutexes. All our tooling content understands streams, then what's the problem?

In 2013, people from Google delivered this talk https://www.youtube.com/watch?v=KXuZi9aeGTw
Where they demonstrate how to reduce the overhead of context switch 100 times or more.
If I understand correctly, in 2013, they already used this solution for services written in C ++ using "regular" threads.

In 2020, they even offered 3 patches for Linux, but didn't finish the discussion and did not merge these patches, and it may take another 5-10 years to get back to this idea.

Ребят,

Я понимаю, что эпоха проксей для Телеграма в России временно прошла, и тема уже не очень актуальная, однако хочу сказать, что буквально только что я выпустил mtg v2.0.0-rc1 (релиз-кандидат). Если вы еще пользуетесь прокси, то рекомендую попробовать.

Важное:
- Проект полностью переписан с нуля
- Переписан так, что теперь он выглядит как библиотека, а само приложение - просто пример того, как эту библиотеку можно встроить куда угодно
- Выкинута к чертовой матери поддержка adtag’а, мультиплексирование и тп
- Из коробки есть поддержка FireHOL-блоклистов
- Есть возможно сооружать цепочки прокси через socks5. То есть можно запустить mtg как фронтенд, и пристыковать его к вашей сетке v2ray/gost/trojan (надеюсь, вы не понимаете, о чем я говорю)
- Унификация и паритет для метрик в statsd/prometheus

Старая версия тоже поддерживается, но никаких новых фич туда вносить не буду. Просто раз в релиз версии Go буду обновлять линтеры и перекомпилировать.

https://github.com/9seconds/mtg/releases/tag/v2.0.0-rc1
https://github.com/9seconds/mtg/discussions/182
https://github.com/users/9seconds/packages/container/mtg/1945626

Спасибо

GitHub документирует проблемы своего собственного UX. Это прекрасно. https://docs.github.com/en/packages/guides/pushing-and-pulling-docker-images#authenticating-to-github-container-registry

Благодаря особой уличной магии питонячьего токенайзера это превращается в [0xf or x in (1, 2, 3)]. Тк or ленивый, то правая часть не вычисляется.

https://xn--r1a.website/scidoge/1644

@umputun выложил свой reverse-proxy https://github.com/umputun/reproxy

Разумеется написано на Go, умеет роутинг, подсасывает правила из файла или читает список докер контейнеров (sic!). Простое как дверь, но пока в ранней стадии разработки. Мне не хватает метрик, но issue уже создано и работы вот-вот начнутся.

Тут пришло в голову: а почему нет подобных проектов на русте? На Go есть уже довольно популярные Caddy и Traefik (и отчасти Istio) которые используются в проде, но вот о рустовых прокси я почти ничего не слышал.

Из более менее популярного, что я нарыл:
⁃ Sōzu https://github.com/sozu-proxy/sozu
⁃ Linkerd2 (сервис меш переписанный с Go) https://github.com/linkerd/linkerd2-proxy

Это очень молодые проекты — оба начаты в 2020. То ли дело в карантине, то ли в том, что экосистема асинк руста более-менее стабилизировалась. И это хорошо. Мне кажется, что rust – один из самых подходящих языков для таких задач.

Крутые анимированные модели различных тепловых двигателей

Спасибо @oleg_log
http://animatedengines.com