rahen

A lot of mistakes in this article, although it's well-intentioned.

There is a direct lineage from the PDP-1 to the PDP-4, and the 18-bit lineage ends with the PDP-15 (missing).

The dual-mode PDP-12 (PDP-8 + LINC) is missing from the 12-bit lineage.

The VAX (VAX-11 initially) was an offspring of the PDP-11 and the VAX-11 could natively run PDP-11 user-mode code. DEC then tried to use the VAX to unify both the 10 and 11 markets.

The PDP-11 and VAX software heritage lives on mostly in C and UNIX (NetBSD being the closest relative), and in VMS / NT. The PDP-10 heritage lives on mostly in Emacs.

"However, even its most powerful configuration wasn’t powerful enough to attract many pdp-10 users." They didn’t serve the same markets.

The PDP-10 was a time-sharing system that shone more for LISP than FORTRAN. For heavy number crunching and matmuls (the FORTRAN playground), 16-bit PDP-11s were usually used, with an auxiliary array processor such as the AP-120B or the CSPI MiniMAP. Those array processors could deliver more than 10 MFLOPS back then, when a minicomputer with a 50-100 KFLOPS FPU was already considered fast (FPUs were an expensive option back then).

The benchmarks against Opus 5.5 and GPT-6.1 Sol look pretty good for 3D generation: https://x.com/atomic_chat_hq/status/2107516529608700383

It's in the announcement: "ML4 was trained from scratch on 3,800 NVIDIA Grace Blackwell GPUs in Mistral’s own datacenters in Europe".

https://mistral.ai/news/mistral-large-4/

Give them time. ML 4.0 was just pretrained. Mistral will certainly use it as the base for distillation and RL for smaller, better, more efficient iterations, just as the competition does.

I’d rather have one European AI lab like Mistral, with the financial firepower and compute to pretrain its own large models, than 20 weak labs that fine-tune Chinese models.

AI needs big bucks, and Mistral is Europe’s Anthropic.

Mistral is the only major non-Chinese contender in the AI race releasing open-weight models. I’d rather trust that French weights haven’t been backdoored than Chinese ones. Heck, I’d even trust Mistral more than Anthropic for sensitive work.

You asked if there was "tangible benefit to end user or developer using ai assisted development". My answer is no, it can be done but has no benefits for this use case. Use Rust here, because its compiler acts as an AI safety net.

Being a code artisan is not gatekeeping. It means if you're used to being close to the metal and sometimes know better than the compiler, Zig is for you. If you're not, use Rust.

Use Rust if you're not writing code yourself.

The borrow checker will catch all kinds of bugs that AI-generated code will happily compile in Zig but will blow up as UB at runtime.

Zig's value prop is different and closer to a modern C: it fits in your head and maps fairly closely to assembly. There is no hidden control flow or hidden allocations, so you can tweak performance at a very low level. You're the pilot, not the compiler.

Rust trades the low-level clarity for compiler-enforced safety. If you're not a code artisan or don't care about being one, then please use Rust.

It definitely is vibe-coded, but yogthos is a competent programmer who has been working on public Clojure projects and repos since 2009, and has maintained a large Clojure framework since well before LLMs were a thing.

I don't think "2k commits in 2 months" is enough to dismiss as slop when it's being developed by a competent Clojure dev.

Not slop, though. The main developer is Dmitri Sotnikov (yogthos), who's been around in the Clojure scene for a long time and knows what he's doing.

However, you're right to point out that the development is moving really fast.

I'm building a Clojure compiler for machine learning (https://github.com/sheaf-lang/sheaf), and after 9 months, it's still very far from being production-ready.

Four day old repo with 92K lines added per day, okay...

There is basically no evidence of human competence in this repo. This is yet another "rewrite in Rust with Claude" project that brings nothing to the table, but devalues expert work by mimicking competence without the expertise.

This was common back then. The PDP-8 had eight primary instructions, although one of them was multi-purpose. This helped keep the hardware simple when we didn't have ICs.

RISC isn't about having a small ISA but about a regular, orthogonal instruction set.

The author has also published a Setun-70 emulator (a Soviet ternary computer rather than a binary one):

https://github.com/Zaneham/setun70-emulator

I was initially surprised because this is not a good use case for Scheme. The current C implementation is clean and efficient, and I'd rather use Scheme to replace some messy Python code with its dependency hell.

And then I saw this: "As mentioned above, some code has been automatically translated from C to Scheme, using generative AI. This is not creative work, and as such, the authors of Goodev cannot claim copyright for it."

Somehow I wish those tokens would had been more usefully spent on porting code where a sound language could actually make a difference.

Not very far off, the IBM 1130 was very much built around its punch-card reader. I've written a backprop in Fortran IV for the 1130 and while it works, it was tedious.

Add ten more years, and the IBM 801 could have been a CPU architecture good enough to scale all the way to the present day without emulation, unlike the 360.

What kind of virtualization do you use internally? I assume some kind of LXD fork? OrbStack really feels like a single-node Incus host.

The first AI winter was largely triggered by Minsky in a book he published in 1969, which mathematically proved that single-layer perceptrons couldn't solve non-linear problems. Favorite quote: "Our intuitive judgment is that the extension [to multilayer systems] is sterile."

Yet we had the computational power to run backpropagation in the 1960s and small Transformers in the 1970s (I'm the author of both):

https://github.com/dbrll/Xortran (backprop on IBM 1130, 60s)

https://github.com/dbrll/ATTN-11 (Transformer on PDP-11, 70s)

What was missing wasn't the raw processing power, but the ideas and algorithms themselves. Because funding and research were completely discouraged during the AI winter, neural networks research was left dormant and we lost two decades.

In the early days of machine learning (before the first AI winter), networks like this were often implemented and trained in hardware: https://en.wikipedia.org/wiki/ADALINE

That was the first thing that came to mind when I read "the smallest brain you can build". Nowadays, that "small brain" would likely be built on a breadboard using op-amps instead.

The Gamma 3, which competed with the 604, only had about 400 tubes as far as I remember: https://en.wikipedia.org/wiki/Bull_Gamma_3

Both the 604 and the G3 were bit serial to save components.

Scheme has a coherent and minimalist design, but its ecosystem and abstraction facilities feel too sparse for large applications.

When I started building a Lisp-based machine learning framework, Guile seemed like the right choice because it provides GOOPS and generic functions, yet I still ended up with a lot of boilerplate to compensate for the lack of a strong type system.

Scheme feels to me like C is to C++: not ergonomic for large-scale application development. Go is one of those languages that has both minimalism and productivity.

That's an idea I had a few months ago: after going through a compaction once the KV cache is nearing capacity, accumulate this knowledge into a dataset to fine-tune a LoRA during offline hours.

This would create a three-layer memory system:

- Stable long-term memory (initial base weights)

- Mid-term memory built from the compactions and replay buffers

- Short-term memory (KV cache)

Sleeping would just be a fancy term for consolidating and transferring information from one memory layer to another during offline hours. Maybe that's also what the brain does while sleeping.

Strictly speaking, this is very domain-specific and doesn't enable any performance that Triton couldn't already achieve (eliminating global memory round-trips via epilogue fusion is nothing new). The real takeaway is the design shift for LLM-driven codegen rather than handcrafted kernels.

LLMs are still bad at low-level hardware optimizations, but really good at high-level composition. Designing compiler abstractions with a restricted, composable API so an LLM can easily glue expert-written blocks together is a smart move. I suspect this will eventually become the norm for codegens as we move to agentic development.

There is ongoing research on neural cellular automata, as they seem to be a very efficient way to generate pretraining tokens: https://arxiv.org/html/2603.10055v1

Emacs Lisp is a descendant of PDP-10 MAClisp, which makes it one of the oldest Lisp dialects still actively maintained. Whether it's version 24.5 or 30.2 doesn't make much of a difference semantically.

Previous: https://news.ycombinator.com/item?id=47861270

Obvious slop still makes it to the front page of HN, and sometimes farms GitHub stars.

These posts also usually get all these glowing comments from users who clearly haven't checked the code. It's even worse when authors get busted and claim "Okay, Claude wrote it, but the design is mine" despite clearly not understanding the output themselves.

Unfortunately, that makes high-effort projects less visible. The SNR will probably keep getting worse until slop can be flagged on HN.

Ink is the Electron of text-based apps. I tried OpenCode out of curiosity, it routinely used hundreds of megabytes of memory.

I'll stick with Emacs as my TUI platform of choice, especially for tool-assisted development.

> try making a DAW in it...

It would in fact work pretty well for a tracker.