4 ms·

> I only wish it was a bit more C-like and you had the ability to run it without a garbage collector "import C, import unsafe". You absolutely can, at least f

by rahen 4y ago

> I only wish it was a bit more C-like and you had the ability to run it without a garbage collector "import C, import unsafe". You absolutely can, at least for performance critical sections where you cannot afford garbage collection. https://dgraph.io/blog/post/manual-memory-management-golang-jemalloc https://dgraph.io/blog/post/manual-memory-management-golang-...

throwaway894345 4y ago
You don't even need CGo or unsafe to deal without a GC. Go's GC is written in Go and it obviously doesn't depend on a GC! You just need to know which features imply a GC/allocation and you need to take care to avoid those features. Conceivably, you could devise a linter that statically verifies your no-GC requirement.
- rahen 4y ago
  > You just need to know which features imply a GC/allocation and you need to take care to avoid those features. This is very insightful. Would you mind sharing more resources regarding that? I'd be interested in a list of such features. The GC can also be used manually by setting GOGC=off, then be triggered manually at the most convenient time.
  - throwaway894345 4y ago
    I don't know of any resources, but basically you can intuit pretty easily about how to avoid allocations in Go (don't allocate or grow slices, don't use maps, avoid returning references to anything you allocate inside of your function call, etc), and there are flags you can pass to the compiler to log allocation points. If you don't allocate, then there's nothing to collect, and you can even turn off the GC altogether.
  - jrockway 4y ago
    Tinygo lets you build your program with the option -gc=none that results in a link error at every point in your program that would allocate memory on the heap. So that's a very easy way to find them. Tinygo is a completely separate implementation of Go, so not every program is going to be portable 1 to 1, and I suppose that where Tinygo might allocate memory is different than where normal Go would allocate memory, so you'll have to take the results with a grain of salt. It is of course possible to use Tinygo-compiled programs for your production use case as well. It has a focus on WebAssembly and microcontrollers, but produces perfectly-serviceable amd64 binaries as well.

by rahen 4y ago

throwaway894345 4y ago

You don't even need CGo or unsafe to deal without a GC. Go's GC is written in Go and it obviously doesn't depend on a GC! You just need to know which features imply a GC/allocation and you need to take care to avoid those features. Conceivably, you could devise a linter that statically verifies your no-GC requirement.

rahen 4y ago
> You just need to know which features imply a GC/allocation and you need to take care to avoid those features. This is very insightful. Would you mind sharing more resources regarding that? I'd be interested in a list of such features. The GC can also be used manually by setting GOGC=off, then be triggered manually at the most convenient time.
- throwaway894345 4y ago
  I don't know of any resources, but basically you can intuit pretty easily about how to avoid allocations in Go (don't allocate or grow slices, don't use maps, avoid returning references to anything you allocate inside of your function call, etc), and there are flags you can pass to the compiler to log allocation points. If you don't allocate, then there's nothing to collect, and you can even turn off the GC altogether.
- jrockway 4y ago
  Tinygo lets you build your program with the option -gc=none that results in a link error at every point in your program that would allocate memory on the heap. So that's a very easy way to find them. Tinygo is a completely separate implementation of Go, so not every program is going to be portable 1 to 1, and I suppose that where Tinygo might allocate memory is different than where normal Go would allocate memory, so you'll have to take the results with a grain of salt. It is of course possible to use Tinygo-compiled programs for your production use case as well. It has a focus on WebAssembly and microcontrollers, but produces perfectly-serviceable amd64 binaries as well.