닷넷 11에서 많은 개선이 예고되어있지만, 개인적으로는 dotnet run file.cs의 BuildLevel.Csc 최적화와 Runtime Async의 결합이 매우 기대됩니다.
이로서 NuGet 패키지 없이 BCL만 사용하는 단일 파일 C# 프로그램이 반복 실행 200ms~630ms의 성능을 달성하며, Python의 편의성과 Go의 배포 단순성, C#의 타입 안전성을 결합한 새로운 코딩 장르가 열리게 됩니다.
Search results
#Optique 0.9.0 is here!
This release brings #async/await support to #CLI parsers. Now you can validate input against external resources—databases, APIs, Git repositories—directly at parse time, with full #TypeScript type safety.
The new @optique/git package showcases this: validate branch names, tags, and commit SHAs against an actual Git repo, complete with shell completion suggestions.
Other highlights:
- Hidden option support for deprecated/internal flags
- Numeric choices in
choice() - Security fix for shell completion scripts
Fully backward compatible—your existing parsers work unchanged.
Designing type-safe sync/async mode support in TypeScript
洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Optique, a type-safe CLI parser for TypeScript inspired by functional programming principles, recently introduced support for both synchronous and asynchronous execution modes to handle complex requirements like dynamic shell completions. Implementing this feature required sophisticated type-level logic to ensure that combining an asynchronous parser with synchronous ones correctly results in an asynchronous aggregate. After evaluating several design patterns, the developer settled on an explicit mode parameter with a default value to maintain backward compatibility while allowing for runtime inspection. This approach leverages conditional types and advanced inference to compute combined modes automatically, even though it necessitated significantly increasing internal implementation complexity to support dual execution paths. The updated API now includes specialized runners that provide compile-time enforcement of the expected execution mode, preventing common pitfalls associated with asynchronous code. By prioritizing a clean user-facing interface, the library successfully integrates asynchronous capabilities without compromising its original simplicity or type safety. This architectural evolution demonstrates how TypeScript’s powerful type system can manage complex state propagation while keeping the development experience intuitive and robust.
Read more →
Two great Django Async projects highlighted in this week’s Django News.
DjangoRealtime, which is SSEs using Postgres as the messaging layer, and Django-Liveview, which lets you build real-time, reactive interfaces with Django using WebSockets, based on Channels.
Just two of the numerous Django projects out there leveraging async to let you build responsive, real-time applications. Go check them out! 🦄
A fun looking project 🤩 SSE for Django using Postgres pub/sub as the messaging layer
Yet another great example of async Django. Long lived ASGI connections that just aren’t feasible with WSGI’s worker-per-connection model.
I’m looking forward to giving it a play.
https://github.com/usmanhalalit/DjangoRealtime #django #sse #postgres #async
A great write-up on #async vs #multiprocessing in #Python. Many teams face that problem for data science tasks with external data consumption (e.g. using #Kafka), but don't understand the underlying mechanics. There's no magic bullet; engineering is a #discipline. https://pythonspeed.com/articles/two-thread-pools/ by 
@itamarstItamar Turner-Trauring #datascience #threadpools #performance #optimization
New TUI dropped for managing SSH connections! 🔥
🌀 **TermiRs** — A modern & async SSH client.
⚡ Connect, browse, transfer files, manage ports and import from ~/.ssh/config.
🦀 Written in Rust & built with 
@ratatui_rsRatatui
⭐ GitHub: https://github.com/caelansar/termirs
#rustlang #ratatui #tui #ssh #terminal #async #devtools #opensource
Async Void in C#: The Trap Card You Keep Playing | with Michael Jolley
How can I write a C++/WinRT IAsyncOperation<T> where T is not a Windows Runtime type?, part 2 | by Raymond Chen.
https://devblogs.microsoft.com/oldnewthing/20250904-00/?p=111557
How can I write a C++/WinRT IAsyncOperation<T> where T is not a Windows Runtime type?, part 1 | by Raymond Chen.
https://devblogs.microsoft.com/oldnewthing/20250903-00/?p=111546
Does .ConfigureAwait Still Matter in .NET? 🤔 | by Bruno Capuano.
https://elbruno.com/2025/08/29/does-configureawait-still-matter-in-net-%f0%9f%a4%94/
Have you ever tried using AsyncPublisher? I have. And some of its behavior has surprised me. I looked into it in-depth in my newest article, where I show how to use its behavior for your advantage, as well as how to get around its limitations. As you will see, some aspects can quite differ from observing publisher in Combine. #combine #swift #asyncpublisher #async
https://www.cleevio.com/blog/the-not-so-equivalent-code-demystifying-asyncpublisher
Now that #swad 0.7 is released, it's time to prepare a new release of #poser, my own lib supporting #services on #POSIX systems, following a #reactor with #threadpool design.
During development of swad, I moved poser from using strictly only POSIX APIs (with the scalability limits of e.g. #select) to auto-detected support for #kqueue, #epoll, #eventports, #signalfd and #timerfd (so now it could, in theory(!), "compete" with e.g. libevent). I also fixed quite some hidden bugs, and added more base functionality, like a #dictionary using nested hashtables internally, or #async tasks mimicking the async/await pattern known from e.g, #csharp. I also deprecated two features, the periodic and global "service tick" (superseded by individual timers) and the "resolve hosts" property of a "connection" (superseded by a separate resolve class).
I'll have to decide on a few things, e.g. whether I'll remove the deprecated stuff immediately and bump the major version of the "posercore" lib. I guess I'll do just that. I'd also like to add all the web-specific stuff (http 1.0/1.1 server) that's currently part of the swad code as a "poserweb" lib. This would get a major version of 0, indicating a generally unstable API/ABI as of now....
And then, I'd have to decide where certain utility classes belong to. The rate limiter is probably useful for things other than web, so it should probably go to core. What about url encoding/decoding, for example? 🤔
Stay tuned, something will come here, maybe helping you to write a nice service in plain #C 😎:
Today, I implemented the #async / #await pattern (as known from #csharp and meanwhile quite some other languages) ...
... in good old #C! 😎
Well, at least sort of.
* It requires some standard library support, namely #POSIX user context switching with #getcontext and friends, which was deprecated in POSIX-1.2008. But it's still available on many systems, including #FreeBSD, #NetBSD, #Linux (with #glibc). It's NOT available e.g. on #OpenBSD, or Linux with some alternative libc.
* I can't do anything about the basic language syntax, so some boilerplate comes with using it.
* It has some overhead (room for extra stacks, even extra syscalls as getcontext unfortunately also always saves/restores the signal mask)
But then ... async/await in C! 🥳
Here are the docs:
https://zirias.github.io/poser/api/latest/class_p_s_c___async_task.html
I finally eliminated the need for a dedicated #thread controlling the pam helper #process in #swad. 🥳
The building block that was still missing from #poser was a way to await some async I/O task performed on the main thread from a worker thread. So I added a class to allow exactly that. The naive implementation just signals the main thread to carry out the requested task and then waits on a #semaphore for completion, which of course blocks the worker thread.
Turns out we can actually do better, reaching similar functionality like e.g. #async / #await in C#: Release the worker thread to do other jobs while waiting. The key to this is user context switching support like offered by #POSIX-1.2001 #getcontext and friends. Unfortunately it was deprecated in POSIX-1.2008 without an obvious replacement (the docs basically say "use threads", which doesn't work for my scenario), but still lots of systems provide it, e.g. #FreeBSD, #NetBSD, #Linux (with #glibc) ...
The posercore lib now offers both implementations, prefering to use user context switching if available. It comes at a price: Every thread job now needs its private stack space (I allocated 64kiB there for now), and of course the switching takes some time as well, but that's very likely better than leaving a task idle waiting. And there's a restriction, resuming must still happen on the same thread that called the "await", so if this thread is currently busy, we have to wait a little bit longer. I still think it's a very nice solution. 😎
In any case, the code for the PAM credential checker module looks much cleaner now (the await "magic" happens on line 174):
https://github.com/Zirias/swad/blob/57eefe93cdad0df55ebede4bd877d22e7be1a7f8/src/bin/swad/cred/pamchecker.c
the other #rustlang thingy that's been cooking (and just passed a #ci run) is called #taggart.
it uses #tengri to pop up an interactive table to edit things, namely: the #id3 tags of music releases
its purpose? why, to make it easier to prepare a certain pile of content (that we've accumulated with a friend over the past, what, 6-7 years), for publication in a sovereign #faircamp instance! but none of it's well-tagged and existing interactive mediatag editors are ugh