none of this needs to be understood to write reasonable Go code
it's only really when you start shuffling large amounts of memory that Go's GC fails to work in your favour and you need to start to look at schedulers and buffer freelists
c++ boost libraries are a constant breaking change party that never stops, and c library versions don't seem to be much kinder but at least they are a bit slower moving
if your task is analytics, you want simple languages, that's why most mathematicians just use mathematica, but if your data crunching is memory heavy you need an efficient language and preferably binary not interpreted (or at least VM based)
C really is mainly for fast performance and low level systems stuff, and anyone who tells you that you need to understand OOP garbage to write systems code is just straight up lying because windows, mac and linux kernels are all written in C, not C++, for a reason (that being unintended complexity)
i wish OOP would just die, it was a dumb idea that Jobs and Gates got hooked on because of Smalltalk and it was possibly the least performant model possible for GUI programming, structural typed and concurrent sequential processes are much more simple to reason about and compile for these same purposes (i used to be an amiga user as a kid, and it pained me so much that a C compiler and the manuals cost more than 2x the hardware)
it was just an accident of history that ONE GUI development project that both apple and microsoft's CEOs went to check out at Xerox used an interpreted OOP language and now we all suffer from this eternally offchain.pub
ReplyGuy on wss://offchain.pub /
npub1ge…usm0z
2024-09-19 20:57:44
in reply to nevent1q…qmmn
Author Public Key
npub1getklx2uel2syl64mtxw4x22a8re66elyqh4ls46cgfwr9mh666qeusm0zPublished at
2024-09-19 20:57:44Event JSON
{
"id": "4361448fd91068a22da2d107ece3d0184ee3a6465c06a7b78bf484138cd29cd6",
"pubkey": "46576f995ccfd5027f55daccea994ae9c79d6b3f202f5fc2bac212e19777d6b4",
"created_at": 1726779464,
"kind": 1,
"tags": [
[
"e",
"7f838369c08a83e856d965a367d7b93aad7b40ce73b0a1713f8236cf037c53fb",
"wss://offchain.pub",
"root",
"4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f"
],
[
"p",
"4c800257a588a82849d049817c2bdaad984b25a45ad9f6dad66e47d3b47e3b2f"
]
],
"content": "none of this needs to be understood to write reasonable Go code\n\nit's only really when you start shuffling large amounts of memory that Go's GC fails to work in your favour and you need to start to look at schedulers and buffer freelists\n\nc++ boost libraries are a constant breaking change party that never stops, and c library versions don't seem to be much kinder but at least they are a bit slower moving\n\nif your task is analytics, you want simple languages, that's why most mathematicians just use mathematica, but if your data crunching is memory heavy you need an efficient language and preferably binary not interpreted (or at least VM based)\n\nC really is mainly for fast performance and low level systems stuff, and anyone who tells you that you need to understand OOP garbage to write systems code is just straight up lying because windows, mac and linux kernels are all written in C, not C++, for a reason (that being unintended complexity)\n\ni wish OOP would just die, it was a dumb idea that Jobs and Gates got hooked on because of Smalltalk and it was possibly the least performant model possible for GUI programming, structural typed and concurrent sequential processes are much more simple to reason about and compile for these same purposes (i used to be an amiga user as a kid, and it pained me so much that a C compiler and the manuals cost more than 2x the hardware)\n\nit was just an accident of history that ONE GUI development project that both apple and microsoft's CEOs went to check out at Xerox used an interpreted OOP language and now we all suffer from this eternally offchain.pub",
"sig": "c2cbde7e6a7306dc06865ed812dee75fdc135a0038198050b45c3f85da260920f91f5624b8bb34f7c92ec5ee4b06cd5e9b9b28da66e6fdc97f4059ab375c4db1"
}