the new rust-nostr sdk api is awesome, kudos @Yuki Kishimoto
Thread
Login to reply
Replies (15)
Nice to hear the SDK is in a good place โ good DX makes a real difference.
Hi @Yuki Kishimoto . I'm wondering if it's fine to use `.clone()` for the `client` instance whenever I need to use it?
I noticed that when I enabled <gossip>, there's a huge delay in receiving events after subscribing. However, it works fine if I keep <gossip> disabled. I thought `.clone()` might be affecting this, but I'm not sure, so I ended up implementing my own gossip mechanism for my app.
No, clone doesn't affect that, it's fine to use it. Have you tried the SQLite gossip storage, instead of the in-memory one?
@reya in addition to the SQLite gossip store, also this PR should help:
If you have the opportunity to test it, let me know if it's faster.
GitHub
sdk: improve gossip concurrency with per-key semaphore system by yukibtc ยท Pull Request #1250 ยท rust-nostr/nostr
Replace the global single-permit semaphore with a per-key semaphore, improving updates concurrency.
Add unit tests to ensure the system is deadlock...
I cannot use sqlite yet, because it's depend on tokio
can you be more concrete, please? name one good thing about it
pretty hard starting from that 4 letter word in the name
"reya"? "yuki"?
ah, you haven't learned yet about my hate for mozilla's sponsored hipsterlang. RUST.
also i said "title" nostr-rust
ok, "name" of the library.
it's a good language
it's hard to read, overly complex, and abuses the use of MMU immutability flags for no reason. and there is no coroutines or atomic fifos (channels) and it takes as long to compile as C++
nostr-rs-relay takes almost exactly as long to build as strfry, and my relay, from scratch, with a totally cleared out module cache, takes about 35 seconds. those other two relays take 11 minutes on a 64gb system with SSD and 6 core 12 thread ryzen 7.
if you had got used to the 3-5 second typical rebuild time after editing code that i have been doing for the last 9 years, you would laugh in Golang.
there are coroutines and atomic channels in tokio, compilation times are faster now, and it can be hard to read, but not necessarily
compilation times are only faster if you eliminate the download and compilation of the dependencies. sure, you only have to deal with it one time, but i'm just gonna say, that the cargo build system is almost a carbon copy of the system that Go uses, except it clutters up your repos with `target` directories that are typically in the gigabytes, not dissimilar to node_modules
and all this, for a 5% performance advantage over a language that does the same thing for nostr-rs-relay versus khatru, orly or rely, which actually both, according to benchmarks i made about 5 months ago, before i started vibe coding, both strfry and nostr-rs-relay are down the bottom of the rankings.
so, uh, yeah. if you can optimize the code well, sure, but 5% boost in performance and peak memory utilization
it's not worth it. and this is also why i abandoned working for shitcoin companies because from 2022, they all abandoned my fast, sleek language in favor of this hipster tire fire.
and all this, for a 5% performance advantage over a language that does the same thing for nostr-rs-relay versus khatru, orly or rely, which actually both, according to benchmarks i made about 5 months ago, before i started vibe coding, both strfry and nostr-rs-relay are down the bottom of the rankings.
so, uh, yeah. if you can optimize the code well, sure, but 5% boost in performance and peak memory utilization
it's not worth it. and this is also why i abandoned working for shitcoin companies because from 2022, they all abandoned my fast, sleek language in favor of this hipster tire fire.