That’s fair, I should have framed it more clearly upfront. Thanks for the feedback.
I was excited about the results. The intent was to talk about performance and architecture, not to imply this was a quick or effortless project. There’s been a lot of iteration and experimentation behind it, and I should have communicated that context better as well as the use of AI for the help.
I totally get it and received the offering. =) Love seeing more use of io_uring too and interesting to see how that's done in Zig. Happy New Year: All the best on this and other projects.
Fair point. And as what it is, not a nats replacement, certainly dont have the time to maintain that this way, a test/tech demo/fun side project that yielded super interesting results is probably the answer. As usual I'm probably way too enthusiast when I see some nice results like that and the goal here was to talk about that, but it shifted super fast. So yes Claude rewrote lots of parts, and that's what I love about it. Testing an idea happens in way less time than before, and I find that super cool.
Its an extract of two weeks of work. And yes Claude did the website and rewrote my code that was absolutely without comments and a gigantic mess. It's an extract of the fourth attempt actually. Src4/ was the original folder. But my goal my to test the architecture applied to nats not to say I've done it without ai?
Claude did rewrote lots of my original messy code. No shame in that? But in the end the interest was in the underlying architecture, applied to nats protocol. Anyway.
Which is totally fine, I use Claude Code a bunch myself. I said nothing about shame, just that one single commit plus a website that looks vibe coded together has all the hallmarks of AI-driven code.
Oh god no. Just having fun with zig and being a little over enthusiast I guess. I'm a big fan of nats, and really wanted to see how far you can push the idea if you do it differently. I was not expecting that tbh but, hpn too!
Coming from i3 this was one of my biggest pain on osx, running skhd + yabai to solve that. Still not i3's perfect experience: I did not manage to have only one action key, but starting to get closer. And you can have that full screen without the osx full screen!
Only if you don't know what you're doing. The problem with DNS is that it might work even when it is misconfigured, and misconfiguration is the source of strange issues.
I think that we all have areas where we don't know what we're doing. This is one of mine. With all the talk of how obvious/important/easy it is to have a failover in place in case this happens, I'm having trouble finding a good resource about setting up a redundant DNS.
Running a droplet on Digital Ocean with Debian and Nginx.
Sounds like we're begging for someone to write a nice blog post for how they set up redundant DNS across multiple providers "the right way"... Sounds like it would hit the front page in short order if anyone is willing to share how they think this should be mitigated, and specifically how to expect common clients to behavior in that case when faced with the various types of outages that may occur!
Yes, I see prometheus as a step towards a more sophisticated monitoring setup if you consider (and enable) this as a prometheus service. Satellite can push metrics to one of the prometheus servers for all the benefits prometheus provides. So neither is really a replacement - rather a complement. Satellite was born out of immediate need to monitor the cluster as it is being created and definitely appears naive in most other respects - it implements just the bits to do that. So, pairing it with an established solution like prometheus (or InfluxDB, for that matter) is an undeniable benefit.
I was excited about the results. The intent was to talk about performance and architecture, not to imply this was a quick or effortless project. There’s been a lot of iteration and experimentation behind it, and I should have communicated that context better as well as the use of AI for the help.
reply