As a disclaimer: I don’t program embedded systems, so take what I say with a grain of salt, and as always: “It depends,” but:
If you’re essentially writing “glue code” between a bunch of C/C++ APIs, then I would not recommend using Go, but if you’re doing any kind of computational work in Python right now, the overhead of going between C/C++ and Go will essentially fade to nothing because of the performance increases you get from running native CPU code instead of interpreted Python bytecode.
I’m not familiar with ioctl, but there are a lot of Ioctl
functions in unix package - golang.org/x/sys/unix - Go Packages, some of which accept pointers as parameters and others that return them, so I’m not sure if that comment is out of date, or perhaps because it’s a golang.org/x/...
package outside of the standard library, perhaps the original poster was not aware of it, etc., but I don’t know if that package changes your mind.
Regarding IDE support, I can’t say I’m surprised. After all, cgo is not go. I would hope that you have to write only a minimal amount of cgo code to wrap calls into C/C++ and that the other 99% of your code would be plain ol’ Go. If that’s not the case (like if your project just performs some transformations before passing data to/from C/C++ libraries), then maybe Go isn’t the best choice, at least for that kind of project.
Regarding:
I’m not sure what that means. Perhaps it’s referring to a common “gotcha” when dealing with cgo: That you cannot pass a pointer to C if the pointed-to data itself contains Go pointers:
type OKForCGo struct {
data0 uint32
data1 uint32
data2 uint32
}
x := OKForCGo{}
C.do_something(&x)
type NotOKForCGo struct {
ptr0 *uint32
ptr1 *uint32
ptr2 *uint32
}
y := NotOKForCGo{
ptr0: new(uint32),
ptr1: new(uint32),
ptr2: new(uint32),
}
// not OK, because y.ptr0, .ptr1, and .ptr2 were allocated from Go.
C.do_something_else(&y)
However, if those ptr
fields were allocated with C.malloc
, then it would be OK because they’re not Go pointers; they would be C pointers, so maybe the original poster is referring to the complexity of knowing if a pointer needs to be C.free
d or not because you don’t know if it’s a Go or C pointer?
tl;dr
If you can write most of your code in normal Go (non-cgo) and only need cgo to bridge a gap between your Go code and the OS/some embedded hardware, then Go should be fine.
If your entire program is all about calling C/C++ functions, then Go is probably not worth it.