Asking for a friend. 

 I can't tell if you're offline or if you're staring in horror at my question. 

 i can live with C but i am not familiar enough with stdio.h to actually do anything useful

but maybe after a few weeks i'd be able to iterate arrays and suchlike

i remember how to do pointer arithmetic and all that, the logic control is very simple and inflexible

i hate the build system though, never did actually grasp how it works, or why i have to repeat my function signature lines in a second.h file, something to do with each C file being an independent binary object so you need to tell the importing code the way to construct valid parameters

let's just say, it's hella primitive and i can do a billion times more with Go, with far less chance of a nasty stack busting bug 

 i guess that's a "no i'm useless to you if you need me to write memory handling" i have a vague concept of how to do it, and i can probably write it really well but it will take me at least 10x longer to do anything, and 100x longer to actually debug it

seriously, i'll just say no, i can build components especially microservice type things and servers in general, code generators, such like tooling, i can invent APIs and codecs, but memory management at that level of irritating detail is just inhuman 

 https://i.imgflip.com/8vh5r1.jpg 

 😂 

 brk(), sbrk() lmfao 

 Actually fun part. My noscrypt makes no calls to allocate heap memory. So much C work can be done on the stack or in the data segment. 

I do maintain forks of mimalloc and rpmalloc for my C# framework  which is fun. 

Take a look into the Cosmopolitan libc and APE loaders which is a pretty awesome project I like to hang out around 
https://github.com/jart/cosmopolitan
 

 i am aware of the uses of stacks

i generally try to use stacks and even registers, it's one of the things i loved about the m68k architecture, so many registers you didn't even need a stack to make many calls, a large number of the improvements that have occurred in the Go compiler output have been achieved through more use of registers, they are the fastest memory in a computer and it's insane how a register-poor architecture like intel has come to dominate, just a reflection of how much abstraction and the bloat it causes is the norm 

 CISC generally does not benefit on a larger register file due to deep pipelines and hyper-threading. Stuff needs to get in and out of registers fast, it also helps with context switching and branch prediction. Again for deep pipeline times L1 is only a few cycles if that.  

 yeah, that's further parts of the reason why i prefer the AMD Zen architecture, because they have simplified the units so much they are literally little sub-dies across the chip instead of a complex whole design as is the norm with intel's engineering

the trend is towards more parallelisation, this helps with latency as well (lower distances of travel) and simplifies manufacturing (less risk of errors in the design due to a simpler design)

as we have seen also, where for a long time intel, notably with the Atom, was getting a better watt/compute ratio 10 years ago, this is now moving in favor of the simplified, parallel architecture of the Zen chips, and i expect the same trend is happening with ARM and MIPS processors as well, with their lower overall engineering budgets versus intel

the difference between SIMD performance on wide bit sizes is phenomenal, i am hoping that some day soon someone makes an secp256k1 signature function in AVX 

 Good chance I will soon :). Likely some ASM because supporting the cross-arch SIMD instructions is a pain in itself. AVX is pretty old now 

 i'm sure i could do it given a month time window, i have reasonable familiarity with assembler syntax in general, and have done a lot of work with iterative operations

just haven't had the time to actually sit down and do it, if you get going on it, i'm keen to follow and if i can, help out

i'm already ridiculously curious about what AVX assembler ops look like 

 Sounds good I'll count you in! 

 gotta follow ya then lol 

 Okay, fair answer. 🫂 

 I have lots of languages coexisting from EDL to Java to C++ to C to Python.  I integrate with message passing / RPC, so there is no issue with binary compatibility.  Struct/copycd/class versions of data layout are easily translated automatically.  My brother uses JSON source for data definitions, and translates that to headers/copycd/etc for various languages.

A lot of people use JSON for messages.  I respect that and have no problem interacting with that, but it is slower. 

 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 

 also, again, it's obviously been a while since you used Go because building a Go app anywhere has been the same since around 2018, it's more reliable and fast for building packages on any system than any other language i know of, literally you can just 

go install url.of.repo/path/to@latest 

and if you configured your path correctly to point where GOBIN has been added, it's instantly available 

 Yes, I am perfectly aware that "works".  You missed the point that that does NOT meet the standard of packaging I insist on, and that distros like Fedora insist on. 

 yeah, and as such have a very difficult time changing the repository or eliminating dependencies

thus we have perl, python, gcc, clang, and a whole bunch of other things in there because the tree of dependencies is more complex than a 1000 year old ficus' root system

this is also why Go itself pioneers the concept of multi-binaries, an idea which started with busybox

every architectural and engineering decision has consequences and you should not ignore the outliers that your chosen one gives you

and it's a hard problem to fix because of the highly decentralised open source development ecosystem, that's why we still have perl even though you can do all that stuff with C or python 

 also, it's a bit of a foggy domain this issue lives in... normal packages don't alter the rc files of shells, there is one main one in /etc and when you install Go it doesn't add to that

in fact, it should be obvious that the shell configurations should actually have a `shell.d` directory which would facilitate that being non-destructive or racy

i like how modules freeze versions of imports and ensure they are valid via git hashes but it was one of the neat things about GOPATH - like the old days of BSD with the /src directory

now, that is something i would like to see come back... pure source OS, so you literally on install drop the source of everything core, bootstrap the compiler and then build everything, using a Go style caching/modula style build cache, and that would also make it a bit easier to introduce dynamic linking if there was a 1:1 between source and binary

probably something that will eventually come in the future... there is already efforts in this direction, and some notable historical attempts towards this kind of goal such as Oberon and Oberon2, actually, one of the earliest, and probably closest to what we see now with the javascript/browser platform was the original Smalltalk, and notably one of Go's founders, Rob Pike, at one time attempted to make a GUI oriented, CSP concurrency language for programming UIs that looks remarkably similar to Go in many respects, the basis of much of the concurrency for sure, and some of the dynamic array stuff

anyhow, it just seems logical to me, if you can have a non-rivalrous namespace to pin every piece of software into, and you have a versioning system that lets you build off a specific version, the really hard problem at this point is still the namespace, and i personally feel that Git overcomplicates the versioning history a little 

 I am not talking about runtime dependencies, which multi-binaries and busybox address.  I am talking about the source code dependencies.   When you have 100 times the number of entities (persons/projects) providing the source code golang pulls in for the easy-peasy build, vetting is 100 times more work.

I really admire the lightning fast compiles of golang and the language features - but the security nightmare of their standard repo is something that younger programmers don't seem to understand, and is shared by other new languages. 

 indeed, along with numerous other features i'd razor out the stdlib (strings is another feature i'd remove)

i'm a rabid golang maxi... less features, more security, more speed 

 for sure the stdlib is the biggest anchor dragging Go down 

 aside from strings 

 yes! also, i want to rewrite the damn golang stdlib, after i rip out the damn string type

also need to change how it treats methods of reference types (slices, maps) so they behave the same way as pointers

these are the two biggest gripes i have with Go

and don't get me started on the math/big library, what a shitshow