Stef wrote: >Our goal is to remove the dependencies to nativeboost. I know that FFI is now maintained again and there is some initiative on a (more) unified FFI. Also there may be some issues with NB: harder to understand than FFI, not complete for ARM, ... Also for Apple devices it is not able to generate/perform machine code in memory. But when you go native you usually have to take care of the underlying system anyway.
But if I understood correctly all this new improvements/movements away from NB will be at the cost of performance: FFI will slower than NB. Or did I misunderstood? The only issues I had with NB so far ist that it initially takes some effort to know the details. But it worked great once one get used to it and I like that Pharo gets fast with it... Why not complete 64 bit, AsmJIT/NB for ARM beside x86 and where possible provide the NB layer? For other platforms we can fall back to FFI when needed. For sure there could be a more unified way to call. Maybe thats the goal of the unified FFI and I just do not know the details. Maybe NB is already planned as a possible backend and it is still possible to use it. Or will it be legacy afterwards? I do not care if it is called "NB" or "FFI" or other, but I would dislike if I had to give up performance or native possibilities or if we just throw away something that was developed/integrated with effort into the image initially. I guess more info or patience is required...
