If the language provides nice features to libraries for C language users by sabotaging the library for use outside the language, then this is absolutely a problem on the language side.
The library interface says to do X call `Foo(FOO_VAR_1, b, c)`. That is what you need to somehow call from another language using FFI. In addition it also has an example wrapper for convenience. You can choose to also include that example as part of your implementation in another language, but you don't need to. I fail to see how that is sabotaging.
It also does not have to do anything with the language, because it IS possible to have FooVar1 as part of the interface. The library developer just didn't want that, likely because they do not want tons of slightly different functions in the interface that they would need to maintain, when they already exposed that functionality.
EDIT:
Concerning your earlier complaint, that you would need to
> have to redo subsequent version updates in your code.
, such a change would be ABI-incompatible anyway and demand a change in the major version number of the library. Neither your FFI, nor any program even when written in C, is going to work anymore. The latter, would just randomly crash, not sure about the former.
Note, that you also see here, where the real interface is. A change to Foo itself, would break programs written in C as well as your FFI, while a change to FooVar1 wouldn't matter at all. Both C programs and your FFI will continue to run just fine without any changes.
> likely because they do not want tons of slightly different functions
No. They do it because it avoids the overhead of dynamic dispatch. Nothing else.
So when I've seen these in reality in real library interfaces they have not been 'example wrappers'. They are real intended usage of the API, and in some cases the lib authors recognize that it is a problem and even provide ways to build it without the issues - either by compile time flag or always outputting two variants of the .so. The former moves the question to the distro - should they provide the version optimized for C or the one optimized for other languages? In the case of the latter it obviously creates a situation where the vast majority of both .so-s are duplicated.
As an example of the compile flag, there is libpipewire. As an example of providing two versions of the .so, there is liburing.
So no, this is clearly something the language ecosystem lacks a good answer to. There is currently no way to make everyone happy.
> such a change would be ABI-incompatible anyway
True, but the C based ones can at least simply rebuild and the problem would go away.
1718627440|19 days ago
It also does not have to do anything with the language, because it IS possible to have FooVar1 as part of the interface. The library developer just didn't want that, likely because they do not want tons of slightly different functions in the interface that they would need to maintain, when they already exposed that functionality.
EDIT:
Concerning your earlier complaint, that you would need to
> have to redo subsequent version updates in your code.
, such a change would be ABI-incompatible anyway and demand a change in the major version number of the library. Neither your FFI, nor any program even when written in C, is going to work anymore. The latter, would just randomly crash, not sure about the former.
Note, that you also see here, where the real interface is. A change to Foo itself, would break programs written in C as well as your FFI, while a change to FooVar1 wouldn't matter at all. Both C programs and your FFI will continue to run just fine without any changes.
yxhuvud|19 days ago
No. They do it because it avoids the overhead of dynamic dispatch. Nothing else.
So when I've seen these in reality in real library interfaces they have not been 'example wrappers'. They are real intended usage of the API, and in some cases the lib authors recognize that it is a problem and even provide ways to build it without the issues - either by compile time flag or always outputting two variants of the .so. The former moves the question to the distro - should they provide the version optimized for C or the one optimized for other languages? In the case of the latter it obviously creates a situation where the vast majority of both .so-s are duplicated.
As an example of the compile flag, there is libpipewire. As an example of providing two versions of the .so, there is liburing.
So no, this is clearly something the language ecosystem lacks a good answer to. There is currently no way to make everyone happy.
> such a change would be ABI-incompatible anyway
True, but the C based ones can at least simply rebuild and the problem would go away.