Readit News Whatever your feelings are about OOP and memory management, the reality is that if you choose GTK, you're forced into interfacing in some way with the GObject type system. You can't avoid it.
Well you can avoid it and we did avoid it. And it leads to a mess trying to tie the lifetimes of your non-reference-counted objects to the reference counted ones. There was an entire class of bug that kept popping up in the Ghostty GTK application that could basically be summed up as: the Zig memory or the GTK memory has been freed, but not both.I know containers are hard to use today, and I don't think we have found the right magic yet. But we're working on it, because all of these tools are so much better in a box.
brew install boldsoftware/tap/sketch
CEREBRAS_API_KEY=...
sketch --model=qwen3-coder-cerebras -skaband-addr=
sketch --model=qwenIt is relatively easy to get the agent to use it, most of the work for us is surfacing it in the UI.
1) people who haven't programmed in a while for whatever reason (became executives, took a break from the industry, etc)
2) people who started programming in the last 15 or so years, which also corresponds with the time when programming became a desirable career for money/lifestyle/prestige (chosen out of not knowing what they want, rather than knowing)
3) people who never cared for programming itself, more into product-building
To make the distinction clear, here are example groups unlikely to like AI dev:
1) people who programmed for ~25 years (to this day)
2) people who genuinely enjoy the process of programming (regardless of when they started)
I'm not sure if I'm correct in this observation, and I'm not impugning anyone in the first groups.
I definitely don't love the process: design docs, meetings, code review, CI, e2e tests working around infrastructure that acts too good to spin up in my test (postgres what are you doing, I used to init databases on machines less powerful than my watch, you can init in a millisecond in CI).
It is pretty clear to me agents are a key part of getting work done. Some 80% of my code changes are done by an agent. They are super frustrating, just like CI and E2E tests! Sometimes they work miracles, sometimes they turn into a game of wackamole. Like the flaky E2E test that keeps turning your CI red, but keeps finding critical bugs in your software, you cannot get rid of them.
But agents help me make computers do things, more. So I'm going to use them.
It can be as simple as changing the size of a vector from one thread while the other one accesses it. When executed sequentiality, the operations are safe. With concurrency all bets are off. Even with Go. Hence the argument in TFA.
Show me the exploits based on Go parallelism. This issue has been discussed publicly for 10 years yet the exploits have not appeared. That’s why it's a nice theoretical argument but does not hold up in practice.