good things take time go | zig | rust Looking for opportunities in Distributed Systems and Databases git: https://xitter.cf/t.co/E22e9rNh8H
Joined November 2024
- Tweets1.5K
- Following103
- Followers113
- Likes4.1K
Pinned Tweet
Introducing:
Model Based Testing in Zig, A Preview of the Quint-Connect port written in the amazing @ziglang
Watch as we find an invariant violation in realtime with some visualizations and @quint_lang magic!
All of this as just a step in `build.zig`
AI didn't render engineering obsolete, it shifted the moat. Everything is now downstream of the skill "asking the right questions"
amgh retweeted
The critical thing here is that AI, in its current form, can't give you solid foundations. So far all interesting non-slop success stories with AI that I've seen is where all the strong core was already in-place, and AI was following the patterns without being able to screw much.
Which, I want to stress it, doesn't mean that AI can't help you with optimization work. It's just when you optimize a turd you'll get optimized turd, and if you don't know what you're doing you won't even know that you have a turd.
when I started writing my engine, my expectation was that it would take 4 to 5 years to get it to a level where everybody could use it.
instead it took 18 months, and that's because I only even started using AI code in July, after Fable 5.
the actual core runtime of a game engine (the part that actually matters), can be written by hand by an experience programmers in a couple of months give or take.
the problem is the sheer amount of glue code you have to write to make it usable: editor code, serialization code, supporting different graphics features per platform, refactoring systems to make sure everything works together without impacting performance, the list goes on.
that kind of code is neither fun to write nor an exercise in technical thinking, and it made up 70% of the work before.
now we have automation for a big part of it. not for the thinking part imo (Fable knows every trick in the book but it seems to struggle with deciding what to do with it), but for the manual work that came after it.
this will simultaneously unlock incredible progress, and incredible disruption. programming doesn't look the same, jobs don't look the same, running a company doesn't look the same. we will have to figure out the new normal in the upcoming years.
do I miss writing code? every day. I went through rough times this year trying to come to terms with this new reality. part of me wants it back, the other part is excited about what the future will look like.
amgh retweeted
I'd like to make software that advances the state of the art and improves the lives of millions around the world :)
amgh retweeted
This is just clankerslop, e.g. no constraints that weren’t expressed to the clanker with automated verification that those constraints are solved for. To form the full set of such constraints, you’d need to exhaustively imagine the program and rigorously build the set of constraints for all program behavior, implicit and explicit. That assumes they are even testable via automated verification systems, which is not true for many things, especially UI, workflow, and psychology related.
amgh retweeted
Are you becoming a master craftsperson?
Growing in understanding, putting in the hard work to hone your skill, day in day out, becoming the best you can be?
It’s fine to answer no, but a few years of working at your craft (with intention) will compound.
amgh retweeted
The thing I learned this year is that when engineers say they like working on “hard problems”, they actually don't. What they like is puzzle solving, and having a repertoire of patterns that they can pattern match onto traditionally hard problems, usually involving databases or something with scale, etc. And they know that the industry used to pay you a lot for how deep and broad this repertoire was. Unfortunately, in 2026, well, you have a cheat code machine that has infinite breadth and depth for pattern matching. So the question is, do you actually like hard problems? Because there are now hard problems that are a complection of engineering, product, society, culture, politics, and they are fairly intractable, probably unsolvable! Because if you do want to work on those actually hard problems, there is so much money that people will pay you for it. But you’ll have to face that truth about yourself first.
My thoughts on AI and learning new things from first principles. This is my own comment on a PR for my project - a sqlite database clone in Zig from scratch.
too much AI hype, the only drawback i have faced is that I need a faster IO bandwidth on my brain to understand more things at a much faster speed.
I'd be unstoppable.
Like i want to build my own language, a database, a GUI and also contribute to 15 different oss projects.
amgh retweeted
Drop the ego and then curiosity, exploration, and discovery emerge. The best part of technology.
"What if?"
It's better now than ever before.
back to X and this is what i come across. Anyway, this applies for generic software. Not the software that is foundational like databases, compilers, infra software, mission critical software, etc.
only applies to CLI tools, web dev, saas and the like.
X i.e. this platform is dogshit. People dont believe in reading books, strangers dunk on each other, engineers shame each other, language wars are being held every single day.
i came here looking for a job.
i dont think it is worth it anymore.
deleting the account today.
how does AI reduce the understanding gap?
we still need the same amount of time (relative to individual intelligence) to actually understand things.
a poster tweet for how LLMs are supposed to be used BY engineers and not replace them or coding.
code is simply a means to an end
engineering is the discipline and no automation will ever replace an entire discipline which always progresses by intellectual inquiry
One of the changes made to improve Ghostty IO throughput was to introduce a new IO gather thread, bringing our total thread count to 3 per terminal instance. Under heavy IO load, this keeps our VT processing working at nearly full bandwidth without stalls.
Previously, Ghostty's IO thread (since 2023!) followed this general shape:
read_pty(); exit_if_quitting(); process_data()
The problem is that under heavy load, the pty kernel-side buffer becomes full, blocking the writer (e.g. TUI program). So while Ghostty was in `process_data`, the rest of the world just stalled. Then when we got back to `read_pty`, we'd read the next chunk (a syscall), and while we're paying the syscall cost, Ghostty isn't processing VT data.
Additionally, on macOS and Linux, the kernel only gives a max of 1024 bytes out of a `read()` on a pty (even if the buffer on either side is larger). So, when you `read_pty`, you get 1024 bytes and get back to blocking.
I tried reading from the pty until EAGAIN to fill a buffer but it actually didn't move the needle much cause the major slowdown issue were the stalls on eithe rside.
So the gather thread instead sits in a loop of reading from the pty and filling a set of preallocated buffers. If a read is less than 1024 bytes we assume we're not under any write pressure and dispatch immediately. This preserves latency.
But when we read a full 1024 byte we assume we are under write pressure and sit in a CPU spin loop (the context switch on a blocking read is higher than the time it takes the writer side to write to the pty). We do this until we get less than 1024 bytes or a timeout of 3 nanoseconds passes or the buffer is full (64KB). Then we dispatch.
As a result, under heavy load, Ghostty is effectively processing data through our VT processor at 100% efficiency so IO is fully bottlenecked there, for now.
This was all discovered in concert with LLM usage, which helped pull direct kernel source (XNU + Linux) to validate assumptions, write minimal harnesses in C to quickly verify, and rubber duck some of my approaches.