4 ms·

It's still absolutely terrible in terms of ergonomics. You're forced to perform manual memory management, etc. I've done it a few times and I absolutely don't r

by riking 10y ago

It's still absolutely terrible in terms of ergonomics. You're forced to perform manual memory management, etc. I've done it a few times and I absolutely don't recommend it.

steveklabnik 10y ago
I'm not making any value judgements here; just saying that the times have decreased significantly since the links that were posted.
burntsushi 10y ago
Finalizers help with memory management in the simple cases.
- danieldk 10y ago
  But C code may not keep a Go pointer that persists between calls (because GC). I can imagine that this is a problem for gradually converting code bases.
  - burntsushi 10y ago
    Sure but that's not what I was replying to? I was only talking about Go->C FFI. If someone didn't know about finalizers, then I've might be trying to insert `free` calls everywhere in their Go code, which could become quite annoying. But yes, Go pointers in C code is bad juju.
    - danieldk 10y ago
      Sure but that's not what I was replying to? I was only talking about Go->C FFI. Sorry, my reply was too brief. I wanted to add that the ergonomics are bad, not just because of freeing memory (for which the inconvenience can indeed be reduced with finalizers and/or Close() methods plus defer). But rules such as this one make Go->C FFI unergonomic as well. To give one example: many linear algebra libraries (e.g. Tensorflow) have their own wrappers around raw arrays to represent tensors (with their dimensionality) [1]. As a consequence of this rule, one cannot just a pointer to the first slice element to such functions (since a pointer to a Go object would be stored in a C struct), but have to malloc an array and copy over data from the slice to the C array. [1] There are other issues, such aligning slice memory to 16-byte boundaries.
      - burntsushi 10y ago
        Ah yes, you are absolutely right. I actually modified Rust's regex C API in part because of this problem in Go. I can't remember the details, but they were similar to your example where the only way to work around it was an unavoidable additional allocation. (Of course, I think the change led to a better overall API. Go just helped me get there in a circuitous way.)

by riking 10y ago

It's still absolutely terrible in terms of ergonomics. You're forced to perform manual memory management, etc. I've done it a few times and I absolutely don't recommend it.

steveklabnik 10y ago

I'm not making any value judgements here; just saying that the times have decreased significantly since the links that were posted.

burntsushi 10y ago

Finalizers help with memory management in the simple cases.

danieldk 10y ago
But C code may not keep a Go pointer that persists between calls (because GC). I can imagine that this is a problem for gradually converting code bases.
- burntsushi 10y ago
  Sure but that's not what I was replying to? I was only talking about Go->C FFI. If someone didn't know about finalizers, then I've might be trying to insert `free` calls everywhere in their Go code, which could become quite annoying. But yes, Go pointers in C code is bad juju.
  - danieldk 10y ago
    Sure but that's not what I was replying to? I was only talking about Go->C FFI. Sorry, my reply was too brief. I wanted to add that the ergonomics are bad, not just because of freeing memory (for which the inconvenience can indeed be reduced with finalizers and/or Close() methods plus defer). But rules such as this one make Go->C FFI unergonomic as well. To give one example: many linear algebra libraries (e.g. Tensorflow) have their own wrappers around raw arrays to represent tensors (with their dimensionality) [1]. As a consequence of this rule, one cannot just a pointer to the first slice element to such functions (since a pointer to a Go object would be stored in a C struct), but have to malloc an array and copy over data from the slice to the C array. [1] There are other issues, such aligning slice memory to 16-byte boundaries.
    - burntsushi 10y ago
      Ah yes, you are absolutely right. I actually modified Rust's regex C API in part because of this problem in Go. I can't remember the details, but they were similar to your example where the only way to work around it was an unavoidable additional allocation. (Of course, I think the change led to a better overall API. Go just helped me get there in a circuitous way.)