Defining a Go target for Rust actually makes sense in the context of replacing assembly (which has no runtime, GC or concurrency connotations), I was just too lazy to do it that way :)
This is a good thing because `cgo` is really bad. No ALSR, always forking. These are completely _insane_ defaults, it manages to be slower then the JNI [1] which is an FFI from a completely managed stack based VM universe! Not a _compiled_ language.
Somehow a compile language calling a static binary manages to be slower then a dynamic language's runtime calling a static binary...
`cgo` isn't doing _anything right_. It is doing a lot of things wrong.
No, if you think there are problems with cgo, the solution is to address those problems, not reinvent it. If you have performance concerns, file a bug or comment on an existing one.
Also, I don't see any reason why jni should be slower than cgo. Go has its own scheduler that brings overhead to cgo and needs to switch stacks whereas Java doesn't have to deal with such things.
> No, if you think there are problems with cgo, the solution is to address those problems, not reinvent it. If you have performance concerns, file a bug or comment on an existing one.
Well, sometimes the solution is to reinvent it and provide another solution. Sometimes a project has a specific goal which might preclude them from using your idea, or the people involved just have a slightly different vision.
Sometimes, if you believe the existing project is wrong from the ground up, the solution is to reinvent it as something else. Sometimes it doesn't pan out, sometimes it does.
That's the beauty of open source.
>If you have performance concerns, file a bug or comment on an existing one.
Excuse my language, or don't. But the Go-Maintainers really don't give shit about improving their languages performance. Also FFI ALSR is disabled for debugging simplicity. Which I can only imagine means they debug by reading literal core dumps by hand.
Furthermore I'd rather not donate my time and energy to a company as large as Google.
>Also, I don't see any reason why jni should be slower than cneeds to switch stacks whereas Java doesn't have to deal with such things.
The JVM has its own scheduler to keep locks fair, also OpenJDK does green threading in its runtime to allow for GC cycles on JIT'd code. I'm pretty sure Oracle and Azule do a well since JIT execution/cleanup requires doing stack swapping.
> However, C code may not keep a copy of the Go pointer after the call returns.
It looks like they've just punted on the pinning issue and not allowed code that does it.
Having written a ton of FFI code across a wide range of languages this type of restriction means that you're not going to be able to implement certain things which is unfortunate.
Defining a Go target for Rust actually makes sense in the context of replacing assembly (which has no runtime, GC or concurrency connotations), I was just too lazy to do it that way :)