3 ms·

> garbage collection made any systems language a nonstarter. Unless you want to bucket all systsme programming in to one bucket, I will say this #1 If your go

by harikb 7y ago

> garbage collection made any systems language a nonstarter. Unless you want to bucket all systsme programming in to one bucket, I will say this #1 If your goal is to make the most efficient and fast code (garbage collected or not), it is not clear gc-less languages are always better. Sometimes, not free-ing the memory at the first possible time will actually be good for you overall. #2 If you are writing anything with serious mem usage in Go, you will optimize for allocations using sync.Pool or some other form of reuse. I am sure well written C++ code would have to do the same tricks. reduce >> reuse >> recycle. Both GC and free() are recyclers. Sure, one could argue GC could provide more control. I 100% agree there are cases C/C++ or Rust would be better for 20% of the trickier situation, but let us not base it all on the presence of garbage collector. Heck, some of my Java code works faster than even my Go code. I don't blame Java for having a garbage collector.

cletus 7y ago
> #1 If your goal is to make the most efficient and fast code (garbage collected or not), it is not clear gc-less languages are always better. Sometimes, not free-ing the memory at the first possible time will actually be good for you overall. Which is why languages like C++ let you write and use your own allocators. There are lots of reasons to do this (eg word alignment). And while I agree that it's certainly possible that delayed freeing may be beneficial I'm not convinced it's a problem in practice, at least when you compare it to how often common GC problems are (eg memory leaking (admittedly also a problem with manual allocation), out-of-control process memory growth and STW pauses). #2 If you are writing anything with serious mem usage in Go, you will optimize for allocations using sync.Pool or some other form of reuse. True, and I mentioned this in another comment: the idea that you can get around many GC issues by using object and memory pools. > Heck, some of my Java code works faster than even my Go code. Why should that be surprising? The JVM at this point has >25 years of engineering effort into it and (IMHO) it doesn't get half the credit it deserves from the devotees of the latest flavour of the month.
- ori_b 7y ago
  > Which is why languages like C++ let you write and use your own allocators. There are lots of reasons to do this (eg word alignment). You're aware that the Go allocator is written in Go, right?
  - erik_seaberg 7y ago
    Is there a way to write and use your own allocator, or is it off limits to everyone outside the language design team?

by harikb 7y ago

cletus 7y ago

> #1 If your goal is to make the most efficient and fast code (garbage collected or not), it is not clear gc-less languages are always better. Sometimes, not free-ing the memory at the first possible time will actually be good for you overall. Which is why languages like C++ let you write and use your own allocators. There are lots of reasons to do this (eg word alignment). And while I agree that it's certainly possible that delayed freeing may be beneficial I'm not convinced it's a problem in practice, at least when you compare it to how often common GC problems are (eg memory leaking (admittedly also a problem with manual allocation), out-of-control process memory growth and STW pauses). #2 If you are writing anything with serious mem usage in Go, you will optimize for allocations using sync.Pool or some other form of reuse. True, and I mentioned this in another comment: the idea that you can get around many GC issues by using object and memory pools. > Heck, some of my Java code works faster than even my Go code. Why should that be surprising? The JVM at this point has >25 years of engineering effort into it and (IMHO) it doesn't get half the credit it deserves from the devotees of the latest flavour of the month.

ori_b 7y ago
> Which is why languages like C++ let you write and use your own allocators. There are lots of reasons to do this (eg word alignment). You're aware that the Go allocator is written in Go, right?
- erik_seaberg 7y ago
  Is there a way to write and use your own allocator, or is it off limits to everyone outside the language design team?