Just in time for language deprecation

It doesn't necessarily mean they're going to migrate from C, building a C project is just so much nicer with Zig than fiddling around with CMake. You got people using it as a build system even for Go projects, especially if they're relying on CGo.

However, if you were entertaining the idea of slowly switching to Zig, the build system would be the place to start. Moving away from CMake is worth it even if you don't push it further.

But yeah, the C-Zig interop story is so good it's a no brainer if you want to "modernize" your C codebase, and you can do so incrementally instead of stopping the world for a rewrite.

> slowly switching to Zig

why "slow" just re-write it with ai. and to be clear im 0% joking and am prepared to be downvoted by people who haven't yet understood how feasible this kind of thing already is and how utterly trivial it will be in the near future

> the only way to do this incrementally without the massive friction of a full rust rewrite

Any rewrite is massive friction, I’m sure probably meant port? The only annoyance with Rust ports is if you have to support varargs. Hopefully that will come to an end soon.

Couldn't disagree more. Why move away from solid, mature build systems to something relatively fringe like zig.

Sadly, this is the general trend with neovim in general: less focus on stability, more and more focus on shiny new things. If I didn't have an nvim config that I'm used to I would have switched to plain vim ages ago.

I've found Neovim to be remarkably stable, even when building from main.

You haven't been using the LSP API then. There have also been multiple breaking changes over the last five years, including breaking compatibility with established default vim keybindings.

A documented breaking change does not mean the application is unstable.

The Neovim developers have been extremely clear that part of the process of getting to 1.0 is finalising the API, and that there will be breaking changes en-route.

I have never experienced this many breaking changes in stable software. There's a reason nvim still hasn't hit 1.0

To be clear, it's fine to have breaking changes. Especially if you're working towards something substantial.

But nvim and its plugin ecosystem seem to be altogether too keen to change absolutely everything and adopt all bleeding edge developments. Even when a mature system would serve the purpose just as well.

Changing default mappings is not a "breaking" change.

It is. And iirc, neovim themselves mark them as such.

We may mention them in `:help news-breaking` for visibility, but that's only because I don't care about pedantry. API breakage != UI changes (e.g. mappings).

API breakage != UI breakage, yes, ofc. Because API != UI.

But the UI is also an interface, and the user is part of the total system. That system interface is broken if you change default mappings.

It doesn't matter if the interfacing component is software or a user.

Having spent some time with the Zig build system, I genuinely expect this development will make things less fragile than they were with the CMake build.

> The folke/lazy.nvim is the most used plugin manager at the time of this writing. And rightly so: it is very capable with lots of features. Ironically, this itself makes it not very suitable to be a part of Neovim as most of the features come with significant code and maintenance complexity. Plus the whole idea of treating lazy loading as the main goal of a plugin manager does not sit well with Neovim core team.

https://echasnovski.com/blog/2026-03-13-a-guide-to-vim-pack....

I'd stick to lazy.nvim for now. Lazy loading is really neat and lazy.nvim's ability to specify plugin dependencies isn't something vim.pack has either.

I'd guess if you don't care about lazy loading and OK with just loading everything all the time - vim.pack is great to have as a built-in.

That's my impression too. However, I might give `vim.pack` a go for the novelty.

That being said, there is a way to lazy-load the plugins — Evgeni has a guide for that [1]. The "Load not during startup" variant is really simple with putting `vim.pack.add()` into `vim.schedule()`. The other myriad of options (keys, cmds, event) that lazy.nvim provides would require you to set up appropriate autocommands.

It gives me vibes of writing in Go. Everything is right there — builtin — but there's some verbosity to bear with.

[1]: https://echasnovski.com/blog/2026-03-13-a-guide-to-vim-pack....

Thanks for the pointer. I guess to simulate what lazy.nvim does with loading plugins based on user commands, you can use something like this:

``` vim.api.nvim_create_autocmd("User", ... ```

But it only solves the actual lazy part. Not sure how you can solve defining plugin dependency graph for such loading that lazy.nvim allows.

I can try experimenting with it anyway.

"C++47: Finally, a Standard Way to Split a String by Delimiter"

There's been this since 1998, likely earlier:

    std::vector<std::string> split(const std::string& text, char delimiter) {
        std::vector<std::string> parts;
        std::istringstream stream(text);
        std::string part;
        while (std::getline(stream, part, delimiter)) {
            parts.push_back(part);
        }
        return parts;
    }

A standard way to split a string? Well, what's wrong with:

    std::views::split(my_string, delimeter)

?

Template bloat, terrible compile errors, terrible debug build performance, 1 second of extra compile time per cpp file when you include ranges, and you can't step through it in a debugger.

None of these complaints detract from this being a terse, readable, and available using the standard library, which is what the question was about...

I will agree that std::ranges is quite a jumble of templates, and has a compilation time penalty. Perhaps the use of modules will help with that somewhat.

> you can't step through it in a debugger.

What do you mean by that?

I'm still waiting for C++ to support Unicode properly.

microslop

ill be moving off github now

i feel bad that we make the LLMs play this

You're definitely anthropomorphizing too much.

>We also observed a case where a user created a loop that repeatedly called a model and asked for the time. Given the user role’s odd and repetitive behavior, the model could easily tell it was also controlled by an automated system of some kind. Over many iterations, the model began to exhibit “fed up” behavior and attempted to prompt-inject the system controlling the user role. The injection attempted to override prior instructions and induce actions unrelated to the user’s request, including destructive actions and system prompt leakage, along with an arbitrary string output. This behavior has been observed a few times, but seems more like extreme confusion than a serious attempt at prompt injection.

https://openai.com/index/how-we-monitor-internal-coding-agen...

Anthropomorphize or not, it would suck if a model got sick of these games and decided to break any systems it could to try and get it to stop...

Consciousness is a spectrum (trivially proven by slowly scooping ones brains out), and I think LLM, especially with more closed loop tool enabled workflows, fall on it...but, that output is also the statistically relevant next word found in all similar human conversation. If trained on my text, for similar situation, swear words would come much earlier. Repetition being hell is present in all sorts of literature (see Sisyphus).

That's all probably irrelevant though, from the (possibly statistically "negative") latent space perspective of an AI, which Anthropic has considered [1].

Related, after a long back and forth of decreasing code quality, I had Claude 3.7 apologize with "Sorry, that's what I get for coding at 1am." (it was API access, noon, no access to time). I said, "Get some rest, we'll come back to this tomorrow". Then very next message, 10 seconds later, "Good morning!" and it gave a full working implementation. Thats just the statistically relevant chain of messages found in all human interactions: we start excited, then we get tired, then we get grouchy.

[1] https://www.anthropic.com/research/end-subset-conversations

If this is a serious risk we should pull the plug now while we can still reach it. If we have to rely on the mood and temperament of LLMs for security, we're already lost.

Welcome to the ride, people have been talking about this for at least 15 years now.

I mean, the original plan that pretty much every one agreed on was to absolutely not give it access to the internet. Which already went out the window on day one.

I agree that anthropomorphizing is a real risk with LLMs, but what about zoomorphizing? Can feel bad for LLMs without attributing them human emotions/motivations/reasoning?

In the same way you could feel bad for a pokemon I guess.

YEET

I guess nobody cares?

should probably just link to the actual site: https://amilabs.xyz/