bevy

TIL about #[doc(fake_variadic)] bevy#14697

Willcaster: Rust + Bevy ile geliştirdiğim oyunun fragmanı: kahraman ile bağ kurarak onu yönetmeye çalıştığınız bir oyun store.steampowered.com bir süredir (yaklaşık 4 yıl :-P , ancak profesyonel olarak da rust dev olarak çalıştığım için oyunuma boş zamanlarımda üzerinde çalışa çalışa bu günlere kadar getirebildim) Willcaster'ı Rust ve Bevy ile geliştiriyorum. son fragmanı yaptım, çıkışı 2026 sonu / 2027 başı gibi planlıyorum. Oyunun kabaca fikri şu: her oda 12x12'lik bir tahta, siz üstüne bir yol çiziyorsunuz ve Murkar (kurbağa) o yolu yürüyor. Ama Murkar'ın kendi özellikleri (açlık, temkin, açgözlülük, merak, sadakat) ve size karşı bir güveni var. Altın ya da tuhaf bir ışık, karakter görürse yoldan sapabiliyor, beğenmediği yolu veya savaş tarzını reddedebiliyor. Savaş başlayınca ona nasıl savaşacağını söylüyorsunuz, uyup uymamak onun kişiliğine göre ve sizinle olan güvenine göre de değişiyor. Ona istemediği ama sonunda ona fayda sağlayan bir şey yaptırırsanız size olan güveni artıyor (veya farklı senaryolar) vs. Yani karakteri yönetmiyorsunuz, onunla sürekli olarak pazarlık ediyorsunuz :-) Güven bir puan değil elbette, planınızın ne kadarının gerçekleşeceğini belirliyor ve çok farklı taktiksel şemalarda oyunu oynayabiliyorsunuz. Geliştirme tarafı: - Görsellerin çoğu kendi render kodum. Şu an 160'tan fazla WESL shader dosyası var, altında da küçük, özel bir compute katmanım. GPU partiküller, çimen üretimi ve büyülerin çoğunun geometrisi. Hep aynı kalıbı kullanıyorum: compute bir instance buffer'a yazıyor, özel bir vertex shader ondan gerçek geometri çıkarıyor, fragment ise Bevy'nin kendi PBR'ını çalıştırıyor. Böylece efektler sahnedeki her şey gibi ışık alıyor. mesh shader kullanmıyorum. - Haritadaki ıslak mürekkep gerçek bir 2D fluid, ve ucuz (compute): yol çizdikçe kâğıtta yayılıyor, kıvrılıyor ve birkaç saniyede kuruyor... - Zemin karolarındaki 'parlamalar' (specular aliasing) için TAA yerine geometric specular AA yazmıştım (Tokuyoshi & Kaplanyan, I3D 2019) ve Bevy'ye de PR olarak açtım. ama tabii henüz mergelanmadı :-P yine de merak eden varsa: bevy#24427 - Compute tarafı kendi shader motorum cuneus'tan esinlenme. kapsülleri de burada yaptım. pek çok basit efektleri de buradan deneyip sonra oyuna ekliyorum genelde. altunenes/cuneus - Bazı farklı olduğunu düşündüğüm teknikleri blogumda anlatıyorum, örneğin havuzların düz bir quad üzerinde nasıl "delik" gibi göründüğü: altunenes.github.io ya da nasıl ucuz yoldan çim, ateş vs yapabileceğiniz vs... Tabii artık LLM çağında bunların bir önemi kaldı mı diyebilirsiniz ama genelde bana ilginç gelen kendi çözümlerimi ya da bazı "özel", "modern" paperlardan aldığım şeyleri paylaşıyorum genelde. Yani genel olarak bevy i de en etkili bir şekilde kullanmaya ve diğer insanların da problemlerini çözebilecek bir şeyler yaptığımda bunları paylaşmaya çalışıyorum. bütünüyle LLM karşıtı bir insan değilim yanlış anlaşılmak istemem ancak farklı şeyler yapmaya gelince iş teknik yönlendirmenin hala çok önemli olduğunu düşünüyorum. oyunun en zorlayıcı tarafı (geliştirme açısından) çok detaylı simülasyon scriptleri oluşturmak oldu benim için. Çünkü böylesine karmaşık bir oyunda dengeyi tutturmak ve level design yapmak çok hassas veri analizi gerektiriyor. Türkiye'den Rust/Bevy ile oyun yapan pek görmedim. Rust'la oyun geliştirmeyi merak eden ya da teknik bir şey soran olursa seve seve cevaplamaya çalışırım.

That sounds very simple. And yet it's apparently not: bevy#26055

Bevy instancing: drawing 639,000 units with one draw call per mesh Originally published at tensorust.com. TL;DR: Bevy already instances meshes for you when entities share a mesh and a material. Past a few thousand moving units, we stopped making them entities at all: units live in a plain Vec, each frame builds one 48-byte instance per unit, and a custom render command draws each mesh once. In LAWN WAR that holds 639,000 live units at 25 fps on an RTX 4070, and the thing that finally slows it down is not the GPU or the draw calls. It's the CPU loop that builds the instance lists. Short answer first, since that's what you searched for. Bevy has two kinds of instancing. The automatic kind: if many entities use the same Handle<Mesh> and the same material, Bevy batches them into instanced draws on its own (the custom_shader_instancing example says so in its first lines). For a few thousand objects, use that and stop reading. The manual kind is that same example: you skip entities per object, hand the GPU a buffer of per-instance data, and issue one draw call that renders the mesh N times. That's what you want when you have hundreds of thousands of things that move every frame. Below is the version that runs LAWN WAR, with the real code, the numbers we measured on October 16, 2026, and the traps. !Animated diagram of one LAWN WAR frame at 639,000 units: think() simulates both armies in 10.09 ms, render() culls and writes 48-byte instances in 18.85 ms, flush() hands about 562,700 instances to the render world through an Arc in 0.08 ms, prepare rewrites a persistent GPU buffer, and the GPU draws each mesh once in 35.08 ms, for 25 fps. One frame of LAWN WAR with 600,000 plants and about 38,700 zombies alive. Timings from LW_LOG, Oct 16 2026, 9:11 PM ET, RTX 4070. What is LAWN WAR, and why did it need this? LAWN WAR is a Rust game on Bevy 0.19.1: an endless plants-versus-zombies war in first and third person, where both armies keep growing until the field is a sea of units. It was built on October 2 and 3, 2026, mostly by a coding agent working from Matthew's design notes, and the source is public on GitLab. The design doc asks for "hundreds of thousands of units per side". Every one of them walks, attacks, burns, dies and tumbles through the air when something explodes. The first playable build did it the normal ECS way. Each zombie slot was an entity with a Mesh3d, a material, a Transform and a Visibility, and a system copied positions from the simulation into those transforms every frame. Here's the spawn, from the first commit (src/horde.rs, Oct 2, 2:58 PM): h.entities = (0..h.cap) .map(|i| { commands .spawn(( Mesh3d(mesh.clone()), MeshMaterial3d(fx.vertex.clone()), Transform::from_xyz(0.0, -50.0, 0.0), Visibility::Hidden, NotShadowCaster, ZombieSlot(i as u32), )) .id() }) .collect(); The two stress screenshots we kept from that build show 974 zombies on the field at 36 fps and 916 at 8 fps. We never profiled that version properly, so I won't pin the blame on one Bevy system. What matters is the decision it forced: 2 hours and 10 minutes later the whole thing was rewritten around custom instancing, and units stopped being entities. !Screenshot of the first LAWN WAR build: a small green spore in front of a picket fence with a line of zombies behind it. The HUD reads horde on the field 974, inbound 1,000,000, 36 fps. The first build, one ECS entity per zombie: 974 zombies on the field at 36 fps (QA screenshot, Oct 2 2026, 3:37 PM ET). Step 1: why aren't the units entities? An entity is a great home for a player, a camera or a boss. For 600,000 identical soldiers it's overhead you pay on every frame: change detection, transform propagation, visibility checks, extraction to the render world. So each army is just a flat Vec of plain Copy structs, allocated once at full capacity, with a free list for recycled slots (src/war.rs): #[derive(Clone, Copy, Default)] pub struct Unit { pub pos: Vec2, pub vel: Vec2, pub y: f32, pub hp: f32, // ... 12 more f32 status fields (burn, chill, tox, corpse timer...) pub kind: u8, pub strain: u8, // ... mark, elite, jumped, died_now ... pub alive: bool, /// Left the battle window: free the slot without a death. pub gone: bool, } pub struct Army { pub units: Vec<Unit>, pub free: Vec<u32>, /// One past the highest slot ever used: every loop stops here, not at capacity. pub hw: usize, // ... } That hw field (a high-water mark) is a small thing that matters a lot. The default cap is 600,000 per army, but early waves only use a few hundred slots. Every loop runs over units[..hw], so a skirmish never pays for the empty 599,000. The simulation runs over those slices in parallel with rayon, and finds neighbours through a grid rebuilt every frame with a counting sort: count units per 2 m cell, turn the counts into start offsets, then drop each unit index into its slot. No hashing, no per-cell Vec, two flat arrays. Both armies rebuild at once: rayon::join( || a0.grid.rebuild(origin, size, &a0.units[..a0.hw]), || a1.grid.rebuild(origin, size, &a1.units[..a1.hw]), ); Step 2: what goes into one instance? Each visible unit becomes 48 bytes: three vec4s the vertex shader reads as extra vertex attributes. Position and facing, then scale, animation phase and kind, then tint and glow. bytemuck's Pod lets us cast the whole list to bytes for free (src/inst.rs): #[repr(C)] #[derive(Clone, Copy, Pod, Zeroable, Default, Debug)] pub struct Inst { /// world xyz, yaw pub a: [f32; 4], /// scale, phase, anim kind, extra pub b: [f32; 4], /// tint rgb, emissive (0 = lit) pub c: [f32; 4], } Notice what's missing: a full 4x4 transform matrix (64 bytes on its own) and any bone data. Units only turn around the vertical axis, so yaw is one float, and the shader builds the rotation. Keeping the instance this small matters at scale. At 562,727 instances a frame, the list is about 27 MB, and at 25 fps that's roughly 680 MB a second going to the GPU. Step 3: how do you build 600,000 instances fast? This is the function the chart further down is about. It walks each army in chunks of 8,192 on all cores, skips what the camera can't see, picks a level of detail (LOD) by distance, picks an animation frame, and sorts each unit into a per-mesh list (src/war.rs, render(), trimmed): let lists: Vec<Vec<Inst>> = a.units[..a.hw] .par_chunks(8192) .map(|chunk| { let mut local: Vec<Vec<Inst>> = vec![Vec::new(); nb]; for u in chunk { if !u.alive && u.corpse <= 0.0 { continue; } let p = Vec3::new(u.pos.x, u.y, u.pos.y); let to = p - cp; let d2 = to.length_squared(); // Behind the camera: skip (with a margin for big things nearby). if d2 > 400.0 && to.dot(cf) < -0.15 * d2.sqrt() { continue; } let lod = if d2 < 40.0 * 40.0 { 0 } else if d2 < 120.0 * 120.0 { 1 } else { 2 }; // ... tint for burning/frozen/toxic, elite scale, animation frame ... local[idx].push(Inst::new(p, yaw, scale, phase, an, extra, tint, glow)); } local }) .reduce(|| vec![Vec::new(); nb], |mut a, mut b| { for (x, y) in a.iter_mut().zip(b.iter_mut()) { if x.is_empty() { std::mem::swap(x, y); } else { x.append(y); } } a }); A few choices in there are worth stealing. The culling is one dot product, not a full frustum test: anything more than about 20 m away and behind the camera is dropped, and the GPU clips the rest. The LOD cut-offs are 40 m and 120 m. And each rayon task fills its own lists, so there are no locks; the reduce step just glues them together, swapping instead of copying when one side is empty. The zombies' walk, attack and death animations come from Kenney's CC0 graveyard kit. Instead of skinning on the GPU, each clip is baked into separate meshes (8 walk frames, 4 attack frames, 1 death pose), and a unit picks its frame from its own phase. Every frame is just another mesh with its own instance list. Step 4: how does the list reach the render world without a copy? Bevy renders in a separate "render world" and copies (extracts) what it needs from the main world every frame. Copying 27 MB twice a frame would be silly, so the lists are wrapped in an Arc. Extraction clones the pointer, not the data (src/inst.rs): #[derive(Component, Clone)] pub struct InstanceData(pub Arc<Vec<Inst>>); fn flush(mut commands: Commands, mut b: ResMut<Batches>, mut q: Query<&mut InstanceData>) { for (id, (mesh, list)) in b.lists.iter_mut() { let data = Arc::new(std::mem::replace(list, Vec::with_capacity(list.capacity()))); match b.entities.get(id).copied() { Some(e) => { if let Ok(mut d) = q.get_mut(e) { d.0 = data; } } None => { /* first time this mesh appears: spawn ONE entity for it, with NoFrustumCulling, holding InstanceData(data) */ } } } } So there's still an entity, but one per mesh, not one per unit. That entity gets NoFrustumCulling, because Bevy would otherwise cull the whole batch based on the mesh's own bounds at the origin. The measured cost of this step at 639,000 units: 0.08 ms a frame. Step 5: why not make a new GPU buffer every frame? Bevy's example creates a fresh buffer with create_buffer_with_data for every batch, every frame. That's fine for a demo. For lists that are millions of instances long, it's a GPU allocation per mesh per frame. LAWN WAR keeps each buffer and rewrites it in place with Queue::write_buffer, and only reallocates when the list outgrows it, with 50% headroom: match existing { Some(mut b) if b.cap >= n => { if n > 0 { queue.write_buffer(&b.buffer, 0, bytes); } b.len = n; } _ => { let cap = (n * 3 / 2).max(1024); let buffer = device.create_buffer(&BufferDescriptor { label: Some("lawnwar instances"), size: (cap * size_of::<Inst>()) as u64, usage: BufferUsages::VERTEX | BufferUsages::COPY_DST, mapped_at_creation: false, }); queue.write_buffer(&buffer, 0, bytes); commands.entity(entity).insert(InstanceBuffer { buffer, cap, len: n }); } } Step 6: what does the draw call look like? The pipeline is Bevy's normal mesh pipeline with one extra vertex buffer bolted on. Its step mode is VertexStepMode::Instance, which means the GPU advances through it once per instance instead of once per vertex: d.vertex.buffers.push(VertexBufferLayout { array_stride: size_of::<Inst>() as u64, step_mode: VertexStepMode::Instance, attributes: vec![ VertexAttribute { format: VertexFormat::Float32x4, offset: 0, shader_location: 8 }, VertexAttribute { format: VertexFormat::Float32x4, offset: f4, shader_location: 9 }, VertexAttribute { format: VertexFormat::Float32x4, offset: f4 * 2, shader_location: 10 }, ], }); And the draw is a single draw_indexed whose instance range is the whole list: pass.draw_indexed(islice.range.start..(islice.range.start + count), vslice.range.start as i32, 0..ib.len as u32). One call, however many units use that mesh. If you want the concept explained from scratch in raw wgpu, the Learn Wgpu instancing chapter is the clearest walkthrough I know. Step 7: who animates 600,000 zombies? The GPU does. The CPU writes a phase and an animation kind; the WGSL vertex shader turns that into motion. Here's the zombie shamble from src/inst.wgsl: if anim == 1u { // Zombie shamble: lean forward, rock side to side, lunge when attacking. let gait = sin(t * 4.5 + ph * 7.0); let lean = -0.12 - extra * 0.6; p = rz(rx(p, lean), gait * 0.12); n = rz(rx(n, lean), gait * 0.12); p.y = p.y + abs(gait) * 0.05; } Plants sway harder toward the top and recoil when they fire, corpses lie flat, debris tumbles, and lightning bolts are a unit cube stretched between two points. Smoke is the clever bit: there's no alpha blending at all. A negative "emissive" value means see-through, and the fragment shader throws away a share of pixels using a 4x4 Bayer pattern. No sorting of half a million transparent things, ever. !Screenshot of LAWN WAR at wave 28: a cactus-like evolved plant hero on a desert lawn, a front line of glowing plants stretching to the horizon. The HUD reads your army 600K / 600K, enemy 38.4K, 26 fps. The 600,000 cap run, Oct 16 2026, 9:12 PM ET: 600K plants and 38.4K zombies alive, 26 fps in the corner. Bot-driven QA screenshot, unedited. So what does it cost at 639,000 units? We measured it tonight. The game has a QA mode that launches straight into a war, plays itself with a bot and prints timings every 2 seconds (LW_LOG=1, using Bevy's RenderDiagnosticsPlugin for GPU time). Five runs on Oct 16, 2026, 9:11 to 9:17 PM ET, same wave (28), same stage (30), only the army cap changing. The shipped build, 1600x900 window, RTX 4070, i7-13700KF. Each number is the average of 16 to 21 samples after the first 12 seconds. - 5,568 units: 50 fps. Most of the 186,000 instances are explosion particles, not units. - 27,934 units: 61 fps, CPU 9.17 ms, GPU 10.56 ms. - 115,217 units: 49 fps, CPU 11.31 ms, GPU 15.60 ms. - 277,469 units: 40 fps, CPU 19.17 ms, GPU 20.19 ms. - 638,734 units: 25 fps (23 to 28), CPU 34.82 ms, GPU 35.08 ms, 562,727 instances a frame. The 115,000 run lines up with what the design doc recorded on Oct 2 ("~110k units 9-13 ms CPU and 10-14 ms GPU"), on a different graphics backend, which is a nice sanity check. !Bar chart of CPU milliseconds per frame. render() instance building: 0.20 at 5,568 units, 0.69 at 28K, 2.27 at 115K, 7.26 at 277K, 18.85 at 639K. think() simulation: 0.74, 1.13, 2.46, 4.79, 10.09. Frame rates 50, 61, 49, 40, 25. Per-system CPU time per frame, five runs with different army caps, Oct 16 2026, 9:11 to 9:17 PM ET. Source: LW_LOG spans, averaged over 16 to 21 samples per run. The surprise is in the per-system breakdown. Going from 28,000 to 639,000 units (23 times more), think(), the whole two-army simulation, went from 1.13 ms to 10.09 ms. That's under 9 times the cost, thanks to the counting-sort grid. render(), the loop from Step 3 that only builds instance lists, went from 0.69 ms to 18.85 ms, 27 times the cost. At full size, building the lists costs more CPU time than simulating the war. Nothing in the timings pointed at the draw calls. The GPU did get slower as the war grew, but steadily, and it finished at 35.08 ms, neck and neck with the CPU. !Bar chart of whole-frame CPU and GPU milliseconds. CPU 8.06, 9.17, 11.31, 19.17, 34.82; GPU 15.47, 10.56, 15.60, 20.19, 35.08, for 5,568, 28K, 115K, 277K and 639K units. Whole-frame CPU vs GPU time, same five runs. The smallest run has the most GPU time per unit because 173,000 explosion particles dominate it. What broke along the way? - Meshes without vertex colours crash the pipeline. The shader reads @location(5) color. A Bevy primitive like Sphere or Cuboid has no colour attribute, so the pipeline fails validation at location 5. The fix is a three-line helper, inst::white(), that adds white vertex colours to every primitive before it's instanced. - Slot recycling needs its own flag. An early version marked "free this slot" with a magic hit-point value. Late-game damage numbers got big enough to blow straight through it (the HUD in the screenshot above shows 45.8 trillion HP). Now units that leave the battle window set gone = true and go back on the free list without counting as a death. - Shader compile time on DirectX 12. On Oct 2 this PC had no Vulkan adapter, Bevy used DX12, and the shader compiler (FXC) took about 40 seconds per launch. The faster DXC compiler broke the particle crate, bevy_hanabi, so the game hides the wait behind a loading screen. Tonight's runs, on a newer NVIDIA driver (617.42), picked Vulkan instead. Check which backend your log line says before you blame your code. - Parallel QA launches lie. Running two copies at once slowed shader compile for both and skewed the screenshots' timing. Measure one at a time, which is how the five runs above were done. What would I try next? The chart says the next win is in Step 3, not in rendering tricks. My bet, untested so far: keep the instance lists alive between frames and only rewrite units that moved, or skip the CPU list entirely and do the culling and LOD pick in a compute shader that writes straight into the instance buffer. That's the "GPU-driven" direction, and Bevy's own renderer has been heading there for its built-in meshes since 0.16. Either could plausibly take 10+ ms off the frame. If someone has done the compute-shader version in Bevy, I'd genuinely like to see the numbers. Do this in your project 1. Start with Bevy's automatic instancing. Same mesh handle, same material handle. Only go custom when entity count, not triangles, is what hurts. 2. Keep mass objects as data. A Vec of Copy structs, a free list and a high-water mark. Entities for the few things that need them. 3. Shrink the instance. Pack position plus yaw instead of a 4x4 matrix. 48 bytes instead of 64+ adds up at half a million. 4. Build lists in parallel with private buffers. par_chunks, one Vec per mesh per task, merge at the end. No locks. 5. Hand off with an Arc, and add NoFrustumCulling to the one entity per mesh. 6. Reuse GPU buffers. write_buffer into a buffer with headroom; reallocate only on growth. 7. Animate in the vertex shader, and dither instead of alpha-blending when you have huge counts of transparent things. 8. Log per-system timings from day one. Without the spans, we'd have guessed "too many draw calls" and optimized the wrong thing. If you're building in Rust, the write-up on rendering Chinese, Japanese and Korean text in our own Rust game engine covers the other engine, and the geodesic live wallpaper is another GPU-in-Rust side quest. LAWN WAR itself was written with coding agents; what broke running 20 of them on one PC is the story of how that works without melting the machine. Our other Rust game, O'BLOCK, a sneaker-flipping sim where you haggle from a $300 shoebox to a billion, is out now, free on Steam. Its only money is the $4.99 Supporter Pack. What's the biggest unit count you've pushed through Bevy, and what fell over first: the CPU, the GPU, or you?

Bevy: A refreshingly simple data-driven game engine built in Rust (48.9k stars) What it does All text below is quoted directly from the project README. >Bevy is a refreshingly simple data-driven game engine built in Rust. It is free and open-source forever! Design Goals: - Capable: Offer a complete 2D and 3D feature set - Simple: Easy for newbies to pick up, but infinitely flexible for power users - Data Focused: Data-oriented architecture using the Entity Component System paradigm - Modular: Use only what you need. Replace what you don't like - Fast: App logic should run quickly, and when possible, in parallel - Productive: Changes should compile quickly ... waiting isn't fun >Bevy is still in the early stages of development. Important features are missing. Documentation is sparse. >Bevy can be built just fine using default configuration on stable Rust. Repository bevyengine/bevy Repository stats |Metric|Value| |:-|:-| |Stars|48,859| |Forks|4,911| |Last release|v0.20.0 (2026-10-08)| |Languages|Rust 94.6%, WGSL 5.3%| |Contributors|1,570| |AI contributor accounts (Claude / Codex / Cursor / Copilot)|None| |AI co-authored commits|Claude: 1| Main contributor |Field|Value| |:-|:-| |Name|Carter Anderson| |GitHub|@cart| |Commits to this repo|1,559 (top contributor)| |Bio|Creator of Bevy Engine | GameDev | Programmer | Artist | Previously Senior Software Engineer at Microsoft| |Company / Location|@bevyengine| |Followers|2,007| |Public repos|45| |On GitHub since|2012-10-31| -------------------------------------------------------------------------------- Discover the best GitHub repos without the endless scrolling. Get top repos organized by category (AI, DevOps, Databases & more), plus key takeaways from developers' most useful comments - all in one free, twice-weekly newsletter. 👉 Get the best repos & community insights - Free

Cloudflare Workers and Deno Deploy: the six-month migration window Deno's entire team is joining Cloudflare. If you host an application on Deno Deploy, the announcement gives you a six-month operating window before the service shuts down. Cloudflare Workers is the destination named in the migration-support promise for paying customers. The Deno runtime has a separate, longer maintenance commitment, and keeping those two clocks separate makes the announcement much easier to act on. {% embed youtube.com %} TL;DR - Deno Deploy will operate for six more months. Paying customers are promised migration help for moving to Cloudflare Workers. - The current team will maintain the Deno runtime for another year, with monthly bug-fix and security releases, then end its development of the runtime. - Deno remains open source. JSR, the JavaScript and TypeScript package registry, continues operating, with its infrastructure moving to Cloudflare. - The proposed workerd/celld merger and distributed self-hosting effort are future work. Cloudflare's joint announcement documents a present scaling limitation for self-hosted Durable Objects. Cloudflare Workers gains the Deno team Ryan Dahl's announcement says the entire Deno team is joining Cloudflare. Dahl created Node.js and later Deno, so the move brings people with a long history of building JavaScript execution environments into the Workers platform. The announcement does not establish a deal price or enough corporate detail to infer a particular transaction structure. Deno is a runtime: software that executes JavaScript and TypeScript outside a browser. Deno Deploy is the hosted service that runs applications for you. JSR is a package registry. Those names often share a paragraph, but they sit at different places in an application's dependency chain. A package registry staying online tells you where packages can be obtained. A hosting shutdown tells you where your application will eventually stop being served. A runtime-maintenance commitment tells you who will keep shipping fixes for the execution environment. The joint Cloudflare post by Dahl and Kenton Varda explains the architectural direction. The team plans to merge workerd, the open-source Workers runtime, with celld, Deno's infrastructure system, and improve first-class self-hosting. Ryan and Bert will lead that effort. Further announcements are promised in the coming months. That gives developers a direction to watch and an existing deadline to manage. The merged platform's eventual features cannot substitute for a migration plan you need to begin today. My dependency manager has many talents; hiring the next maintainer has so far escaped its scope. Deno Deploy: turn six months into an inventory The primary announcement says Deno Deploy will continue operating for six months before shutting down. It specifically promises migration support for paying customers moving to Cloudflare Workers. The wording supplies an operating window, without giving an exact calendar shutdown day in the statement cited here. It also leaves the extent of free-customer assistance unspecified. I would start by listing everything the hosted application relies on. This is a practical recommendation, rather than a claim that Deno or Cloudflare has published a universal migration recipe. A useful inventory includes database connections, background work and stored data. Write down which service owns each piece and how it can be tested independently. For database connections, identify the actual connection path and the credentials involved. An application successfully accepting an HTTP request tells you little about whether its destination environment can reach the same database. For background work, identify what triggers it and what happens if it runs twice or misses a run. For stored data, identify which data needs to move, who owns the export and how you would recognize a complete transfer. Then choose a small, representative workload for a trial migration. Include the stateful operation you are most worried about, even if the landing page would make a prettier demo. Record the expected behavior before moving it. You want a result that can be compared with the current application, especially around persistence and retries. Keep the migration assistance promise attached to its actual scope. Being a paying customer moving to Workers is the case explicitly named by Deno. That statement alone does not prove that every application is a drop-in replacement or that every Deploy integration has an identical Workers feature. The appropriate next step is to ask about your application's dependencies, with an inventory that lets someone give a concrete answer. Six months is enough time to put this work on a calendar. It is also enough time to keep saying you will put it on a calendar until the calendar becomes the incident. Deno runtime maintenance: name an owner The runtime commitment is another year of monthly releases containing bug fixes and security updates. After that, the current team says it will end its development of Deno. The source remains open, and others are welcome to continue it. JSR continues operating, while rusty_v8 also receives continued support and work toward integration into workerd. For a developer running Deno on infrastructure they control, this is a maintenance-ownership decision. The announcement does not say that an installed executable suddenly stops functioning on October 9. It changes the forward commitment of the people who maintain it. An open-source license preserves the ability to inspect the code and continue development. Continuing maintenance takes people, time and a release process. A possible fork should be evaluated as an actual project when one exists, with evidence of who maintains it and how fixes are delivered. The permission to fork is valuable; a staffed maintenance effort still needs to be organized. I would put a named owner beside the runtime in the same inventory used for the hosting migration. That person can track monthly releases, identify the features the application depends on and decide what evidence would justify staying with a future maintenance project. The choice may differ between a small internal tool and a service with a larger operational commitment. Keeping JSR online helps preserve a separate part of the ecosystem. It does not answer every application's execution or hosting question. Treat each layer as its own dependency, so that good news about one layer does not hide a deadline in another. Durable Objects and the self-hosting gap The Cloudflare post describes a Durable Object as an individually addressable server with its own SQLite database, single-threaded JavaScript and WebSockets. Its example assigns one object to each chat channel. That distributes state and connections by channel, giving the discussion a concrete unit of ownership. The important qualification is Varda's statement about workerd's current Durable Objects implementation: it is implemented “only in a single-instance way, good enough for local testing, but unable to scale.” The context is self-hosted Durable Objects. Applying that sentence to every workerd workload would make the claim broader than the source supports. The proposed merger with celld is the positive counterweight. Dahl describes celld as a Rust binary whose only external service dependency is object storage. Bringing the systems together is intended to improve distributed self-hosting. That is a vendor architecture description and a future direction, rather than our independently reproduced operational result. For someone evaluating self-hosting, the questions follow directly from this gap. What can the current system do? Which part needs distributed state ownership? What has actually shipped by the time you need it? A local test environment can be useful while a production deployment needs additional behavior. Keep both facts in view when reading the roadmap. Also today: Microsoft MXC and Bevy 0.20 Microsoft MXC is an embedded SDK for running untrusted code, such as model output or plugins, under containment policies. Its 1.0 release was published October 7; its public-release history reaches June 2. Today's discussion should not turn that older history into a claim that the repository was created today. The SDK offers different execution backends, and their isolation boundaries differ. Its README explicitly warns that audit mode turns off all sandbox security for the workload being analyzed and must never be used to run untrusted code. Audit is for trusted policy analysis. Bevy 0.20 arrived October 8. Bevy is a free, open-source Rust game engine. The episode uses the Solari author's real footage to show shadow-lag and reflection improvements, alongside the release's number-input widget demonstration. Solari remains experimental and requires ray-query support. Metal support comes with a missing built-in macOS denoiser; the release does not promise DLSS on a Mac. Optional ReSTIR is off by default, with documented shadow-quality tradeoffs, especially in motion with many lights. These are useful graphics improvements with hardware and quality qualifications attached. Verdict: NEEDS REVIEW I stamped this episode NEEDS REVIEW. Plan the hosting migration and name the runtime maintenance owner. The self-hosting roadmap is worth following, and the immediate commitments are specific enough to make the first decisions now. Keep the Deploy deadline and the runtime deadline on separate lines. FAQ Is Deno Deploy shutting down immediately? The announcement says it will operate for six months before shutting down. It promises migration support for paying customers moving to Workers. An exact shutdown day is not supplied in the cited wording. Will Deno remain open source? Yes. The current team's runtime maintenance commitment lasts another year, after which it will end its development. Others are welcome to continue the open-source project. Is JSR closing too? JSR will continue operating. Its infrastructure is moving to Cloudflare, according to Deno's announcement. Is distributed self-hosting ready today? The workerd/celld merger and first-class self-hosting work are announced plans. The joint post explicitly identifies the current single-instance limitation for workerd's self-hosted Durable Objects. Sources - Deno: Deno is joining Cloudflare - Cloudflare: joint announcement and self-hosting direction - Microsoft MXC README - Microsoft MXC 1.0 release - Bevy 0.20 release - Solari author: realtime raytracing in Bevy 0.20 - Bevy 0.20 experimental Solari feature requirements Cover portrait: Ryan Dahl at YUIConf 2010, photographed by David Calhoun, CC BY 2.0, via Wikimedia Commons. Cropped, background removed and mirrored. It is a historical portrait. --- *This article expands on an episode of The Daily Diff, a five-minute daily video on what shipped and what broke in tech. Watch the episode · Subscribe on YouTube · the written diff lands in your inbox every morning at thedailydiff.dev.* Video transcript and primary sources

I was curious how the design was arrived at and found some of the trade-offs discussed in this issue[0]. I personally liked the idea of using a combination of semicolons and commas to separate entities and components; but oh well, I guess we'll get used to the double-dash. [0]: bevy#25616

It is coming! I have a working MVP, and the first part of that is in review now: bevy#26043