Does Go has disadvantages in comparison with C/C++ when utilizing in low-level system and embedded programming? – Technical Dialogue

As a disclaimer: I don’t program embedded programs, so take what I say with a grain of salt, and as all the time: “It relies upon,” however:

If you happen to’re primarily writing “glue code” between a bunch of C/C++ APIs, then I’d not advocate utilizing Go, however for those who’re doing any sort of computational work in Python proper now, the overhead of going between C/C++ and Go will primarily fade to nothing due to the efficiency will increase you get from working native CPU code as an alternative of interpreted Python bytecode.

I’m not conversant in ioctl, however there are quite a lot of Ioctl features in unix bundle – golang.org/x/sys/unix – Go Packages, a few of which settle for pointers as parameters and others that return them, so I’m unsure if that remark is outdated, or maybe as a result of it’s a golang.org/x/... bundle exterior of the usual library, maybe the unique poster was not conscious of it, and many others., however I don’t know if that bundle modifications your thoughts.

Relating to IDE assist, I can’t say I’m shocked. In any case, cgo just isn’t go. I’d hope that you must write solely a minimal quantity of cgo code to wrap calls into C/C++ and that the opposite 99% of your code could be plain ol’ Go. If that’s not the case (like in case your venture simply performs some transformations earlier than passing knowledge to/from C/C++ libraries), then possibly Go isn’t the only option, at the least for that sort of venture.

Relating to:

I’m unsure what meaning. Maybe it’s referring to a typical “gotcha” when coping with cgo: That you just can not go a pointer to C if the pointed-to knowledge itself accommodates Go pointers:

kind OKForCGo struct {
    data0 uint32
    data1 uint32
    data2 uint32
}

x := OKForCGo{}
C.do_something(&x)

kind NotOKForCGo struct {
    ptr0 *uint32
    ptr1 *uint32
    ptr2 *uint32
}

y := NotOKForCGo{
    ptr0: new(uint32),
    ptr1: new(uint32),
    ptr2: new(uint32),
}
// not OK, as a result of y.ptr0, .ptr1, and .ptr2 have been allotted from Go.
C.do_something_else(&y)

Nonetheless, if these ptr fields have been allotted with C.malloc, then it might be OK as a result of they’re not Go pointers; they might be C pointers, so possibly the unique poster is referring to the complexity of figuring out if a pointer must be C.freed or not since you don’t know if it’s a Go or C pointer?

tl;dr