I've found that LLMs are particularly bad at writing Zig because the language evolves quickly, so LLMs that are trained on Zig code from two years ago will write code that no longer compiles on modern Zig.

these seem to occur only in college assignment projects, and in the output of text generators trained on those.

(i actually do this in slack messages and folks find it funny and annoying, but more funny)

I put such emojis at the beginning of big headings, because my eyes detect compact shapes and colors faster than entire words and sentences. This helps me (and hopefully others) locate the right section easier.

In Slack, I put large emojis at the beginning of messages that need to stand out. These are few, and emojis work well in this capacity.

(Disclaimer: I may contain a large language model of some kind, but very definitely I cannot be reduced to it in any area of my activity.)

But the telltale signs are far more than just that. The whole document is exactly the kind of README produced by Claude.

In my experience, when you work with something like agentic development tools, you describe your goals and give it some constraints like “use modern zig”, “always run tests”… and when you ask it to write a README, it will usually reproduce those constraints more or less verbatim.

The same thing happens with the features section, it reads like instructions for an LLM.

I might be wrong but I spend way too much time using Claude, Gemini, Codex… and IMHO it’s pretty obvious.

But hey, I don’t think it’s a problem! I write a lot of code using LLMs, mostly for learning (and… ejem, some of it might end up in production) and I’ve always found them great tools for learning (supposing you use the appropriate context engineering and make sure the agent has access to updated docs and all of that). For example, I wanted to learn Rust so I half-vibed a GPUI-based chat client for LLMs that works just fine and surprisingly enough, I actually learned and even had some fun.

As I wrote in another comment, it is not inherently a bad thing. I use LLMs too (while knowing what I am doing), and if the project works, why not?

There seems to be a fair amount of stigma around using llms. And many people that use them are uncomfortable talking about it.

It's a weird world. Depending on who is at the wheel, whether an llm is used _can_ make no difference.

But the problem is, you can have no idea what you're doing and make something that feels like it was carefully hand-crafted by someone - a really great project - but there are hidden things or outright lies about functionality, often to the surprise of the author. Like, they weren't trying to mislead, just didn't take them time to see if it did all of what the LLM said it did.

I think it is not inherently a bad thing to use LLMs, only if you have absolutely no clue about what you are doing, but even then, if the project is usable and as-is advertised, why not? shrugs

As for the link, that is exactly the same code that caught my eye, besides the README.md itself. The LRU eviction thing is what GPT (and possibly other LLMs) always comes up with according to my experiences, and he could have just had it properly implemented then. :D

Edit: I am glad author confirmed the use of an LLM. :P

only if you want to refactor/rewrite a lot

also operators and integer types are unambiguous, and there is no UB in safe compilation modes.

It's arguably much better than C, not "slightly better than C"

AKA You are responsible for opting into "modern C". In order to be unsafe in zig (in the dimensions I mentioned) you must opt out.

Compile time slice bounds checking is generally not a thing, since the length is not known until runtime. Its still safe.

> but only in Debug/ReleaseSafe builds

So, the default build modes?

Istg zig should just eliminate releasefast and releasesmall and force you to opt in on a function by function basis.

It has little step-by-step tasks with automated tests. There are some other good ones like git and docker. It's pretty cool.

https://app.codecrafters.io/courses/redis/overview

Something like LevelDB is relatively easy to write. Then you can build the rest of Redis on top of it.

I mean, I have my own C libraries for most of these!

> Memory safety with RAII patterns

I'm curious to see how they achieve RAII in Zig, which doesn't have destructors. If they mean defer + deinit methods, that's not the same thing.

No? It's the first thing that came to my mind when I've read RAII.

idk if redis labs (the organization aka big bad) are going to patent the “protocol” to disallow clones (or they’d be going after valkey first)

Naming is famously difficult in this world!

So, there's another project – called kvrocks https://github.com/apache/kvrocks , which is for people which don't need in-memory perf of redis but would like to use its protocol and be still very performant. However, its devs never packaged a release in deb and other formats.

So, if you were to implement something similar ^ which will implement the protocol, have ability to grow on disk, and be available in distro repos (ideally) – would definitely hold a niche of many little projects which benefit from redis-like thing I've done.

another major drawbacks of Redis is that It is single threaded and sync. you need expensive high frequency CPU if you need more performance. something that could benefit from multi core system and if you would want to use disk cache async is a must. single threading also affects scripts running on Redis side, when they execute whole Redis is waiting and is unable to fulfil other requests.

another place for improvement would be proper easier to use HA, and maybe also auto scaling.

Redis-compatible protocol guarantees that you can think about the things you've mentioned later. If project is successful – you'll find money to pay for RAM and move to pure Redis. If it's CPU-bound – you'll find multi-threaded alternatives.

So this is a pretty nice niche IMO actually.

It regularly gets itself into messed up state and even with graceful shutdown for node updates the official client libraries throw errors for up to a minute.

You can use the ancient BerkeleyDB which is supported everywhere for last like 30 years. Or a more recent LevelDB. Or even SQLite which is plenty fast on simple queries.

You'll have to tolerate the high latency of safely writing tings to a block device, compared to RAM. If your load is mostly reads, it should be OK.

Ironic to see this, as even a cursory glance over the code shows a lot of memory bugs, such as dangling pointers, data races, some potential bugs like double free, etc.

It is good that the OP is learning things, but I would caution against relying on LLMs and taking on a bigger project like this, before the basics are well understood.

Personally, this is one of the reasons I dislike the LLM hype, people are enabled to produce much more code, code that they aren't qualified to support or even understand.

While the project linked is clearly designated as strictly for "learning purposes", the applications we will get in the large will be of no better quality.

The difference being, before LLMs, those, who didn't have qualification, wouldn't even approach problems like this, now they can vibecode something that works on a lucky run, but is otherwise completely inadequate.