# await Published articles for await. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## CodeSOD: Asynchronous Directories DevFeed: [CodeSOD: Asynchronous Directories]() Original publisher: [Read original article]() Author: Remy Porter Published: 2026-09-09T06:30:00Z Content type: article Language: en Sources: [The Daily WTF]() Topics: [Vala](), [async/await](), [Library](), [Programming]() Tags: [async](), [asynchronous](), [await](), [codesod](), [exceptions](), [filesystem](), [writing-code]() ### AI overview This article examines implementing an asynchronous version of Vala's directory-creation method when the core library provides only a synchronous version. The proposed function walks up the directory tree, then creates missing directories in reverse order, using exceptions for control flow. ### Source excerpt Eri has a mix of a "true confession" and a "wait, really?" today. The programming language Vala bills itself as a C# like language that compiles into something pretty close to C performance, designed specifically for writing code against Gnome and its associated libraries. One of the C#-isms in brings in is async/await type semantics. You can yield someAsyncFunction(), which returns control to the caller, allowing it to proceed until the yielded function returns an actual value. Because it has asynchronous functions, many library functions for handling I/O are already async. So you can make_directory_async, which yields control so you can keep executing while waiting for the filesystem to make your directory. There are also synchronous versions of those methods. And then there's create_directory_with_parents, which will create a chain of directories for you. That's the synchronous version, and Vala's core library has decided not to provide an asynchronous version of it, which is my "wait, really?" I suspect it's really about the race conditions involved and the risks of things going wrong while doing it asynchronously; all solvable problems, but tricky ones to solve. But it's the problem Eri had, and this is their solution: /// Note: does not throw if target already exists async void create_directory_with_parents_async(File file, Cancellable? cancellable = null) throws Error { var to_create = new File[0]; var? current_target = file; while(current_target != null) { try { yield current_target.make_directory_async(Priority.DEFAULT, cancellable); } catch(IOError.NOT_FOUND e) { to_create += current_target; current_target = current_target.get_parent(); continue; } catch(IOError.EXISTS e) { break; } break; } for (int i = to_create.length - 1; i >= 0; --i) { try { yield to_create[i].make_directory_async(Priority.DEFAULT, cancellable); } catch(IOError.EXISTS e) { // Created by another process } } } If I'm reading this correctly, we start by trying to create the full path to ## WorkOS announces Agent Registration, Airlock, Relay, and native iOS and Android SDKs DevFeed: [WorkOS announces Agent Registration, Airlock, Relay, and native iOS and Android SDKs]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-09-02T00:00:00Z Content type: release Language: en Sources: [WorkOS Blog]() Topics: [SDKs](), [Android](), [iOS](), [Authorization](), [Mobile](), [Claude](), [Kotlin](), [Swift](), [MCP](), [Coroutines](), [Claude Code](), [codex]() Tags: [agent](), [android](), [api](), [authorization](), [await](), [claude](), [claude-code](), [coroutines](), [ios](), [kotlin](), [maven-central](), [mcp](), [sdks](), [swift](), [updates]() ### AI overview WorkOS announces August updates including Agent Registration for scoped, short-lived credentials, Airlock for authorizing AI-agent actions, Relay for proxying third-party application requests, and native Swift and Kotlin SDKs for iOS and Android. ### Source excerpt Agent Registration, Airlock, Relay, iOS & Android SDKs, & more ## Don't Block Suspend Functions DevFeed: [Don't Block Suspend Functions]() Original publisher: [Read original article]() Author: Jesse Wilson Published: 2026-01-22T04:32:49Z Content type: tutorial Language: en Sources: [Public Object]() Topics: [Coroutines](), [Kotlin](), [Concurrent Programming](), [Concurrency](), [async](), [Job](), [IO]() Tags: [async](), [await](), [blocking](), [blog-post](), [concurrency](), [coroutines](), [dispatcher](), [kotlin](), [thread](), [threads]() ### AI overview This Kotlin tutorial explains why blocking calls inside suspend functions can prevent other coroutines from running. It contrasts preemptive thread concurrency with cooperative coroutine concurrency and recommends avoiding blocking functions in suspending code, using the I/O dispatcher when necessary, and avoiding runBlocking. ### Source excerpt Here's a program that launches 3 jobs. The first runs forever and the other two exchange a value. @Test fun test() = runTest { val channel = Channel() val deferredA = async { while (isActive) { delay(1_000) } } val deferredB = async { channel.send("hello") } val deferredC = async { channel.receive() } deferredB.await( ## Use Swift with Temporal DevFeed: [Use Swift with Temporal]() Original publisher: [Read original article]() Author: Shy Ruparel Published: 2025-11-10T00:00:00Z Content type: release Language: en Sources: [Temporal Blog]() Topics: [Swift](), [SDKs](), [async/await](), [Swift 6.2](), [Concurrency](), [distributed-systems]() Tags: [announcements](), [async](), [await](), [concurrency](), [github](), [grpc](), [sdk](), [structured-concurrency](), [swift](), [swift-6-2]() ### AI overview Temporal announces a Swift SDK for building durable, fault-tolerant, long-running workflows with Swift 6.2, async/await, and structured concurrency. The SDK supports automatic handling of failures, retries, persistence, and crash recovery, and integrates with Temporal through Swift C interop and gRPC-swift. ### Source excerpt Announcing the Swift Temporal SDK. Build durable, fault-tolerant Workflows in Swift 6.2 with async/await and structured concurrency. ## Promise based Web Worker Messaging DevFeed: [Promise based Web Worker Messaging]() Original publisher: [Read original article]() Author: Stanko Published: 2025-11-03T00:00:00Z Content type: tutorial Language: en Sources: [Stanko Tadić]() Topics: [Promise](), [Messaging](), [Web](), [async/await](), [Code](), [Error Handling]() Tags: [async](), [await](), [code](), [error-handling](), [event](), [implementation](), [messaging](), [thread](), [web](), [worker]() ### AI overview This tutorial presents a Promise-based wrapper for Web Worker messaging. It explains how unique message identifiers map worker responses to stored promises, allowing the main thread to resolve or reject the corresponding promise and use async/await with simpler error handling. The same pattern can also be applied to Service Workers. ### Source excerpt If you've ever used Web Workers (or any other event-based communication), you probably noticed that this kind of code can be hard to read and reason about. You also have to implement some kind of identifier for each message to recognize which worker response corresponds to which request. To simplify that, we can write a small wrapper that lets us use Promises to communicate with Workers. I'll show you an example for Web Workers, but the same pattern can be applied to Service Workers as well. The resulting API looks like this: const workerResponse = await sendToWorker(data); I first used this approach in Pulsar, because I wanted to parse and execute the user's code in a Web Worker, but also wait for the worker to finish before providing data for the next frame. Implementation # The idea is fairly simple - before sending a message to the worker, we create a unique id and a promise. We store the promise in a map using the id as the key. Then we send an event to the worker, including both the data and the id, and return the promise to the caller. When the worker finishes its calculation, it sends back a message that includes the result and the same id. In the main thread, we listen for these messages. When one arrives, we use the id to find the corresponding promise in our map. Finally, based on the worker's result, we resolve or reject that promise. It might sound like a lot, but the code is actually quite straightforward: send-to-worker.jsCopy // Worker initialization const worker = new Worker("./path-to-your-worker.js"); // Map of promises const promises = {}; worker.addEventListener("message", (e) => { // Listen to worker messages and find the correct promise matching the id // Then resolve or reject it depending on the response if (e.data.error) { promises[e.data.id].reject(e.data.error); } else { promises[e.data.id].resolve(e.data.data); } // Remove the resolver reference delete promises[e.data.id]; }); // For identifiers it is safe to use a simple integer // whic ## Beyond the Spinner: Building Responsive AI Apps with Genkit Streaming DevFeed: [Beyond the Spinner: Building Responsive AI Apps with Genkit Streaming]() Original publisher: [Read original article]() Author: Pavel J Published: 2025-10-28T10:35:17Z Content type: tutorial Language: en Sources: [Firebase Developers - Medium]() Topics: [Genkit](), [Streaming](), [Large Language Model](), [User experience (UX)](), [Structured-data]() Tags: [ai](), [await](), [genkit](), [json](), [llm](), [process](), [streaming](), [ux]() ### AI overview A practical guide to using Genkit streaming for responsive AI applications. It covers streaming LLM response chunks with generateStream and callbacks, awaiting final response metadata, parsing incomplete streamed JSON, and streaming custom AI logic from flows. ### Source excerpt Better AI UXA practical guide to streaming LLM responses, partial JSON, and custom status messages to eliminate perceived latency. In the new age of AI, streaming structured data has suddenly become useful and mainstream. The main reason is that LLMs can be slow, and a good user experience (UX) strives to reduce this perceived latency. We could show a spinner for a few seconds, but that feels slow. Instead, if we start rendering content as soon as we receive the first few tokens from the LLM, the user can watch the response "grow in front of their eyes." Even if the end-to-end time is the same, it feels faster because the user sees activity immediately. BTW, this sample app (streaming side only) is available at: https://github.com/genkit-ai/samples/tree/main/simple-chatbot Streaming is foundational to Genkit's design. Everything in Genkit is built on top of actions -- simple, function-like constructs that, among other things, can stream. Models are actions, and flows are actions, so they can all stream. LLM streams Let's start with receiving streams from LLMs. The most common and useful way is to use the generateStream function: const { stream, response } = ai.generateStream({ prompt: 'Tell me a story about AI', }); for await (const chunk of stream) { process.stdout.write(chunk.text); } // optional const finalResponse = await response; console.log(finalResponse.usage); console.log(finalResponse.messages); // history In addition to the stream of "generate response chunks," we can optionally await the response promise. This is useful because it contains final usage data (like token counts), the complete message array (great for tracking history), and other metadata. If you don't like using the for await syntax and prefer callbacks, there's another less known way to stream using the generate function, by providing the onChunk callback: const response = await ai.generate({ prompt: 'Tell me a story aboud AI', onChunk: (chunk) => process.stdout.write(chunk.text), }); conso ## Kotlin Coroutines Compared with Reactor for Sequential and Asynchronous Operations DevFeed: [Kotlin Coroutines Compared with Reactor for Sequential and Asynchronous Operations]() Original publisher: [Read original article]() Published: 2025-10-06T00:00:00Z Content type: comparison Language: en Sources: [Kt. Academy]() Topics: [Coroutines](), [Kotlin](), [kotlin-coroutines](), [Reactive Streams](), [RxJava](), [async/await](), [Android](), [Back end]() Tags: [android](), [async](), [asynchronous](), [await](), [backend](), [compare](), [comparison](), [coroutines](), [kotlin](), [kotlin-coroutines](), [programming](), [programming-languages](), [reactive-streams](), [rxjava](), [simple](), [time](), [workshop-learning-programming]() ### AI overview This article compares Kotlin Coroutines with Reactor for backend and Android development. It argues that coroutines provide more readable and straightforward syntax for sequential and asynchronous operations, while Reactor requires additional operators, concepts, and patterns. ### Source excerpt A comparison of Kotlin Coroutines and Reactor, highlighting the elegance and simplicity of Coroutines over the complexity of Reactor. ## runBlocking in practice: Where it should be used and where not DevFeed: [runBlocking in practice: Where it should be used and where not]() Original publisher: [Read original article]() Published: 2025-09-01T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [runBlocking](), [Coroutines](), [Kotlin](), [kotlin-coroutines]() Tags: [android](), [async](), [await](), [best-practices](), [blocking](), [coroutines](), [dispatcher](), [guide](), [kotlin](), [pitfalls](), [retrofit](), [runblocking](), [workshop-learning-programming]() ### AI overview A practical guide to runBlocking in Kotlin Coroutines. It explains how runBlocking converts suspending calls into blocking calls, blocks the calling thread until completion, and creates a new coroutine hierarchy. The article discusses appropriate uses, code smells, and alternatives, including an Android Retrofit interceptor example. ### Source excerpt A comprehensive guide to using runBlocking in Kotlin Coroutines, including best practices and common pitfalls. ## Understanding Futures and await in Dart and Flutter DevFeed: [Understanding Futures and await in Dart and Flutter]() Original publisher: [Read original article]() Author: Marvin März Published: 2025-05-27T08:28:16Z Content type: tutorial Language: en Sources: [QuickBird Studios Blog]() Topics: [Dart](), [Flutter](), [event driven](), [Concurrency]() Tags: [asynchronous](), [await](), [concurrency](), [dart](), [event-driven](), [flutter](), [future](), [post]() ### AI overview This tutorial explains how Futures and await work in Dart and Flutter, including their interaction with Dart's single-threaded event loop, asynchronous I/O, and common pitfalls. ### Source excerpt Futures in Dart might seem straightforward at first glance, but dig a little deeper, and you'll find they can be more intricate than you initially thought. Ever wondered how these asynchronous operations truly play with Dart's single-threaded event loop? Or perhaps you've stumbled upon some of the common pitfalls that can trip up even experienced Flutter developers? Fear not, because we're about to embark on a journey to unravel the mysteries of Futures in Dart and Flutter. The post Why Await? Futures in Dart & Flutter appeared first on QuickBird Studios. ## Укрощаем асинхронный код с помощью async/await DevFeed: [Укрощаем асинхронный код с помощью async/await]() Original publisher: [Read original article]() Author: McDee (hh.ru) Published: 2025-04-29T06:50:38Z Content type: tutorial Language: ru Sources: [HeadHunter RU]() Topics: [async/await](), [async](), [iOS](), [Swift]() Tags: [async](), [await](), [ios](), [ios-92ecabba3495](), [ios-development](), [swift](), [tag-218f4e01a540](), [tag-7b7ea8dda2d4](), [tag-ae979152fd5d](), [tag-f538878e20ff]() ### AI overview This Russian-language tutorial explains async/await for asynchronous and multithreaded programming in iOS applications with Swift. It introduces the core concepts and compares async/await with GCD, highlighting code readability and error handling. ### Source excerpt Привет! Меня зовут Андрей Максимкин, я iOS-разработчик в hh. Мы в команде активно используем async/await подход при написании нового кода, а также активно применяем при переписывании старого. В процессе работы сталкивались с некоторыми интересными и не самыми очевидными моментами -- их и рассмотрим в статье. Работа с различными потоками -- очень важная часть разработки мобильных приложений под iOS. Грамотное распределение нагрузки положительно влияет на скорость работы приложения, а значит, и на пользовательский опыт. До Swift 5.5 для работы с многопоточностью в основном использовали фреймворки GCD и NSOperation. Начиная с версии Swift 5.5 стал доступен функционал async/await. В статье мы кратко расскажем о базовых принципах данного подхода и сделаем акцент на проблемах и особенностях, которые необходимо знать при написании кода. Информация будет полезна тем, кто уже знаком с функционалом async/await, а некоторые примеры могут быть интересны и более продвинутым разработчикам. Поехали! ## How to fetch data with React Hooks DevFeed: [How to fetch data with React Hooks]() Original publisher: [Read original article]() Author: Robin Wieruch Published: 2024-10-21T11:50:46Z Content type: tutorial Language: en Sources: [Robin Wieruch]() Topics: [React](), [Tutorial](), [data](), [client](), [axios](), [API](), [Promise]() Tags: [api](), [async](), [await](), [axios](), [beginners](), [browser](), [command-line](), [component](), [effect](), [fetch](), [fundamentals](), [how-to](), [learn](), [libraries](), [react](), [react-fetch-data-hooks](), [react-hooks](), [state](), [tutorial]() ### AI overview A tutorial on fetching data in client-side React with built-in React Hooks. It explains state and effect management, builds a reusable custom data-fetching hook using the Hacker News API, and shows how to use axios or the browser's native fetch API, including handling asynchronous effects and cleanup functions. ### Source excerpt Learn the fundamentals about data fetching in client-side React with React Hooks ... ## Oxidizing OCaml: Data Race Freedom DevFeed: [Oxidizing OCaml: Data Race Freedom]() Original publisher: [Read original article]() Author: Max Slater Published: 2023-09-01T00:00:00Z Content type: article Language: en Sources: [Jane Street]() Topics: [OCaml](), [Concurrency](), [data](), [async/await](), [Rust]() Tags: [async](), [atomics](), [await](), [code](), [concurrency](), [data](), [ocaml](), [rust](), [synchronization]() ### AI overview This final post in a series explains how Jane Street uses OCaml modes and capsules to design a statically data-race-free API for multicore OCaml. It discusses shared-memory parallelism, the risks of mutable data races, and approaches for safely handling shared mutability across domains. ### Source excerpt OCaml with Jane Street extensions is available from our public opam repo. Only a slice of the features described in this series are currently implemented. ## Async / Await Coroutines in Swift from Kotlin Multiplatform using KMP-NativeCoroutines DevFeed: [Async / Await Coroutines in Swift from Kotlin Multiplatform using KMP-NativeCoroutines]() Original publisher: [Read original article]() Author: Aleksander Jaworski Published: 2023-08-02T13:01:12Z Content type: tutorial Language: en Sources: [AKJAW]() Topics: [Kotlin Multiplatform](), [Coroutines](), [Swift](), [async/await]() Tags: [async](), [await](), [coroutines](), [ios](), [kmp](), [kotlin](), [kotlin-multiplatform](), [multiplatform](), [swift]() ### AI overview A write-up of a Droidcon Berlin 2023 talk about calling Kotlin Multiplatform coroutines from Swift using KMP-NativeCoroutines. It states that the official approach has significant awkwardness and limitations. ### Source excerpt This is a write-up for a talk I gave at Droidcon Berlin 2023, the video version can be found here: Calling Kotlin Multiplatform Coroutines from Swift with the help of KMP-NativeCoroutines - droidcon The official way of using Coroutines from Swift is awkward and has a lot of limitations. These ## Eliminating coroutine races DevFeed: [Eliminating coroutine races]() Original publisher: [Read original article]() Published: 2023-06-26T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Coroutines](), [kotlin-coroutines](), [Kotlin](), [Concurrent Programming]() Tags: [await](), [coroutine](), [coroutines](), [how-to](), [kotlin](), [kotlin-coroutines](), [workshop-learning-programming]() ### AI overview This tutorial explains how coroutine races occur when coroutines start in an unpredictable order and presents ways to coordinate them. It covers awaiting a completed coroutine, handling listener and event races in Android MVI scenarios, and using replay or completion signals for flows. ### Source excerpt How to make one coroutine await for another coroutine or flow subscription. ## Kotlin Coroutines Best Practices DevFeed: [Kotlin Coroutines Best Practices]() Original publisher: [Read original article]() Published: 2023-04-24T00:00:00Z Content type: article Language: en Sources: [Kt. Academy]() Topics: [Coroutines](), [Kotlin](), [kotlin-coroutines](), [async](), [await](), [Android](), [Back end](), [Parallelism](), [Unit testing]() Tags: [android](), [async](), [await](), [backend](), [coroutines](), [kotlin](), [kotlin-coroutines](), [parallelism](), [unit-testing](), [workshop-learning-programming]() ### AI overview A concise review of Kotlin coroutine practices, including avoiding unnecessary async/await usage, preferring awaitAll in suitable cases, keeping suspending functions safe across threads, selecting appropriate dispatchers, injecting dispatchers for unit testing, and using yield in CPU-intensive or blocking work. ### Source excerpt Let's review the Kotlin Coroutines best practices. ## Streaming, snapshots, and other new features since SvelteKit 1.0 DevFeed: [Streaming, snapshots, and other new features since SvelteKit 1.0]() Original publisher: [Read original article]() Author: Geoff Rich, Rich Harris Published: 2023-02-21T00:00:00Z Content type: article Language: en Sources: [Svelte blog]() Topics: [Svelte](), [Streaming](), [Promise]() Tags: [await](), [new-features](), [streaming](), [svelte]() ### AI overview This article describes SvelteKit features shipped since version 1.0, focusing on streaming non-essential data from nested promises in server load functions. It explains that pages can begin rendering before nested data resolves, while hosting support determines whether responses are streamed or buffered. ### Source excerpt The Svelte team has been hard at work since the release of SvelteKit 1.0. Let's talk about some of the major new features that have shipped since launch: streaming non-essential data, snapshots, and route-level config. Stream non-essential data in load functions SvelteKit uses load functions to retrieve data for a given route. When navigating between pages, it first fetches the data, and then renders the page with the result. This could be a problem if some of the data for the page takes longer to load than others, especially if the data isn't essential - the user won't see any part of the new page until all the data is ready. There were ways to work around this. In particular, you could fetch the slow data in the component itself, so it first renders with the data from load and then starts fetching the slow data. But this was not ideal: the data is even more delayed since you don't start fetching until the client renders, and you're also having to break SvelteKit's load convention. Now, in SvelteKit 1.8, we have a new solution: you can return a nested promise from a server load function, and SvelteKit will start rendering the page before it resolves. Once it completes, the result will be streamed to the page. For example, consider the following load function: export const const load: PageServerLoadload: PageServerLoad = () => { return { post: anypost: fetchPost(), streamed: { comments: any; }streamed: { comments: anycomments: fetchComments() } }; }; SvelteKit will automatically await the fetchPost call before it starts rendering the page, since it's at the top level. However, it won't wait for the nested fetchComments call to complete - the page will render and data.streamed.comments will be a promise that will resolve as the request completes. We can show a loading state in the corresponding +page.svelte using Svelte's await block:
{data.post}
{#a ## Firebase team profile: Charlotte Liang DevFeed: [Firebase team profile: Charlotte Liang]() Original publisher: [Read original article]() Author: Paulette McCroskey Published: 2022-11-18T00:00:00Z Content type: article Language: en Sources: [Firebase Blog]() Topics: [Firebase](), [Swift](), [SwiftUI](), [async/await](), [iOS](), [SDKs]() Tags: [async](), [await](), [community](), [firebase](), [firebaserfriday](), [google](), [ios](), [sdk](), [sdks](), [swift](), [swiftui](), [watchos]() ### AI overview A mini-profile of Firebase team member Charlotte Liang covering her path from writing the Firebase Remote Config iOS SDK to modernizing Firebase SDKs with Swift. She also discusses iOS and watchOS app development, SwiftUI, and her preference for async/await over callback listeners. ### Source excerpt Join us for the monthly mini-profiles on Firebase team members, aka "Firebasers", from all around the world! Learn about their backgrounds... ## Reasoning about asyncio.Semaphore DevFeed: [Reasoning about asyncio.Semaphore]() Original publisher: [Read original article]() Author: Guido van Rossum (noreply@blogger.com) Published: 2022-10-05T06:39:00Z Content type: article Language: en Sources: [Guido van Rossum]() Topics: [Concurrency](), [Concurrent Programming](), [await]() Tags: [await](), [fairness](), [implementing](), [performance](), [reasoning](), [semantics](), [synchronization]() ### AI overview The article explains asyncio synchronization primitives through a restaurant queuing analogy. It maps exclusive access and cancellation to a Lock, then explains why multiple concurrently seated guests require a Semaphore. It also discusses challenges involving fairness, correctness, semantics, and performance. ### Source excerpt In Silicon Valley is a very exclusive fast-food restaurant, which is always open. There is one table, where one guest at a time is served an absolutely fabulous hamburger. When you arrive, you wait in line until the table is available. Then the host takes you to the table and, this being America, you are asked a seemingly endless series of questions about how you would like your hamburger to be cooked and served. But today we're not talking about culinary delights. We're talking about the queuing system used by the restaurant. If you are lucky to arrive at the restaurant when the table is available and there are no other guests waiting, you are seated right away. Otherwise, the host gives you a buzzer (from an infinite stack of buzzers!) and you are free to roam the neighborhood until your buzzer goes off. It is the host's job to ensure that guests are seated in order of arrival. When it is your turn, the host will cause your buzzer go off and you make your way back to the restaurant, where you will be seated. If you change your mind, you can return the buzzer to the host, who will take it back without lifting an eyebrow. If your buzzer has already gone off, the host will buzz the next guest, if any. Guests are always polite and don't abscond with their buzzers. The host is always fair and doesn't seat another guest ahead of you even if you take your time making it back. The above description fits that of a Lock. A guest arriving corresponds to the acquire() call; leaving is a release() call. Changing your mind is like getting cancelled while waiting in acquire(). You can change your mind before or after your buzzer goes off, i.e., you can be cancelled before or after the lock has awakened your call (but before you return from acquire()). One day the restaurant expands, hiring extra sous-chefs and opening several new tables. There is still only one host, whose job is not really changed. However, since multiple guests can be seated concurrently, a Semaphore must now ## React Labs: What We've Been Working On - June 2022 DevFeed: [React Labs: What We've Been Working On - June 2022]() Original publisher: [Read original article]() Published: 2022-06-15T00:00:00Z Content type: article Language: en Sources: [React]() Topics: [React](), [async/await](), [Shopify](), [Vercel](), [Vite](), [Webpack]() Tags: [async](), [await](), [compatibility](), [experimental](), [react](), [release](), [shopify](), [vercel](), [vite](), [webpack]() ### AI overview A June 2022 React Labs update describes ongoing research following the React 18 release, including experimental React Server Components. The React team discusses adopting async/await, annotating boundaries, coordinating bundler semantics across Webpack and Vite with Vercel and Shopify, and improving asset loading APIs. The projects had no firm timelines and might change or never ship in their current form. ### Source excerpt This blog site has been archived. Go to react.dev/blog to see the recent posts. React 18 was years in the making, and with it brought valuable lessons for the React team. Its release was the result of many years of research and exploring many paths. Some of those paths were successful; many more were dead-ends that led to new insights. One lesson we've learned is that it's frustrating for the community to wait for new features without having insight into these paths that we're exploring. We typically have a number of projects being worked on at any time, ranging from the more experimental to the clearly defined. Looking ahead, we'd like to start regularly sharing more about what we've been working on with the community across these projects. To set expectations, this is not a roadmap with clear timelines. Many of these projects are under active research and are difficult to put concrete ship dates on. They may possibly never even ship in their current iteration depending on what we learn. Instead, we want to share with you the problem spaces we're actively thinking about, and what we've learned so far. Server Components We announced an experimental demo of React Server Components (RSC) in December 2020. Since then we've been finishing up its dependencies in React 18, and working on changes inspired by experimental feedback. In particular, we're abandoning the idea of having forked I/O libraries (eg react-fetch), and instead adopting an async/await model for better compatibility. This doesn't technically block RSC's release because you can also use routers for data fetching. Another change is that we're also moving away from the file extension approach in favor of annotating boundaries. We're working together with Vercel and Shopify to unify bundler support for shared semantics in both Webpack and Vite. Before launch, we want to make sure that the semantics of RSCs are the same across the whole React ecosystem. This is the major blocker for reaching stable. Asset Loa ## How @MainActor works DevFeed: [How @MainActor works]() Original publisher: [Read original article]() Author: Ole Begemann Published: 2022-05-05T13:52:42Z Content type: tutorial Language: en Sources: [Ole Begemann]() Topics: [Swift](), [Concurrency](), [Protocol (disambiguation)]() Tags: [await](), [compiler](), [concurrent](), [executor](), [main-thread](), [protocol](), [swift]() ### AI overview This tutorial explains how Swift's @MainActor works by reimplementing it in simplified form. It describes the roles of global actors and custom executors, including how a custom serial executor can run jobs on the main dispatch queue. ### Source excerpt @MainActor is a Swift annotation to coerce a function to always run on the main thread and to enable the compiler to verify this. How does this work? In this article, I'm going to reimplement @MainActor in a slightly simplified form for illustration purposes, mainly to show how little "magic" there is to it. The code of the real implementation in the Swift standard library is available in the Swift repository. @MainActor relies on two Swift features, one of them unofficial: global actors and custom executors. Global actors MainActor is a global actor. That is, it provides a single actor instance that is shared between all places in the code that are annotated with @MainActor. All global actors must implement the shared property that's defined in the GlobalActor protocol (every global actor implicitly conforms to this protocol): @globalActor final actor MyMainActor { // Requirements from the implicit GlobalActor conformance typealias ActorType = MyMainActor static var shared: ActorType = MyMainActor() // Don't allow others to create instances private init() {} } At this point, we have a global actor that has the same semantics as any other actor. That is, functions annotated with @MyMainActor will run on a thread in the cooperative thread pool managed by the Swift runtime. To move the work to the main thread, we need another concept, custom executors. Executors A bit of terminology: The compiler splits async code into jobs. A job roughly corresponds to the code from one await (= potential suspension point) to the next. The runtime submits each job to an executor. The executor is the object that decides in which order and in which context (i.e. which thread or dispatch queue) to run the jobs. Swift ships with two built-in executors: the default concurrent executor, used for "normal", non-actor-isolated async functions, and a default serial executor. Every actor instance has its own instance of this default serial executor and runs its code on it. Since the serial exec ## Advanced Swift, fifth edition DevFeed: [Advanced Swift, fifth edition]() Original publisher: [Read original article]() Author: Ole Begemann Published: 2022-03-28T14:03:30Z Content type: release Language: en Sources: [Ole Begemann]() Topics: [Swift](), [Concurrency](), [async/await]() Tags: [async](), [await](), [concurrency](), [generics](), [release](), [structured-concurrency](), [swift]() ### AI overview The fifth edition of Advanced Swift has been released. It is updated for Swift 5.6, adds a chapter on concurrency covering async/await, structured concurrency, and actors, and includes new material on property wrappers, result builders, protocols, and generics. The print edition is now a hardcover, and ebook owners receive a free update. ### Source excerpt We released the fifth edition of our book Advanced Swift a few days ago. You can buy the ebook on the objc.io site. The hardcover print edition is printed and sold by Amazon (amazon.com, amazon.co.uk, amazon.de). Highlights of the new edition: Fully updated for Swift 5.6 A new Concurrency chapter covering async/await, structured concurrency, and actors New content on property wrappers, result builders, protocols, and generics The print edition is now a hardcover (for the same price) Free update for owners of the ebook A growing book for a growing language Updating the book always turns out to be more work than I expect. Swift has grown substantially since our last release (for Swift 5.0), and the size of the book reflects this. The fifth edition is 76 % longer than the first edition from 2016. This time, we barely stayed under 1 million characters: Character counts of Advanced Swift editions from 2016-2022. Many thanks to our editor, Natalye, for reading all this and improving our Dutch/German dialect of English. Hardcover For the first time, the print edition comes in hardcover (for the same price). Being able to offer this makes me very happy. The hardcover book looks much better and is more likely to stay open when laid flat on a table. We also increased the page size from 15x23 cm (6x9 in) to 18x25 cm (7x10 in) to keep the page count manageable (Amazon's print on demand service limits hardcover books to 550 pages). I hope you enjoy the new edition. If you decide to buy the book or if you bought it in the past, thank you very much! And if you're willing to write a review on Amazon, we'd appreciate it. ## AppCode 2021.2: улучшения поддержки Swift, автодополнение выражений, окно иерархии вызовов для Swift и не только DevFeed: [AppCode 2021.2: улучшения поддержки Swift, автодополнение выражений, окно иерархии вызовов для Swift и не только]() Original publisher: [Read original article]() Author: yeswolf (JetBrains) Published: 2021-08-16T09:53:35Z Content type: release Language: ru Sources: [JetBrains RU]() Topics: [Swift](), [ide](), [Kotlin Multiplatform](), [swift-package-manager](), [async/await](), [Kotlin](), [multiplatform](), [Objective-C]() Tags: [appcode](), [async](), [await](), [call-hierarchy](), [complete-statement](), [ide](), [kmm](), [kotlin](), [kotlin-multiplatform](), [kotlin-multiplatform-mobile](), [local-history](), [mobile](), [multiplatform](), [objective-c](), [swift](), [swift-package-manager]() ### AI overview This release article describes AppCode 2021.2 improvements, including support for Swift features such as result builders, enum Codable synthesis, and async/await. It also covers documentation completion, Call Hierarchy, Swift Package Manager build and debugging support, a Kotlin Multiplatform Mobile plugin, a debugger Preview Tab, and Local History search. ### Source excerpt Привет, Хабр! В этом посте, как и всегда, расскажем о новом релизе AppCode. Всем, кому интересно, -- добро пожаловать под кат. Читать далее ## New runtime configuration options with Cloud Functions for Firebase DevFeed: [New runtime configuration options with Cloud Functions for Firebase]() Original publisher: [Read original article]() Author: Doug Stevenson Published: 2018-08-13T00:00:00Z Content type: release Language: en Sources: [Firebase Blog]() Topics: [Cloud Functions](), [Node.js](), [Firebase CLI](), [Firebase](), [async/await](), [configuration](), [ECMAScript](), [V8](), [TypeScript](), [Deployment](), [JSON]() Tags: [async](), [await](), [cloud-functions](), [cloud-next](), [deployment](), [firebase](), [firebase-cli](), [json](), [launch](), [node-js](), [serverless](), [typescript]() ### AI overview This Firebase team article describes new Cloud Functions for Firebase configuration options announced at Cloud Next 2018. It covers the beta Node.js 8 runtime, required Firebase CLI and firebase-functions versions, ECMAScript 2017 async/await support, TypeScript configuration, and per-function region, memory, and timeout settings. ### Source excerpt News, tutorials, and updates from the Firebase team. ## Javascript's async/await and Promise in a few words DevFeed: [Javascript's async/await and Promise in a few words]() Original publisher: [Read original article]() Author: Graham King Published: 2018-07-27T14:30:45Z Content type: tutorial Language: en Sources: [Graham King]() Topics: [async/await](), [JavaScript](), [Promise](), [callback](), [Exception](), [Code]() Tags: [async](), [await](), [callback](), [exception](), [javascript](), [software]() ### AI overview This tutorial explains how JavaScript uses Promises and async/await to handle operations that could otherwise block its single thread. It shows how async/await makes callback-based asynchronous code appear more linear while failures are handled through exceptions. ### Source excerpt Unraveling the magic of async/await: From callbacks to linear code. [Next page]()