Ace: aceofspadeshq at gee mail.com
Buck: buck.throckmorton at protonmail.com
CBD: cbd at cutjibnewsletter.com
joe mannix: mannix2024 at proton.me
MisHum: petmorons at gee mail.com
J.J. Sefton: sefton at cutjibnewsletter.com
Chavez the Hugo 2020
Ibguy 2020
Rickl 2019
Joffen 2014
AoSHQ Writers Group
A site for members of the Horde to post their stories seeking beta readers, editing help, brainstorming, and story ideas. Also to share links to potential publishing outlets, writing help sites, and videos posting tips to get published.
Contact OrangeEnt for info: maildrop62 at proton dot me
My friend's panel raised a point I keep coming back to: if we sprint to deliver something, the expectation becomes to keep sprinting. Always. Tired engineers miss edge cases, skip tests, ship bugs. More incidents, more pressure, more sprinting. It feeds itself.
Recently, a colleague of mine at Modal rewrote an external system that integrated deeply with the Linux kernel. The initial rewrite was a simple translation of a C codebase to a Rust one, in preparation for some custom feature work. The resulting code wasn't bad, nor was it un-idiomatic Rust. What it also wasn't was Good Code. It was hard to read and understand, would have been difficult to extend and maintain, and it wasn't even clear to us why we'd taken the burden of rewriting and maintaining this extra system.
The initial rewrite also relied heavily on coding agents.
Oops. But:
This same colleague then invested time into understanding the kernel subsystem, the exact reasons why the original C program was written how it was, and rewrote the Rust translation himself. The difference was night and day; the code flowed naturally, explained itself and the underlying subsystems, and may genuinely be some of the nicest parts of the entire codebase. Better, I think, than even the original C, despite this type of program being arguably one of the best places to use C over Rust.
It was the first time in weeks, maybe months, that I'd felt something that used to be common in my day-to-day: excitement about the lines of code in front of me.
You're not burned out. You're just tired of this shit.
So Claude Code wrote a C compiler. All by itself. Mostly.
Is it any good?
Well, that's a complex question.
Does it work?
It can compile - though not link - the entire Linux kernel without errors. It can compile and link the SQLite database. So it's technically correct, for the most part, which is a significant achievement.
Is it useful?
Benchmarking SQLite compiled with this tool vs. the standard GCC toolchain, the code produced was on average 720 times slower, and up to 158,000 times slower in extreme cases. A test suite that took ten seconds for unoptimised GCC code took two hours to run with the Claude compiler.
So an interesting trick, but about as practical as that 512-byte compiler from yesterday.
5Gb switch have basically not existed until very recently. 5Gb network cards were easy to find, but you had to use a 10Gb switch with the port running in 5Gb mode.
And you still do. This model has a 10Gb switch chip, but the ports are permanently limited to 5Gb mode, because reasons.