i'm a #golang maxi myself, no other language has coroutines in the base syntax and no other language is as readable nor compiles as fast
you can program in a functional style in go but it can make performance bad because you dump so much garbage memory when you do everything pass by value return by value and no mutability
functional doesn't really even say anything about concurrency and when you mix concurrent and functional together it's a terrible mess of memory waste and hellish STW GC pauses
on teh other hand, remembering to lock and unlock mutexes is a pain in teh ass too
it's really the thing that makes #golang shine is you can use almost every style of architecture and execution except for object oriented, it instead has interfaces and anonymous struct members which allows for concise composition of composite data types and accessors to mutate them
go is much maligned because it demands a kind of discipline that most other languages don't teach you, for example as i work through forking fiatjaf and mattn's codebases they excessively use "generics" and interfaces, which they clearly don't understand, and write code that ends up being slower and more long winded than a static typed version
i can tell that fiatjaf, at least, has a javascript/python background because he seems to loathe dealing with types properly, almost none of his interface using code has any type assertion safety, which is partly why i have to do the work to fork it, i have had code like this bomb out on edge cases many times before and i'm just not interested in delivering trash like that
in Go you can't just say "unpack this interface into this type" and pray that it is ok because it stops the whole runtime
Haskell has a copying garbage collector for that reason. You can't use the wrong tool for the job and then complain it doesn't work well.
that doesn't change how much memory it takes to compile and the relative amount of memory it needs to do the same task
i personally believe that as a programmer if you don't have a grasp of the architecture of the hardware then you can't write good code for it
i don't like the architecture of the intel/amd type of processor, the motorola is a much more generous design with more and more logically designed fast short term memory storage elements
if your code doesn't respect the limitations of the hardware it will develop mysterious problems that seem perfect in the language but are not fit for the hardware
to me that is the centre of the Go philosophy - humans learn how to write the code for the machine, which is the polar opposite of the C++ philosophy which is the machine interprets the code, usually very imperfectly, and thus slowly, to finally get a decent performance
functional is nice but it would only work really well on a simplified architecture with very large register files, like the hardware actually is now, but not how it actually uses it, it doesn't let you actively choose where your data is stored, and thus if you blow its internal processing budgets of memory in one cache you are punished with a big memory copy or access and a lesser performance
i'm sure there is many ways to improve computer programming but any that disrespect the hardware's limitations is punished by slow compilation and higher runtime memory utilization which leads to less performance, and more chances of bugs slipping through due to a long edit/test cycle
no single model fits the hardware because the hardware is highly heteregonous in its design in order to - probably - fit all these divergent philosophies of program organisation
If you are talking about fiatjaf/relayer, which I maintain, I expect that relayer can change its behaviour depending on whether it implements a method or not. If you want that functionality, just add a method. This is not a feature provided by generics.
no, i've been working with algia, no need for me to use several and i prefer the completeness of khatru and its relative modularity
i would just like to tell you that at least on the algia codebase, you don't break things into small pieces enough, some of the functions are extremely long winded and repetitive and several different slight variations in many cases to do the exact same thing, it's not easy to follow or change
I understand that and I will have to refactor it you said. I just don't have the enough time for it at the moment.
FYI, patches are welcome.
of course, and i would but i'm also retargeting it to a refactored version of go-nostr so it isn't really possible, i have got several parts of it fully working now but others i don't understand so well or need yet so ... anyhow... i appreciate your manners, i hope you don't mind my simpleness
Oddbean new post about login | logout