it is obvious that you haven't worked with go for a long time because for some years now go.mod files show you literally every import, both the ones named in your sources in the repo, plus all the ones that are named in the ones you imported (go mod tool puts `// indirect` after them)
and i concur with your opinion about the thoughtless use of packages without considering this, i'm obsessive about how long the list of imports in my go.mod gets, and when i see repeating ones i get stressed
this is why i put my "nostrbench" package in a completely separate repo from my code because i don't want it polluted with fiatjaf's infinity imports, and all the crazy versions
this is also why i have reworked the entire btcec library to eliminate, for one thing, the decred dependency, and i've mostly also removed its dependency on blake hash library except for a few tests that i have to regenerate vectors for
the go standard library itself has a lot of things but some things are glaringly missing, and especially when it comes to go's crazy immutable strings, the amount of memory garbage these throw off is mindboggling - the more complex your application, and the longer it runs for, the more likely you are to run into GC hell with high CPU usage and reduced latency after a certain amount of time, and even worse if you are spawning coroutines for each network connection and those damn connections never drop (this is a problem with the design of nostr websocket subscriptions, and there is no specification about what constitutes an expected time to drop a subscription beyond exceeding the configured limit field in filters)
i am not overtly conscious of the fact that huge long go.mod files could be a security problem but now you point it out, yes, this is another reason, but my primary reason to not want that is to not fill my disk with useless, often unnecessarily redundant crap, it clogs the disk, for a start, and then in the actual binary, it means several pieces of code do the same thing in different parts, this annoys the piss out of me also, and it's more memory that is going to waste, and then on top, very often the entire architecture of the different components is not in line with my architecture and all my efforts to maintain sane memory usage are defeated by some stupid import of an import of an import
mleku / mleku™️
npub1fjq…leku
2024-07-01 10:41:30
in reply to nevent1q…zdhn
Author Public Key
npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmlekuPublished at
2024-07-01 10:41:30Event JSON
{
"id": "6ef0558367c5ac5929086459179e28ec5049c4d6c2e5d3a710dd978e5e8e4378",
"pubkey": "4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f",
"created_at": 1719823290,
"kind": 1,
"tags": [
[
"e",
"61d4c0ac64c75d01285981b260b9282dd8dcad28fd8d310bdf65f828e14a9766",
"wss://theforest.nostr1.com/",
"root"
],
[
"e",
"c1c72cbd57e530c623ffa9ecb7eca1289f0f079aa6237924f3ae7d760b04f761",
"",
"reply"
],
[
"p",
"5dcd8ebc9ab7f212c907b5100769b36b9aeafdf8e89f239d97cadd79f5a17bdc",
"",
"mention"
],
[
"p",
"dd664d5e4016433a8cd69f005ae1480804351789b59de5af06276de65633d319",
"",
"mention"
],
[
"p",
"df67f9a7e41125745cbe7acfbdcd03691780c643df7bad70f5d2108f2d4fc200",
"",
"mention"
]
],
"content": "it is obvious that you haven't worked with go for a long time because for some years now go.mod files show you literally every import, both the ones named in your sources in the repo, plus all the ones that are named in the ones you imported (go mod tool puts `// indirect` after them)\n\nand i concur with your opinion about the thoughtless use of packages without considering this, i'm obsessive about how long the list of imports in my go.mod gets, and when i see repeating ones i get stressed\n\nthis is why i put my \"nostrbench\" package in a completely separate repo from my code because i don't want it polluted with fiatjaf's infinity imports, and all the crazy versions\n\nthis is also why i have reworked the entire btcec library to eliminate, for one thing, the decred dependency, and i've mostly also removed its dependency on blake hash library except for a few tests that i have to regenerate vectors for\n\nthe go standard library itself has a lot of things but some things are glaringly missing, and especially when it comes to go's crazy immutable strings, the amount of memory garbage these throw off is mindboggling - the more complex your application, and the longer it runs for, the more likely you are to run into GC hell with high CPU usage and reduced latency after a certain amount of time, and even worse if you are spawning coroutines for each network connection and those damn connections never drop (this is a problem with the design of nostr websocket subscriptions, and there is no specification about what constitutes an expected time to drop a subscription beyond exceeding the configured limit field in filters)\n\ni am not overtly conscious of the fact that huge long go.mod files could be a security problem but now you point it out, yes, this is another reason, but my primary reason to not want that is to not fill my disk with useless, often unnecessarily redundant crap, it clogs the disk, for a start, and then in the actual binary, it means several pieces of code do the same thing in different parts, this annoys the piss out of me also, and it's more memory that is going to waste, and then on top, very often the entire architecture of the different components is not in line with my architecture and all my efforts to maintain sane memory usage are defeated by some stupid import of an import of an import",
"sig": "417a1257d5382d324825c982113d42bc2d4dba4f0f7399e375c9cdb78359edbf25492b2c30036f1064da01b26821556c9cee7edfdb4747e38083fe627e1f71ec"
}