4 ms·
>It abstracts everything as if you were on a 1975 computer, so there's allocations, allocations everywhere! Care to elaborate? Generally you don't care about m
by kgeist 5y ago
>It abstracts everything as if you were on a 1975 computer, so there's allocations, allocations everywhere!
Care to elaborate? Generally you don't care about memory management in Go at all, so I wouldn't call it 1975 programming where you certainly would. Sure, taking the address of a variable heap-allocates but that's an implementation detail and I don't see how it's related to the article at all. It's automatic and you don't even think about it. The article talks about userland software reinventing what's already implemented in a modern operating system. How is it the case with heap allocations in Go, escape analysis etc.? Operating systems don't have means to do escape analysis for userland variables. Or did you get the conclusion from the article that slow=1975 programming? I don't think that's what the author meant.
- GordonS 5y ago> Generally you don't care about memory management in Go at all I think this is true for the majority of devs, just as it is for any managed language (C#, Java...). But sometimes you are working on something performance sensitive, and there minimising allocations can be a real problem.
- kgeist 5y agoAbstractions do have costs, no doubt. I just don't see the connection between "Go heavily uses interfaces which force heap allocation in the current implementation" and "1975 programming". How would one go from 1975 to current year? By stopping using abstractions? Isn't that exactly what 1975 programming was to begin with?
- GordonS 5y agoWell, yes, I have to agree that I don't see the link between allocations, abstractions and 1975 ¯\_(ツ)_/¯