Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
derekcollison
searching Neon…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
7 ms
·
1.
▲
by
derekcollison
11mo ago
We are waiting on the IO abstraction for a supported Zig client (There are others though today), but this is specifically for a new initiative at Synadia that we will share more details about soon!
2.
▲
by
derekcollison
11mo ago
TigerBeetle's excellent companion blog - https://tigerbeetle.com/blog/2025-10-25-synadia-and-tigerbee...
3.
▲
Synadia and TigerBeetle Commit $512k USD to the Zig Software Foundation
(synadia.com)
405 points
by
derekcollison
11mo ago
|
8 comments
4.
▲
by
derekcollison
1y ago
Here is our official response. We also plan to have a public AMA early next week for anyone interested. https://www.synadia.com/blog/synadia-response-to-cncf
5.
▲
by
derekcollison
4y ago
Would your company be willing to fund the development? Or would you be willing to post a PR? We would be happy to take a look.
6.
▲
by
derekcollison
4y ago
We are waiting on demand for it. We have a bunch of folks using MQTT on NATS and NGS but no requests yet for MQTTv5 so far. Once we see legit demand we will make sure it's supported.
7.
▲
by
derekcollison
5y ago
We have some great work coming that allows lighter weight consumers to scale to that level and beyond. Happy to chat with folks on how we can make that work today.
8.
▲
by
derekcollison
7y ago
We are always interested in feedback on how we can do better. Feel free to jump on our slack channel to join the community. We are actively working on the C client. Interested in more details on Python and Java issues as well.
9.
▲
So You Want to Build a Super-Fast Messaging System
(medium.com)
4 points
by
derekcollison
8y ago
|
0 comments
10.
▲
by
derekcollison
11y ago
I think entropy, in however you measure it, does influence something like a UUID generator differently than the cryptographic algorithms. What you are trying to achieve, or more importantly the condition you are trying to avoid, is differen
11.
▲
by
derekcollison
11y ago
I agree, was simply sharing because it was a need we had, which might be a need someone else had as well. Anyone can feel free to use it or not.
12.
▲
by
derekcollison
11y ago
I disagree, either the entropy is drained and the randomness of what the pool returns (based on OS) is compromised or you get stalled waiting for more of it and decrease performance of the generator. https://www.google.com/w
13.
▲
by
derekcollison
11y ago
Yes, but most UUID when moved across networks are translated to hex, so 32 bytes/characters whereas NUID's are 22 bytes, so generally a savings of 10 bytes per when stored as a string.
14.
▲
by
derekcollison
11y ago
UUID V4 is ~900ns/op, NUID is ~60ns/op, so 15X speedup, or 1500%.
15.
▲
by
derekcollison
12y ago
I am deeply saddened by this news. I remember trying to convince Ezra to join us to help out with CloudFoundry. I, like others, knew Ezra through the Ruby community where he was a larger than life presence. My thoughts are with his son, his
16.
▲
by
derekcollison
14y ago
The test is specific to a new NATS server written in GO (gnatsd). I described in more detail above the tests and what they do, but suffice it to say that it does test the message processing overhead of the server.
17.
▲
by
derekcollison
14y ago
It is not, but its on my TODO list, and I have also observed similar behavior at times. I have taken care to make sure the synchronization is efficient, but running the test is needed to get the real results.
18.
▲
by
derekcollison
14y ago
It is not one big write, but optimizations around msgs/write using buffering are used in clients, with obvious care to balance latency and throughput. In the benchmark, the write buffer is 16k, so it is flushed automatically via Go's bufio
19.
▲
by
derekcollison
14y ago
That is correct, I am only attempting to measure the efficiency of the messaging processing engine within the server. I did want to include the network stack and the buffering portion, as well as the framing, protocol parser, and the subjec
20.
▲
by
derekcollison
14y ago
The simple benchmark is testing throughput of a messaging system, specifically a new server written in Go. Both the client and server are on the same machine, but going over a tcp/ip socket. The Pub benchmarks send messages and then make su
21.
▲
by
derekcollison
15y ago
We plan on doing that, appreciate the feedback.