had some rate limiting ideas to try out with @ryanhiebert 's https://queueio.dev
had claude dump a bunch of #frontmission wanzer data into a file for me and i built a contrived rate limiting api around it. got hung up trying to get #rabbitmq to work with the #devcontainer in #devpod so i didn't get any real code that i wanted to do in. i'll start back in on it when i get some spare time.
repo sadly void of queueio code here: https://github.com/cmhobbs/wanzerbay
stay tuned!
Wow so it turns out I was right, Javascript is a gross language that is impossible to read for anybody who isn't already familiar with its syntax.
I come from C/C++ and Python land when it comes to network request stuff, and I'm accustomed to code just executing one line after another. I can get used to the async stuff, but it's pretty damn frustrating that VS Code doesn't even have any indications to tell you when a function is going to be async or not.
There's also seemingly no immediately clean way to just say "don't continue, everything after this is going to rely on the result of this function".
Maybe I'm just bitching because I don't understand how await and Promises work.
Oxyde – Pydantic-native async ORM with a Rust core
https://github.com/mr-fatalyst/oxyde
#HackerNews #Oxyde #Pydantic #ORM #Rust #async #Python #developer #tools
Oxyde ORM is a type-safe, Pydantic-centric asynchronous ORM with a high-performance Rust core designed for clarity, speed, and reliability. - mr-fatalyst/oxyde
닷넷 11에서 많은 개선이 예고되어있지만, 개인적으로는 dotnet run file.cs의 BuildLevel.Csc 최적화와 Runtime Async의 결합이 매우 기대됩니다.
이로서 NuGet 패키지 없이 BCL만 사용하는 단일 파일 C# 프로그램이 반복 실행 200ms~630ms의 성능을 달성하며, Python의 편의성과 Go의 배포 단순성, C#의 타입 안전성을 결합한 새로운 코딩 장르가 열리게 됩니다.
Tokio!
It's 'static + multithreaded-by-default requirement has created the myth that async #Rust is inherently difficult.
People should use `smol` more - here's why:
#Async Rust can be a pleasure to work with (without `Send + Sync + 'static`) - by Evan Schwartz:
https://emschwartz.me/async-rust-can-be-a-pleasure-to-work-with-without-send-sync-static/
Some developers still think async/await makes code faster. I thought the same when I started with .NET. Then one day, our API started slowing down under load. Not because of the CPU. Not because of the database. Because we were blocking threads everywhere. .Result .Wait() Sync database calls Sync HTTP calls Everything worked perfectly… until traffic increased. What many developers miss is this: Async doesn’t make one request faster. A request that takes 400ms with sync code will still take ~400ms with async. The real difference is what happens to the ThreadPool. With synchronous code: Thread → waits for HTTP → waits for DB → waits for I/O The thread is blocked the whole time. With async code: Thread → starts I/O → returns to ThreadPool OS notifies completion → continuation resumes. That single difference is what allows ASP .NET Core to handle thousands more concurrent requests. The real killer I keep seeing in production codebases is this: Sync-over-async var result = httpClient.SendAsync(...).Result; This blocks the thread again and under load it can lead to ThreadPool starvation. And once that happens, your API starts feeling “mysteriously slow”. No CPU spikes. No database bottlenecks. Just no threads left to process requests. I made this visual to explain what actually happens inside ASP .NET Core. Curious: Have you ever debugged a production issue that turned out to be sync-over-async? __ 📌 Don't miss the next newsletter issue, 20,000 engineers will read it, join them: thecodeman.net 📌 Join our Free Closed .NET Hub (1.1k members) and get access to content nobody publicly has: https://lnkd.in/gu_5HiMD ♻️ Repost to others. 📂 You can save this post for later, and you should do it. ➕ Follow me ( Stefan Đokić ) to learn .NET and Architecture every day. | 32 comments on LinkedIn
How to Stop Async forEach From Doing Nothing
forEach ignores await and hides failures.
How to Prevent Promise Race From Hiding Errors
race resolves early and drops later failures.
[Перевод] Async Coalescing: 5 стратегий объединения асинхронных запросов
Асинхронное программирование сегодня используется почти везде — от пользовательских интерфейсов до серверных систем с высокой нагрузкой. Оно позволяет не блокировать поток выполнения и эффективно работать с операциями ввода-вывода. Но вместе с этой гибкостью появляется и обратная сторона: пересекающиеся асинхронные вызовы начинают конкурировать друг с другом. Представим простой пример. Пользователь печатает в строке поиска, и каждый символ запускает новый запрос. Или серверный сервис несколько раз запрашивает одни и те же данные, потому что разные части системы одновременно обращаются к одному ресурсу. Это не редкие случаи — такое происходит постоянно. Если такие вызовы никак не координировать, система начинает выполнять лишнюю работу. Возникают дублирующиеся запросы, гонки данных и дополнительные вычисления. В интерфейсах результаты могут приходить в неправильном порядке, а на сервере растёт нагрузка и появляются трудно воспроизводимые ошибки. Обычно проблему пытаются решать блокировками, токенами отмены или дополнительными проверками в коде, но такие решения часто оказываются лишь временными костылями. Более системный подход — объединять пересекающиеся асинхронные операции. Если несколько вызовов требуют один и тот же результат, нет необходимости выполнять работу несколько раз. Гораздо разумнее выполнить её один раз и распределить результат между всеми ожидающими. Однако в реальных системах одного такого поведения недостаточно. Иногда результат должен определяться самым последним запросом. Иногда выполнение лучше немного отложить, чтобы дождаться стабилизации входных данных. А в некоторых случаях операции вообще нужно выполнять строго по очереди. В этой статье я разберу пять стратегий Async Coalescing — подхода, который позволяет контролировать конкуренцию асинхронных операций. Мы посмотрим, в каких ситуациях каждая стратегия полезна и какие компромиссы она вносит в систему.
Never snooze a future, https://jacko.io/snooze.html.
An interesting article explaining how a “snoozed future” can be a source of deadlock. The article discusses potential solutions to overcome this problem.
hobbs
River
Hacker News
남정현
Jan 
robrich
JavaScriptBuzz
Habr
Ivan Enderlin 🦀