Why would they specifically mention the Steam Deck? EAC doesn't have separate flags for Linux and Steam Deck. It's almost certain they intentionally allowed it to run on Linux. They call out Steam Deck by name because it is a popular handheld that has greatly increased the # of Linux users, not because an EAC update allowed it to work by chance.

They said the model is intentionally under-trained since it is mainly for R&D purposes of proving the new architecture. Many people are excited for models in this range as they are a step above the common ~27B models, while not requiring exorbitant sums of money to run like much larger models.

Tofu, seitan, and tempeh all have protein, but they differ from animal protein in that they are "cut" with lots of carbs and fat. I am on a protein-sparing modified fast (PSMF) for bodybuilding goals right now, and there are no viable non-animal whole sources of protein (so, excluding pea protein isolate etc.) I can have. Even seitan is only ~81% protein by calories, which is too low. I am targeting 90% calories from protein right now.

They are definitely good options, along with lentils (which have a similar problem of having more carbs than protein), for vegetarianism+. But they are not a perfect substitute as you cannot get nearly pure protein from them. They also tend to lack the BCAAs that make up a large portion of muscle.

So, you can fulfill most dietary goals purely vegan, but it is harder and more expensive due to limited options.

Plus, meat is tasty. It makes perfect sense people look forward to lab-grown variants that are ethically sourced and have no adverse health effects.

GPT 5.6 Luna is the only non-Chinese model that seems to compete at such incredible price/performance. It's concise too, Claude models are wildly verbose. And Google is nowhere to be found in LLMs right now.

Nix tends to have updates almost as quickly as Arch does, I run a lot of bleeding edge software and have no issues, and the breadth of packages is immense. Nix just has a different style. With the AUR, you can adopt an abandoned package more easily. That has pros and cons (the AUR has recently suffered multiple supply-chain attacks due to packages being adopted and infected).

Nix and NixOS are two of the most revolutionary pieces of software in my experience. Hopefully Nix finds a governance structure worth of it.

Her school did not have adequate resources to handle these students, so they always had multiple students with severe behavioral issues that should have been in a dedicated classroom with a special education trained teacher, but were just in regular teachers' classes. Naturally, the teachers were burnt out from working with too many challenging kids they were not trained to take care of and the other students had worse learning outcomes.

You're right, other things constant, this would not make sense. But this is a strawman. Zig has fast compilation on average compared to systems languages with more automatic memory management, like Rust. In addition, Bun's fork is based on 0.14 Zig, while 0.16 has become much faster.

Take a look at this post by one of Zig's core maintainers explaining why Zig doesn't want to upstream any changes from the Bun fork: https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio....

In short, the Bun fork introduces non-deterministic compilation errors, a terrible problem for a language and its compiler to have. Zig just made changes to type resolution in 0.16 specifically to allow them to implement parallel semantic analysis, but properly without the bug the Bun fork has.

In addition, they have chosen to spend their time building the self-hosted backend and perfecting incremental compilation, which will have orders of magnitude more benefits to compile times than. Matthew already demonstrates a 4x speedup, what Bun claims to achieve, using the self-hosted backend, and 300x speedups with incremental compilation on a large project (Zig itself).

I am sure it is frustrating for Jarred to not get his patch in, but he was rebuffed for good reason. Bun's fork may have worked for them but many people, including the Zig team, would rather Zig do things properly than introduce bugs and tech debt to make flashy headlines.

You're right, a rewrite is in existence, and whether it is good enough to be used or expand upon is what is being considered. I don't think that changes the fact that languages don't live or die by whether or not 1 large project using them continues using them. Especially a language like Zig which has taken plenty time making breaking changes. They know this is par for the course.

>I wonder if that's the mentality that got them in this situation in the first place.

I highly doubt it. To my knowledge, the only "why" Jarred has given is frustration with memory issues. Speculated reasons I see are: 1. Anthropic wants a rewrite to a language with a more favorable AI contribution policy, to avoid bad press by acquiring a framework written in a language that is skeptical of AI code quality. 2. Rust is more stable and a better target for AI-assisted programming or entire vibe coding. 3. Bun is upset Zig does not want to merge their fork into main.

Focusing on the issue Jarred gave as why he started the rewrite, I don't see how Zig got themselves into the situation at all. Zig was always upfront that it aimed to be a modern C: simple language, powerful modern features, and excellent compatibility with all things C. While it certainly has much better behavior concerning memory safety and undefined behavior, it has never aimed for Rust or GC level memory safety.

It's not like Jarred has been begging the Zig devs to implement language changes to make Bun development easier. Zig was always upfront that you will have to manage memory manually, and that allows for operator error. I think Jarred is in this situation because he wants to be, simply. He works for Anthropic, probably has no limit on how many tokens he spends, and may have access to their most powerful internal models like Mythos. I would guess he pointed agents at this problem and let them go, because why not? He has likely has no opportunity cost.

But Bun has open issues and bugs. The test suite doesn't tell us whether it has introduced many new bugs, solved existing ones the test suite doesn't catch, or anything else. Not to mention, the rewrite is 960K lines that nobody understands. How long will it take for the Rust version to be better, and be understood as well as its current maintainers understand the Zig version?

Having a project consider a rewrite isn't so big a deal. Zig has been designed from the ground up with a vision, and isn't worried about taking a while to create a stable API to achieve that vision. The self-hosted backend shows how incredibly fast incremental compilation is when the language is built for it ground-up. Compared to other languages that implement weaker forms of incremental compilation it isn't even close.

I don't think the Zig team is concerned at all.

In addition, a core Zig developer has explained why the PR was rejected, because it would introduce non-deterministic bugs into the compiler, just to achieve a speedup Zig is already gaining thanks to recent work on the self-hosted backend and incremental compilation, which are far more general as well.

In addition, the link in the comment you replied to explains why the PRs Bun opened to Zig would have lowered the quality of the compiler and how Zig has achieved even greater speedups, with more widely applicable features like incremental compilation and the self-hosted backend.

[0] https://ziggit.dev/t/bun-s-zig-fork-got-4x-faster-compilatio...