No, this has nothing to do with processes. It has to do with the `context` package, which the best way to do goroutine cancellation in Go, but if you look how it works under the hood, it requires a lot of hacks, because there is no direct cancellation support for operations in the runtime. For example, every single `Read()` in the standard library would have to be wrapped by `AfterFunc()`, not all of them actually do it, so some reads are cancellable, some reads are not. It's all just best-effort with no guarantes.
It's true for almost all pthread implementations, not all. But when talking about asynchronous I/O runtimes and coroutines, you have more options. Systems like Tokio, or zio (the one I'm working on), give you a task handle, and when you call `cancel()` on the handle, it will cancel whatever async operation the task is currently running. And it does so reliably.
I was amazed how well are goroutines integrated into the language when I saw the first videos from Rob Pike. Then I actually started using Go for concurrent code, and noticed one thing, it's extremely easy to leak goroutines. There is no proper way to cancel them, they need to cooperate via select/context. Go developers eventually learn hacks to deal with it, but the simple go+chan style of programming style you see in tutorials is usually not safe. I still consider Go a remarkable piece of software. The runtime really doesn't have any seriously bad edge cases, it just works. But as a developer, I now prefer a slightly more explicit approach to concurrency. I've spent the last year developing an async runtime for Zig and I'm now more comfortable writing concurrent code in Zig than I was every using Go. I have more options for how to handle closed channels, I can cancel any operation, etc.
It takes 10+ years for any storage engine to iron out all the wrinkles, get it to a state where it's both fast enough, and you can trust it to not lose data. It's stupid to throw it away once it reaches that point.
I've been using ZFS on my Linux servers for years and have pretty good experience with it. I've not been following Linux development too much. Is bcachefs usable/stable/reliable enough to replace it?
The main advantage of Zig for me and many other programmers, is the simple mental model you need to keep while reading the code. All control flow is expressed by keywords, never symbols. That along makes code much more readable. There is nothing like Rust macros, things can't do "magic. Zig comptime are regular functions, so you can clearly see and follow the trail. There are no exceptions, no recoverable panics, all code will run linearly as you see it written. Error handling in Zig is close to perfect, in my view. Obviously, Zig is not a language to use for high-level jobs. It makes no sense to write CRUD web app in Zig, you will be fighting the resource management for no good reason. For me personally, I feel that I'm too stupid to use Rust effectively. I started moving away from C++ purely because I don't want to deal with exceptions. And Rust is just a more complex C++ with memory safety.
The concept of winter pretty much stopped existing where I live. It's just colder autumn. The ground doesn't freeze. Snow doesn't accumulate. No amount of meandering is going to compensate for the fact that the mountains do not hold water. Something needs to feed the springs and rivers. And the source is gone. Europe is shifting into a different climate, where water primarily comes as rainfall, causing floods. I imagine it's similar to Asian countries, and we will have to learn to deal with that.
I had a similar observation this year. In 2015, I was in California, was doing some hiking on the weekends, and I found it very unnatural how all the grasses were dry, trails dusty, on the hills/mountains. I came back to Slovakia, and I was happy to see the green grass. Fast-forward to 2026, and our grasses are equally dry and trails are equally dusty. Water management seems to be more important than ever, because this is only going to get worse. Maybe we need to build massive reservoirs, to retain the flood water somehow, if we want to keep living here in the next 100 years.
People are not scared of individual droughts. They are scared of the patterns. Here in Slovakia, the last real winter with proper snow depths we had was in 2018, if I remember correctly. There is pretty much no snow anymore. All the water comes in form of heavy rainfall, causing massive floods, and the water goes straight to the sea. Nature depends on the water accumulating on the mountains during the winter, and that just doesn't seem to happen, at least in this part of Europe.
Programming asynchronous code is hard. Execution is split up, you have extra state machine to handle, extra resources to manage that need to survive across async boundaries. And by asynchronous, I mean either callbacks or manually checked completions from some event system. Modern languages hide that under async/await, which is much better from DX perspective, but still leads to split in the ecosystem, and it's hard to optimize across async boundaries.
This is an example why Go is such a successful language, in my view. It hides the async complexity and allows you to pretend you have a simple continuous thread of execution. It's just cheaper than system threads. Imagine if operating system threads and the blocking syscalls were this efficient.
I've spent the last year building a similar runtime for Zig. Purely because I want my applications to forget they are using things like io_uring in the background.
One problem is that a large part of Europe doesn't understand the concept of public domain. I'm not legally allowed to not own my creation, except by transferring it to someone else. That's why licences like CC0 exist.
I run this on a side of the Claude Pro subscription that I use for other purposes. My main motivation was root cause analysis of production issues. I have a solo project and unfortunately my mental state has been degrading over the last years. I would avoid looking at production issues, because I didn't have the energy to focus on the investigation. So I automated this, setup the loop, setup metrics/logs access for Claude to use and now whenever something goes bad, I have a single report that I can act on easily, and if I don't, it will ping me in a way that's not spammy like automated alerts. But I'm finding more uses for it.
This is is already possible with Claude Code. I use a setup where I have one instance monitoring a local queue, I have a web app for receiving webhooks from various sources and pushing them to the queue. Plus email for things that don't have webhooks. That instance then decides what to do with each input, sometimes it can spawn additional agent to investigate/prepare, sometimes it creates a ticket assigned to me and then waits for me input. All of that just uses the monitoring tools built into CC. The dispatcher loop doesn't need to be extremely smart, so I might experiment replacing it with a local model like this.
Of course they do. They have such a huge parameter maps. You need to be able to guide it through the map, so it starts making the right connections. Even in the Sonnet 3.7 days, it became clear to me, that if I have want efficient code out of it, I need to really take care of the context. If I just let it research a problem, it will mess up most of the time. If I tell it to study A, B, C and then present problem D, it will solve it perfectly. And it's true even with the current top models.
That was their headline for Opus 4.8, I guess the invested into some post-training to get them to write this, and I like it, it's a great way to identify AI posts from Claude.
If I had coworkers with the ability to program like Sonnet 3.7 did, I'd be extremely happy. In reality, I can probably count 1-3 people like that, out of many over the years. Honestly, pair programming with Opus is better than any pair programming I had with a human, especially at understanding the reasons behind my designs.
As much as I hate to say this, I think it is an user error. Fable is very to the point, much more so than any other Anthropic model. I found it to be cheaper to use Fable, than using Opus for same task, but in order to achieve that, it needs to be given a targeted task.
I considered Opus 4.5 to be the peak for a while. Opus 4.6 tended to over think, and generally get lost in thinking. I asked something and Claude Code would just spin for 15 minutes. And it was not the harness, if I changed the model to 4.5, it was fine again. So I skipped the following releases. I've been working with Opus 4.8 the last weeks and while I don't like how talkative it is, but it is fine to work with interactively. I've also used Fable for the few days it was available, and indeed, that was model worth using for my use case. To the point, but still very interactive.
Zig has multiple issues, but syntax is definitely not it. It might take a little bit of time getting used to, if you are coming from another language, but it's one of the most readable languages I've ever worked with.
I was never able to get these models to collaborate with me the way Opus does. I'm probably an outliner, I don't one-shot projects, I don't vibe code. I basically use LLMs are if I was working with a coworker, fairly smart one, but with short memory and often missing the big picture. Sometimes I can delegate more, sometimes less, but I know I always have to stay on top of what's happening, because it WILL create mess when it hits something hard. With the Antropic models, this kind of cooperation is easy (with the exception of Opus 4.6, which was bad for some reason).
I don't have an example, but I know the pattern. You are working on your software, security researcher finds a bug, it's in your project, for you it's just another bug, but for them it's a point on their CV, so they make a theater about it, and expect priority in dealing with it. It must get tiring if you get many of these.
I feel that Zig will stay a niche language. In this world, there is no reason for corporations to use anything but Rust for this kind of code. And without the corporate push, it will probably still exist for a long time, but the D trajectory is what I predict. I really like the language and I hope it gets more popular, but it seems unlikely to me.
With the amount of problems I had using Redis Sentinel, I really wish there was another way. On multiple occasions, with completely different deployments, it got itself into a non-repairable state where the only option was to drop it and setup the replicas manually. I was hoping someone would do a Patroni-like project for Redis, but I've not found it yet. I've moved all persistent data to PostgreSQL and use a number of Valkeys behind Envoy proxy as a cache.
Well, I'm just an extremely happy user. I've honestly tried to find an alternative, and couldn't. I'm using it in the context of solo developer and it provides a huge value to me.
It's actually common, many companies develop their products this way. The source is available, you can see the VCS, but you can't participate in the development. That's why I see this as signal that it's going to turn into a company.