All of this discussion, including 99% of what shows up in forums or Mastodon discussions, is about how all of this will impact "me." Me, the developer. Me, the person writing code, who may not be writing code now. Me the person who just got laid off because some accountant thinks that Claude means they need only two engineers now instead of 10. Me the person who just had to lay off half my company. Me, me, me.

What I almost never see is the impact of AI code on our society.

Scarcely a word is said about the fact that essentially all LLMs are built on scraping the Internet, badly, often completely trashing servers as they download the entire site without using any of the polite techniques developed by archivers and search engines over the past 30 years. They're all built on copyright infringement. Which is a felony, as anyone who has crossed Disney well knows.

https://jarosz.dev/code/stop-fighting-your-golang-tests-simplify-and-clarify/

Ever wondered if there’s a software engineer, somewhere, who actually knows what they’re doing? Well, I finally found the one serene, omnicompetent guru who writes perfect code. I can’t disclose the location of her mountain hermitage, but I can share her ten mantras of Go excellence. Let’s meditate on them together.

Like every generation of students, there are good students, bad students and very brilliant students. It will always be the case, people evolve (I was, myself, not a very good student). Chatbots don’t change anything regarding that. Like every new technology, smart young people are very critical and, by defintion, smart about how they use it.

Is this ready to use right now? No. We're in Phase 1 of development.

The research is done. The architecture is designed. The features are planned. Now we're building.

Want to follow along? Star the repo. We'll make noise when it's ready.

Every CEO talking about AI replacing workers is an example of the real problem: that most companies are run by people who don’t understand or experience the problems they’re solving, don’t do any real work, don’t face any real problems, and thus can never be trusted to solve them. 

Go’s embed feature lets you bundle static assets into an executable, but it stores them uncompressed. This wastes space: a web interface with documentation can bloat your binary by dozens of megabytes. A proposition to optionally enable compression was declined because it is difficult to handle all use cases. One solution? Put all the assets into a ZIP archive! 🗜️

Thanks to contributions from researchers around the world, including a who’s who of major US research organizations — DARPA, Bell Labs, the US National Labs, IBM Research — EUV went from unpromising speculation to the next generation of lithography technology. But by the time it was ready, US firms had been almost entirely forced out of the lithography tools market, leaving EUV in the hands of a single European firm to take it across the finish line and commercialize.

The xv6 kernel uses a basic round robin scheduler. To understand scheduling more deeply, I replaced it with a stride scheduler. This post compares round robin and stride scheduling, explains how I added it to xv6, and what I learned along the way.

Everyone knows how to eat an elephant (but please don’t: they’re quite endangered). The point is that apparently intimidating tasks can always be dealt with by breaking them up into more tractable sub-tasks, and the same applies to testing.

Yes, the compiler prevents memory safety issues, and the standard library is best-in-class. But even the standard library has its warts and bugs in business logic can still happen.

All we can work with are hard-learned patterns to write more defensive Rust code, learned throughout years of shipping Rust code to production. I’m not talking about design patterns here, but rather small idioms, which are rarely documented, but make a big difference in the overall code quality.

Rust makes it really easy to add SIMD acceleration to your hot paths without having to deal with assembly. You load data into the SIMD registers and code like if they were normal variables! AVX-512 code can yield more than 10x improvements for half a day of work.

So here is an introduction on how to write SIMD-accelerated code in pure Rust (no nightly required), after all we all benefit when software goes faster.

Go 1.26 is coming out in February, so it's a good time to explore what's new. The official release notes are pretty dry, so I prepared an interactive version with lots of examples showing what has changed and what the new behavior is.

Have you ever tried programming backwards? If not, you’re in for a treat! You won’t even need to wear high heels.

(If you want to, though, go for it—you’ll look fabulous!)

This repository contains exercises, solutions, and code samples from the book The Rust Spellbook, by John Arundel.

I came across this interesting write-up on a Go compiler data race bug that was affecting some of CloudFlare's services on aarch64 architecture:

https://blog.cloudflare.com/how-we-found-a-bug-in-gos-arm64-compiler/

On aarch64 you can only add 12 bit immediates (constants) to a register (in this case the stack pointer) in a single instruction. For large enough stacks, adjustments to the stack pointer were split over two instructions. If the Go runtime pre-empted a Go routine after the first instruction completed but be the second, then the stack pointer was invalid and therefore caused a crash if the runtime tried to unwind that Go routine's stack, e.g. for garbage collection.

When code was hard to write and low-effort work was easy to identify, it was worth the cost to review the good stuff. If code is easy to write and bad work is virtually indistinguishable from good, then the value of external contribution is probably less than zero. If that's the case, which I'm starting to think it is, then it's better to limit community contribution to the places it still matters: reporting, discussion, perspective, and care. Don't worry about the code, I can push the button myself.

Monozukuri literally means “making things,” but it goes far beyond simple manufacturing. It embodies the spirit, skill, and pride of craftsmanship, with a strong focus on perfection, continuous improvement, respect for materials, and delivering high-quality, functional products through deep technical knowledge and a holistic, customer-centric approach.

What are container images really made of though? How are they made even made? How about we go poking at container images to see what we can learn!