since most of Nicolas concerns were answered by others, there's only one thing i'd like to say about: platform-specifc zoo.
At first look it can be scary, but look at opengl binding using nativeboost: we were able to deal with it at image side. And in our case a platform-specific code is maybe less than 1% of total codebase of all NBOpenGL code. Remember an endless issues "B3DAccelerator doesn't works, XYZPlugin doesn't works", because of all this ldconfig/etc mess.. Every time we have such issue, we need to look at VM code, patch it, and rebuilt it again. That means more time and more people involved every time there are issue in VM side. In contrary, if problems like this arising in FFI world, users can easily patch the code by they own, and have stuff working in minuted instead of days (or even months) waiting till new VM build will be released. Especially for OSProcess: why i targeting it? Because it exposing most basic kernel functionality, which can be found on all systems. That means there much less likely will be the problems with linkage with right libs etc. Since OS kernel is there and cannot disappear. And last but not least, of course, avoiding problem of minimal common denominator. For any software experts, i guess , it is important to be able to access the full potential of a system, not a small portion of it. It might be not that important for people with "living in sandbox" mindset, but if you really approach with goals like "i want to implement a modern application on this system using this language" then you probably will start worrying about limitations sooner or later, as well as, how easy you can change it to adopt to your needs. -- Best regards, Igor Stasenko.
