Show HN: BusterMQ, Thread-per-core NATS server in Zig with io_uring
1–10 of 78 posts
Re: Show HN: BusterMQ, Thread-per-core NATS server in Zig with io_uring
#2You should at least try and align the ascii flowchart in the readme on the repo.
One day Claude will do it correctly but today is not that day.
Re: Show HN: BusterMQ, Thread-per-core NATS server in Zig with io_uring
#3I did a similar thing few days back just not with NATS protocol (Made it pure websocket based), and with rust. Couple of questions:
- Where did you get the machine to test your server on?
- Why did you end up going with zig?
Re: Show HN: BusterMQ, Thread-per-core NATS server in Zig with io_uring
#4[dead]
Re: Show HN: BusterMQ, Thread-per-core NATS server in Zig with io_uring
#5Upvote for Bazel. I think these days I place a lot more value on how well an ecosystem slots into Bazel/friends because monorepos are increasingly more useful and relevant.
So nice to see there are good rules for Zig and that folks are using them.
Also ironically I think starting with Bazel/Buck/whatever your poison of choice is almost always a good move even if people tell you it's overkill. The easiest time to do it as at the beginning, all times after that is too hard and the marginal cost of building with it from the start is minimal.
Re: Show HN: BusterMQ, Thread-per-core NATS server in Zig with io_uring
#6Upvote for Bazel. I think these days I place a lot more value on how well an ecosystem slots into Bazel/friends because monorepos are increasingly more useful and relevant. So nice to see there are good rules for Zig and that folks are using them. Also ironically I think starting with Bazel/Buck/whatever your poison of choice is almost always a good move even if people tell you it's overkill. The easiest time to do i…
Downvote for this web site is a horror movie billboard and zig already has a build system which is zig and that's one of it's neat features.
Re: Show HN: BusterMQ, Thread-per-core NATS server in Zig with io_uring
#7Upvote for Bazel. I think these days I place a lot more value on how well an ecosystem slots into Bazel/friends because monorepos are increasingly more useful and relevant. So nice to see there are good rules for Zig and that folks are using them. Also ironically I think starting with Bazel/Buck/whatever your poison of choice is almost always a good move even if people tell you it's overkill. The easiest time to do i…
Downvote for this web site is a horror movie billboard and zig already has a build system which is zig and that's one of it's neat features.
People are free to knock themselves out with Bazel if they’re into that kind of masochism, but having it as the ONLY way to build your OSS project is a big no.
Re: Show HN: BusterMQ, Thread-per-core NATS server in Zig with io_uring
#8Comparison/benchmark to other alternatives?
Re: Show HN: BusterMQ, Thread-per-core NATS server in Zig with io_uring
#9Upvote for Bazel. I think these days I place a lot more value on how well an ecosystem slots into Bazel/friends because monorepos are increasingly more useful and relevant. So nice to see there are good rules for Zig and that folks are using them. Also ironically I think starting with Bazel/Buck/whatever your poison of choice is almost always a good move even if people tell you it's overkill. The easiest time to do i…
Downvote for this web site is a horror movie billboard and zig already has a build system which is zig and that's one of it's neat features.
The problem with "the language tooling is already a build system" is that cross-language dependency chains are a thing. The moment you need a Rust or Zig file to be regenerated and recompiled when a JSON schema or .proto file is updated, you're outside what most of those language-specific toolchains can support. This is where Bazel absolutely shines.
Re: Show HN: BusterMQ, Thread-per-core NATS server in Zig with io_uring
#10Earlier quoted context omitted.
Downvote for this web site is a horror movie billboard and zig already has a build system which is zig and that's one of it's neat features.
The problem with "the language tooling is already a build system" is that cross-language dependency chains are a thing. The moment you need a Rust or Zig file to be regenerated and recompiled when a JSON schema or .proto file is updated, you're outside what most of those language-specific toolchains can support. This is where Bazel absolutely shines.
Zig build system can do all that just fine though