lukaslalinsky

But written in Go, and I would expect the NetBSD base only includes software buildable using tools already in the base system.

If you know what you want to do (i.e. you have the architecture/pseudo-code in your head already), LLMs are a actually quite good at transforming that into real code and do save you time/effort. If you are using them like slot machines, and hope for the best after a vague prompt, then yes, it's not worth it, it just leads to frustration and wasted energy.

I was a fan of the Debian GNU/kFreeBSD project, I wanted to use FreeBSD back then, but I was unhappy with the BSD approach to software packaging. But even that was abandoned due to lack of interest. People who want to use BSDs just generally prefer the BSD way of doing things. I might be wrong, but I don't think the anti-AI ex-Linux-user crowd is large enough for this to become successful. I think a more useful work from the anti-AI community would be to start improving the driver situation in NetBSD/OpenBSD, so it can be used on modern machines, and just accept the BSD way of packaging software.

While you could say that, all the operations are documented behavior. You need to assume they will block. If the blocking happens in userspace runtime or in the kernel doesn't matter. And you, as the application author, are the one choosing which runtime to use. This just allows the libraries to be generic.

There is a difference between single-threaded and multi-threaded, but if you use `io.concurrent` or `io.async`, you are expected to have your code assume multi-threaded enviroment. And there is no visible behavior change between blocking and non-blocking backend, assuming you are not calling external libraries that do their own I/O. So code written and tested on blocking threaded I/O, will work just fine on async implementation. All I/O operations are the yield point.

There is no magic about the I/O interface. It's a regular dynamic dispatch, the same as if you use virtual functions in C++. Currently, and in the foreseeable future, there are only two options how it can run, blocking mode where each task occupies a dedicated thread, or using stackful coroutines. The interface implements blocking functions, there is no async waiting anywhere in there. But because it's dynamic dispatch, it allows the async implementation to do the "prepare operation, suspend until completed, wake up" dance, where the threaded implementation would just run the blocking syscall directly. There are plans to add stackless coroutines, but that will require many language restrictions to happen first, so it's not going to happen any time soon and when it does, the interface will likely change to accomodate it.

You are looking at this from the wrong perspective. If you are fine with automatic allocations and RAII like you have in C++ or Rust, or with a garbage collected language, there is pretty much no reason to even look at Zig.

Zig is a language to use when you do need the control, mostly because of performance reasons. And once you are in, you start thinking how to manage your allocations and arenas are the logical outcome, once you notice that your application has scopes that can be destroyed at once.

If you need an argument why arenas are better than RAII, then you likely don't have the performance needs to even consider using Zig, because outside of performance, arenas are not better.

My biggest advice is to keep programming for fun. I don't know what do you do at work, but for me work was never the satisfying activity what I started programming for. Pretty much all the problems at work were obvious and just needed the code written. But outside of work, you get to experiment, you get to learn, solve challenges. I started programming because I was fascinated by how what we learn at math class (trigonometry) can be used to display things on the computer (old 8bit one). Then I rented all the books from the local library and studied, even though I didn't have a computer at home. And this kind of kept me going. I always had a personal project which can occupy my head, and in the past, when I got home, I could try to write the ideas into code. These days, I use the agents for the last step, but that step was never the fun part for me, it was the thinking and "connecting the dots".

How long have you been using it? I've always been disappointed with similar systems, etcd including.

I think you are misunderstanding what the article suggests. std::atomic::wait and std::atomic::notify_all are the C++ abstractions over futexes. The whole concept of the future can be expressed in terms of atomics and futexes. The only problem is that the C++ standard doesn't have std::atomic::wait_for.

I'm Slovak, and when I was a kid, I was really wondering what is the thing that makes people Slovak, what is the unifying thing. And only later in life I realized, that there is not much to it. It's just people that happened to be living in this area and stayed throughout the different times. Many cultures came and left. All the slavic languages we kind of fluid for a very long time, the standardization is recent, if you look at it from global point of view. The sad part is, this is not really even taught in local schools. And I also find it fascinating, that it's such a wild blend of cultures and yet the country/nature where the people lived formed them to something unique.

You would be surprised how fast Node/Bun can be if you scale them properly. If you use Bun, you are using uWebSockets already. If what you are doing in your application is database queries and some template rendering, you might not actually gain that much from these compiled languages.

And then it reads all the AI-written "docs" from the previous changes, at which point it's all so muddy, it just tries to copy the style and output more junk and more verbose "docs". This is why I never let AIs maintain documents on their own.

In my experience, the worst crap gets into the codebase through updates. Especially when dealing with something hard, Claude will take shortcuts, that undermines the project's quality. In my projects, I deal with it by still pair programming with it. But as far as I understand, Anthropic deals with it by re-creating projects, rather than updating them.