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.

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.

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.

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.

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.

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

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

Comments URL: https://news.ycombinator.com/item?id=49221679

Points: 92

# Comments: 17

Comments URL: https://news.ycombinator.com/item?id=49121868

Points: 157

# Comments: 142

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.

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.

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.

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.

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

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.

Also, we wouldn't train on the whole session. A separate critic module, like a reward model, would filter the KV cache to extract the high-value information, like a garbage collector before the LoRA.

That's just an idea though. Right now most research focuses on changing the architecture itself (TITAN, HOPE...) instead.

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.

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.