pizza234

> "gaming is dead now"

One gets the impression that gaming is dead when one's only contact with modern gaming consists of reading headlines about a handful of AAA games.

In reality, the gaming landscape has never been better, as game production has expanded in several directions:

- The barrier to entry into game development has been lowered; People who are talented in design but not programming now have the opportunity to create games

- AAA budgets have increased; those who enjoy large-scale productions will find increasingly large games

- There is still a market for old-school games, so plenty of (especially smaller) companies produce retromodern games

Heck, they even still produce commercial Commodore 64 games o_O

Of course, there is less room for radical innovation, but people do not play only radically innovative games. And regardless, innovation still exists today, especially in smaller-scale productions.

> but this is how progress happens.

This is progress in the same way that a man climbing a tree is making progress toward reaching the moon.

This project is essentially the MoE-of-the day, with some platform-related optimizations.

> Keep going! I personally can't wait for the day when a 1t param model runs off a $200 SSD instead of a $50k rack of Nvidia chips.

That won't happen. Projects like this just give the illusion that that will be possible.

> but are they functionally useful or helpful to anyone currently?

Yes and no, depend on your expectations. Some/many like to run local LLMs just for the sake of it, so anything will do.

MoE are useful on PC systems, at the condition of having high enough memory bandwidth (and large amounts of RAM) - that is, Threadripper/Pro.

The advantage of MoE is that only a subset of the model's experts is used for each token, so not all weights need to be present in VRAM at once. The remaining weights can reside in system RAM, although moving and accessing them still carries a substantial performance cost (and that's why high memory bandwidth is needed).

> 1. speaking German doesn't matter too much in Berlin, except older "Berlin Berlins" most people speak conversational English

This depends on the context: it doesn't matter to speak German in the stage of life where one doesn't interface with the administration (and therefore, older generations). But for those who settle, and are past that stage, German is a requirement.

German culture is very functional, rigid, and dry, and it serves people with that kind of mindset very well. However, it clashes strongly with typical Southern cultures, so it is no surprise that the parent mentioned this. People who value the "softer" aspects of life are not going to feel at home.

There are certainly exceptions, and YMMV.

"AI-assisted" != "AI-written". People who have AI write their articles entirely surely don't mention it at all.

Which are those use cases, considering that the hypothetical server, as described by the GP, is also extremely slow (4/6 hours for a response)?

> This post doesn’t make sense

The author's assumption is that a rewrite is not just a mechanical translation of code - it's also a state of stability. And no release, for the author (I agree) means no stability.

It's like a developer who says that after a week of work, a feature is 90% ready, but the other 10% is still not ready (for release) after months.

A firewall can reduce who gets an opportunity to exploit this, but does not make an authenticated RCE irrelevant. This access pattern is perfectly legitimate for hosted Redis services, for example.

No, that’s a flawed analogy, because this is an RCE. It's (like) having credentials for a network service, then exploiting that service to execute arbitrary code on the Windows host (of course the blast radius depends on the underlying permissions). Access to Redis is not access to the underlying server.

I'm actually confused by the post - indeed why choosing the 27B dense and the 35B MoE models? Given the structure of the post I honestly have the impression that the Spark was purchased out of curiosity more than for a specific purpose (LLMs).

> but used as an attack against other languages, as if to prove they are not good enough for a specific use case.

Ultimately, it comes down to the (subjective, sure) ergonomic limitations of a language. To me, Go without garbage collection and implemented using specific compiler support and significant amount of unsafe operations, does not really represent Go, just as, so to speak, a Rust project containing 90% unsafe code does not really represent Rust. Both are possible of course, and there are even use cases in which they may be desirable in the broader context (ie. the Go runtime).

Therefore, this is not an attack on the language; it is simply an assessment of its ergonomics for particular use cases.

It really depends on the end goal. For personal tools that one uses, LLMs are extremely useful. But publicly used software doesn't only need to be written - it also needs to be maintained. And considering that it's extremely easy to implement features that are not used, vibe coded software tends to be, in best case, a mixed bag, and in worst (I believe typical) case, quickly abandoned.

Vibe coded software is the modern equivalent of the shovelware of the 90s.

> Go's runtime is written in Go. The whole compiler toolchain, GC, compiler, linker, Assembler, is written in Go.

There's some nuance to this. The runtime code uses specific compiler support and restrictions that are not ordinary Go - possible (or even done, like this case) ≠ ergonomic. No doubt of course that for the Go project, this is still a win.

No argument that it's inappopriate, but I wonder if the author works with other programming languages - in some (Groovy, Kotlin, Ruby), "it" is the implicit block parameter.

> Anthropic is not in the programming language market; their post about rewriting Bun in Rust is full of technical details that led to improving the end product for their users

Anthropic absolutely is in the programming language market. If/since AI makes rewrites to certain languages relatively easy, a success story will tie the given language(s) to the given AI company.

Rust may have a tremendous success in the future, because it's much easier to write it with AI (ignoring for a moment whether that's really a good thing). The implication is that Anthropic has a stake in Rust's success.

Also, to be kept in mind that devs advertising successfull rewrites often hide some aspects that are unfavorable to the narrative; typically, how bad was the code before the rewrite), although there are other (significant) aspects that have been omitted.

> Zig's response is a sour opinion piece full of personal attacks.

I take you haven't read Andrew Kelley's article (here: https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.ht...).

Summary:

- Jarred has written Bun with very bad engineering standards

- Jarred has managed public relations very poorly (e.g. ghosting the Zig foundation)

- When they rewrote the project to Rust, and described Zig as poor choice, there has been a negative fallout for Zig

- The ZSF is obviously upset because of the poor publicity

This is summarized at the end of the post:

> Zig users who knew next to none of these facts and have only the surface level understanding that an ex-Zig-user is getting trashed by the language creator. Such people might reasonably worry that might happen to them

As a matter of fact, I also believed the same after reading's Bun's post. This is undeserved though, and that's what Kelley explains.

There's definitely a personal attack somewhat, and this is addressed in the last (added later) section.

> I suspect Anthropic had to turn up its safety guardrails to an 11 to assuage the government’s concerns, as this hasn’t been a one-model problem.

This behavioral change is actually official (https://www.anthropic.com/news/redeploying-fable-5):

> For Fable 5, we made this safety margin much larger than in any prior launch (row B), meaning that many more benign requests would be blocked. We understood that these kinds of false positives would be frustrating for users, but made this tradeoff in the interest of making the model’s other capabilities widely available.

NK is politically aligned with the red countries, and positioned against US. Especially after the Otto Warmbier accident, some believe that Americans/Westerners in NK are in constant danger (my opinion: O.W. did something stupid while drunk; the accusations were obviously fabricated but the incident was not unprovoked), so to those, it may seem surprising that somebody can feel safe there.

> There's no real evidence in here that the IDTech team or the "coders" were specifically let go

Scott Miller said it himself:

> Big day today at Id Software [...] today, Microsoft/XBOX decided half the team was deemed USELESS and needed to be let go [...] With literally the best of the best coders in the industry.

The same applies to ray tracing; the question whether shadows can be rendered accurately and cheaply is also not knowable - but it's very unlikely that ray tracing will become as cheap as rasterization for the same quality target. LLMs are pretty much the same; they're inherently computationally expensive, even if optimizations are in continuous development.

> Seems like an investment into building expertise

Learning LLM internals != using them as daily tools (the latter was the topic of discussion).

Shifting to the learning topic: no need for expensive hardware. Even a 16 GB GPU will do, and that's (relatively) cheap and available.

Not really - it's essentially a workflow.

The steps, described [here](https://github.com/obra/superpowers#the-basic-workflow), are: brainstorming → using-git-worktrees → writing-plans → subagent-driven-development or executing-plans → test-driven-development → requesting-code-review → finishing-a-development-branch.

The principles, described [here](https://github.com/obra/superpowers#philosophy), are: Write tests first, always; Process over guessing; Simplicity as primary goal; Verify before declaring success.

Install it, take a complex tasks, and instruct the agent to implement it; it's easier to watch it in action than to describe it.

In my own experience, the advantage is that it's a very systematic workflow - investigation of requirements, breakdown in simpler steps, and TDD development, among the other aspects.

> Now come back to my first question. An LLM predicts the next word based on all the words before it. That is the whole story. There is no idea sitting underneath.

No!! This is misinformation.

An LLM predicts the next words (tokens) based on the words before it *and* on the internal representations it has learned from training.

Processing language can lead to internal representations that capture patterns and relationships; LLMs can exhibit emergent abilities, including reasoning-like (stress on "-like") behavior, even when they weren't explicitly trained for that.

Making reductionist claims about LLMs, based on next-word prediction, is similar to making such claims about biology, based on amino acids.

> Having a machine that can run some modest local LLMs, like the Gemma 4 12B, is really worth it.

Cloud models are (much) faster, they don't consume so much power/generate heat, they have much bigger (LLM) context, they're much more precise and they have a much wider (engineering) context of the given problem.

Except privacy and use cases that are blocked by cloud models (e.g. reverse engineering), local LLMs are currently an expensive toy.

When I try to program with a local LLM (I'm on a 32/128 GB system), I end up wasting time compared to a cloud LLM.

NTlite has also been around for more than a decade, although it has a freemium model.

> Quake III Arena was pretty entertaining. Doesn't seem like it came from a company that had been ruined for years.

It's not that the company was ruined, but that it had lost some of its creative direction after Romero left (while retaining technical excellence).

LOL, sure this works if one has a time machine or a LOT of money to burn.

32 CPU Epyc (Epyc is required for faster memory access) + 32 GB VRAM + 512 GB RAM is stupid expensive nowadays, and in best case, it will just downgrade to "very" expensive at some point in the future.

This makes sense only if 1. one is paranoid about privacy or 2. they have money to smoke or 3. they need to workaround cloud model restrictions, AND they have to do it routinely (because if not, a oneshot cloud bare metal setup is way cheaper, faster, and allows more powerful models, due to VRAM offering).

I did spend stupid money as well and yet, the system is 2x slower than cloud providers for comparable performance on vision tasks (I still have to test coding). Oh, and it's hot as hell.

> Another CEO with AI psychosis [1]. LLMs are not true AI, they lack common sense (or whatever it's properly called).

If you read the article, you'll find that the it indeed relies on this claim:

> Within a couple of years, possibly much sooner, AI may achieve so-called closed-loop recursive self-improvement (RSI): the capacity to rewrite its own code to become more capable, without human intervention. Should that happen, the result could be an intelligence explosion of a kind for which there is no precedent and no map.

This may be optimistic and/or simplistic, but not impossible.

Flashback came considerably later (1992) than PoP (1989); a single year back then was a lot more significant than it is today. A classic game in between was Another World (1991).

Just out curiosity, PoP ran on 8088/8086, while Flashback on 286/386.

OpenAI and Anthropic are certainly strong drivers, but there's a large demand from many other players: cloud provider, accelerator vendors, and so on. I think there's no end in sight.