pizza234

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.

Slight?? It has 3g of salt per liter, which is very high - not least because 1g of that is sodium. Having said that, I like it very much.

8.8" is a bit too small for my use case, but... oh my, their Win Max 2 is a very impressive machine (10.1") - I'm really shocked at the size. I'm confused by the price, though - 6500$??

Confirmed. Minibooks are amazing in cramped locations (for example, airplane seats), or just to always keep in the bag for support.

There's nothing in the market like them, which is a shame - I think a slightly better quality Minibook (Chuwis are plain crap) would be a very solid laptop.

It isn't realistic to expect a design to be "proper in first place" because requirements change; my opinion is indeed the opposite - I find it natural for programming languages to have a (sort of) lifespan, and for new ones to (sort of) take their place.

Not everyone needs that fast RAM access but for those who do it could be nice to have an option. The writing is on the wall for years now.

There is an option already, at least from AMD, in the HEDT segment - Threadripper/Pro has 4/8 channels (although the bandwidth is not a high as Apple chips).

EDIT: the leads are, in practice, managing a small team, although their exact technical background is unclear ("experienced practitioners who know how to design and deliver digital products", not clear if they're professional software engineers).

I think the use of AI is really missing the point here. The point is that small in-house teams can deliver a lot more quickly and to a higher quality and at a lower cost than large outsourced teams from the big consultancy companies.

This assumes that small in-house teams are inherently effective/efficient, which is not necessarily true.

In this sense, the difference between proven engineering leads (as the article states/assumes) leading a small team versus AI is that the latter is entirely under their control, which minimizes the risk.

So AI vs. small teams is about controlling/guaranteeing effectiveness/efficiency.

The article argues that although this is an asynchronous process:

Long running work: an agent doing a 10 minute task isn’t a ‘request’, it’s a long-running async process.

it should not be stateful at the database/storage level:

Stateful compute: an agent might run multiple turns of a conversation, might process multiple tool calls, and relies on accumulated context. That state is not really ‘database state’, it’s the agents memory.

According to the author, the problem is already solved, but implemented with the wrong design assumptions.

(Uploading a file for conversion could be framed as a slightly different problem from the author's, though, due to size constraints)

Because the speed increase is - on modern, properly tuned filesystems - surprisingly small, due to how RDBMS's manage their pool; by working on large container files, they avoid most of the filesystem overhead.

Vibe coding on consumer hardware is still very limited; this is especially true on GPUs, whose RAM limit is around 16 - maybe 24 - GB for the vast majority (although Macs change the equation).

These are two realworld experiments, whose results are disappointing for those expecting levels of performance comparable to cloud services:

- https://deploy.live/blog/running-local-llms-offline-on-a-ten...

- https://betweentheprompts.com/40000-feet/

The first is even the 35b version of qwen3.6.