They are trying to use condition variable without a mutex and see missed wake ups. That's a textbook error, no? I'm surprised asyncio.Condition even allows that mode of operation.
If they do, it could be because safety is a gradient and one variable among many in software development, albeit a very important one when it comes to browsers.
My entire professional life, I've been dealing with coworkers who just want their code shipped. Overly complex solutions to simple problems, inefficient algorithms, nested spaghetti code. And it was hard to just plainly reject it. I eventually had to become a mentor, teach them how to do it better. I've called myself a programmer even though I mostly just helped other people to program.
Over the years, I've lost the ability to focus on writing code myself, but I've seen a rebirth with the age of coding agents. I find it easier to review their code and they always follow my guidance. In fact, I sometimes feel like around year 2000 when I had "google" skills and the people around me did not.
It's much easier to produce garbage with AI and it will inevitably happen, but engineers who are able to think will simply use it as a new tool.
I've always been more interested in the computer science and software engineering aspects. I did enjoy writing code occasionally, but overall, I was wishing I had some kind of neural implant to convert my thoughts into code. Coding agents are now good enough that I consider that dream as realized, and with that benefit that I do not actually need any implant in my brain. :)
Interesting, I've found AI to be further from the goal of converting my thoughts to code than writing code myself.
English is so ambiguous that by the time I provide sufficient context to the prompt it's taken more typing than writing the code would have been. That's not even accounting for the output often needing further prompting to manipulate into what was intended, especially if I try to be light on initial context.
I like it for quick proof of concept stuff though, the details don't matter so much then.
I really approach is the same way as helping my coworkers to be productive. Most of the context is spent on the initial familiarizing with the code and I just double-check that it has the right understanding, there is minimal prompting on my side for this. The next step is to explain the problem I'm trying to solve and and for the simpler ones, it gets what needs to happen 8/10 times. I don't need to be detailed, because it already knows the context. For the complex problems, I split them into small tasks myself and only ask it to do the small steps, small enough to fit into the first category. I feel like the worst outcomes happen when you specify the problem first and let it do it's own research with that in "mind", then it just overthinks and comes up garbage.
Give it the problem first. Then have it generate the context. Make edits and iterate on the context. Then hit go. Finally, have it write down whatever it needs to for next time.
There was a recent post where someone said AI allows them to start and finish projects. And I find that exactly true. AI agents are helpful for starting proof of concepts. And for doing finishing fixes to an established codebase. For a lot of the work in the middle, I can be still useful, but the developer is more important there.
I was experimenting with other tools a while back and the visibility/interactivity was one of the main benefits of Claude Code. Now that it's gone, maybe I can move on and just learn to work with the new tool/model.
Same here, both Claude Code due to this change, and how Opus 4.6 is setup, they think they can do things autonomously. But in my experience, they really can't. Letting it overthink something while being on the wrong track is what leads to AI slop.
I really love Zig the language, but I'm distancing myself from the stdlib. I dislike the breakage, but I also started questioning the quality of the code recently. I was working on an alternative I/O framework for Zig over the last months, and I was finding many problems that eventually led to me trying to not depend on stdlib at all. Even on the code announced here, the context switching assembly is wrong, it doesn't mark all necessary registers as clobbered. I mentioned this several times to the guys. The fact that it's still unchanged just shows me lack of testing.
It sounds like Zig would benefit from someone like you on the inside, as a member or active contributor, reviewing and participating in the development of the standard library.
Zig is one of my favorite new languages, I really like the cross-compiler too. I'm not a regular user yet but I'm hopeful for its long-term success as a language and ecosystem. It's still early days, beta/dev level instability is expected, and even fundamental changes in design. I think community input and feedback can be particularly valuable at this stage.
I've realized that Zig is a language, in which people can write programs in vastly different styles. And these are not really compatible. This is not unlike C++, for example. I learned Zig in my own bubble, just using my previous programming knowledge, not relaying on existing Zig code much. If I saw Zig's own code at the early stages, I'd probably not pick the language, purely on the style of huge inlined switches and nested conditions all over the place.
I’m confused. The register clobbering is an issue in the compiler, not in the stdlib implementation right? Or are you saying the stdlib has inline assembly in these IO implementations somewhere? I couldn’t find it and I can’t think why you’d need it.
If it’s a compiler frontend-> LLVM interaction bug, I think you are commenting in the spot - it should go in a separate issue not in the PR about io_uring backend. Also, interaction bugs where a compiler frontend triggers a bug in LLVM aren’t uncommon since Rust was the first major frontend other than clang to exercise code paths. Indeed the (your?) fix in LLVM for this issue mentions Rust is impacted too.
I agree with the higher level points about stability and I don’t like Zig not being a safe language in this day and age, but I think your criticism about quality is a bit harsh if your source of this complaint is that they haven’t put a workaround for an LLVM bug.
There is the one issue which I fixed in LLVM, but it should be fixed in Zig as well, because the clobber list in Zig is typed and gives you false impression that adding x30 there is valid. But there is also another issue, x18 is a general purpose register outside of Darwin and Windows and needs to be marked as clobbered on other systems. And yes, look at the linked changes, the stdlib has inline assembly for the context switching.
I don't want to be the negative guy, but this is news about two unfinished implementations. There is a lot of work needed for this to be considered done. For example, no networking in the GCD version yet. And as these are being implemented, the interface stops being an interface, the vtable keeps growing, and it's just the current snapshot of what's needed by the std implementations.
> They are now available to tinker with, by constructing one’s application using std.Io.Evented. They should be considered experimental because there is important followup work to be done before they can be used reliably and robustly:
And then they proceed to list 6 important pending work to be done.
I think another way of thinking about this interface is: it’s kind of like an abstraction over Linux system calls and ntdll. It’s naturally gonna have a kind of subset of all the useful calls, with some wrapping.
I don’t see anything wrong with this, it’s kind of how Windows forces developers to use DLL to access syscalls (the syscall numbers can change) which IMO is a good architectural decision.
Except it's not. I've implemented it, over its multiple iterations, so I'm familiar with it. It's an interface to satisfy the needs of the Zig compiler. It's heavily lacking for use in server applications.
I know more about Zig than C++ at this point, but it's hard to read the article seriously, if it starts with such mistakes. Zig does in fact have an HTTP client in the standard library, there is a tar reader, and realpath hasn't been removed, it still exists even in the std.Io namespace.
reply