4 ms·

Working on a way to write Oculus Quest apps in Golang. The entire thing is a tower of yak shaving. Current adventure: attempting to write a reactive UI system t

Working on a way to write Oculus Quest apps in Golang. The entire thing is a tower of yak shaving. Current adventure: attempting to write a reactive UI system that doesn't need to dynamically allocate memory.

messe 5y ago
> Current adventure: attempting to write a reactive UI system that doesn't need to dynamically allocate memory. Avoiding dynamic memory allocation... in Go?
- lukem567 5y ago
  One of the many yaks! In this case taking memory mapped Vulkan buffers and unsafeing them to various Go arrays and whatnot. I have a gapbuffer implementation on top of this, and then a truly evil "gaptree" implementation that uses gapbuffers to represent a tree data structure.
  - messe 5y ago
    Do you need to work around Go's escape analysis much? I was under the impression that it's good but not perfect, leading to some heap allocation of variables that wouldn't necessarily need it if they were on C/C++.
    - lukem567 5y ago
      I think "good but not perfect" describes my experience here as well. I've certainly needed to rework some bits of code that were allocating when I didn't expect them to, but so far, this has not become too onerous (yet). The "write a little bit of code, then test it to see if it allocates" approach has been very useful. That way I don't get too far out on a limb with a bunch of allocating code and no easy way to clean things up.
- throwaway34241 5y ago
  It's actually easier than you might think: Go has most of the capabilities of C, including calling C APIs like malloc/free etc and casting them to Go data types. Of course (like C) writing code in that way won't be particularly convenient or memory safe.
  - messe 5y ago
    Well, yes and no. My concern was the fact that Go's escape analysis isn't always correct (although it's quite good), leading to variables that would be stack allocated in C/C++, being heap allocated in Go.
throwaway34241 5y ago
I'm also writing a Quest app in Go, maybe we should chat sometime! I added my email to my profile.

messe 5y ago

> Current adventure: attempting to write a reactive UI system that doesn't need to dynamically allocate memory. Avoiding dynamic memory allocation... in Go?

lukem567 5y ago
One of the many yaks! In this case taking memory mapped Vulkan buffers and unsafeing them to various Go arrays and whatnot. I have a gapbuffer implementation on top of this, and then a truly evil "gaptree" implementation that uses gapbuffers to represent a tree data structure.
- messe 5y ago
  Do you need to work around Go's escape analysis much? I was under the impression that it's good but not perfect, leading to some heap allocation of variables that wouldn't necessarily need it if they were on C/C++.
  - lukem567 5y ago
    I think "good but not perfect" describes my experience here as well. I've certainly needed to rework some bits of code that were allocating when I didn't expect them to, but so far, this has not become too onerous (yet). The "write a little bit of code, then test it to see if it allocates" approach has been very useful. That way I don't get too far out on a limb with a bunch of allocating code and no easy way to clean things up.
throwaway34241 5y ago
It's actually easier than you might think: Go has most of the capabilities of C, including calling C APIs like malloc/free etc and casting them to Go data types. Of course (like C) writing code in that way won't be particularly convenient or memory safe.
- messe 5y ago
  Well, yes and no. My concern was the fact that Go's escape analysis isn't always correct (although it's quite good), leading to variables that would be stack allocated in C/C++, being heap allocated in Go.

throwaway34241 5y ago

I'm also writing a Quest app in Go, maybe we should chat sometime! I added my email to my profile.