4 ms·

This is probably the thing that annoys me the most about golang: It abstracts everything as if you were on a 1975 computer, so there's allocations, allocations

This is probably the thing that annoys me the most about golang: It abstracts everything as if you were on a 1975 computer, so there's allocations, allocations everywhere! And trying to keep them under control requires intimate knowledge about go's implementation details. Failure to do so dooms your program to run 3-4x slower since allocations are horribly slow to begin with, and now your data is spread all over the place. And even then, there are still some things (like []byte <-> string) that you simply can't get around (unless you want to delve into unsafe land and risk your code blowing up once the runtime implementation changes).

masklinn 6y ago
To be fair to Go, it provides an escape analysis log and a memory profiler in the standard distribution, so while fixing the heap allocations can require good knowledge of implementation details, finding out that you have heap allocations is really easy.
- throwaway894345 6y ago
  Go is also not that clever, so you can often intuit fairly easily where the allocations are taking place and how to avoid them. As far as optimizing goes, it’s a lot easier to optimize away allocations in Go than in many other languages. I also think this is the right tradeoff—most code isn’t that sensitive to allocations so why make the programmer think about the 100% of the time, rather than opting into thinking about them in order to optimize the hot path?
kgeist 6y 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 6y 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 6y ago
    Abstractions 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 6y ago
      Well, yes, I have to agree that I don't see the link between allocations, abstractions and 1975 ¯\_(ツ)_/¯
phkamp 6y ago
I think this comes down to the right tool for the job. If you have a lot of programmers churning out code, languages like golang makes it harder for them to make mistakes, sometimes at the cost of performance, but 99.9% of the time, performance does not matter. If performance matters, there is no better language than C to bend the hardware to your precise will, but that comes at a cost of programming difficulty.

masklinn 6y ago

To be fair to Go, it provides an escape analysis log and a memory profiler in the standard distribution, so while fixing the heap allocations can require good knowledge of implementation details, finding out that you have heap allocations is really easy.

throwaway894345 6y ago
Go is also not that clever, so you can often intuit fairly easily where the allocations are taking place and how to avoid them. As far as optimizing goes, it’s a lot easier to optimize away allocations in Go than in many other languages. I also think this is the right tradeoff—most code isn’t that sensitive to allocations so why make the programmer think about the 100% of the time, rather than opting into thinking about them in order to optimize the hot path?

kgeist 6y 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 6y 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 6y ago
  Abstractions 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 6y ago
    Well, yes, I have to agree that I don't see the link between allocations, abstractions and 1975 ¯\_(ツ)_/¯

phkamp 6y ago

I think this comes down to the right tool for the job. If you have a lot of programmers churning out code, languages like golang makes it harder for them to make mistakes, sometimes at the cost of performance, but 99.9% of the time, performance does not matter. If performance matters, there is no better language than C to bend the hardware to your precise will, but that comes at a cost of programming difficulty.