3 ms·

MetaCall: Inter-language foreign function interface calls

74 points by pcr910303 7y ago

pcr910303 7y ago
I encountered this library while trying to embed node.js in a C program, but this is useful in all kind of contexts. As mentioned in the README: - Interconnect different technologies in the same project. It allows to have heterogeneous teams of developers working over same project in an isolated way and using different programming languages at the same time. - Embedding programming languages to existing softwares. Game Engines, 3D Editors like [Blender](https://www.blender.org/ https://www.blender.org/), among others can take benefit of METACALL and extend the core functionality with higher level programming languages (aka scripting). - Function as a Service. METACALL can be used to implement efficient FaaS architectures. We are using it to implement our own FaaS (Function as a Service) [https://metacall.io](https://metacall.io/)** https://metacall.io](https://metacall.io/)** based on [Function Mesh](https://medium.com/@metacall/function-mesh-architecture-c0304ba4bad0)** https://medium.com/@metacall/function-mesh-architecture-c030... pattern and high performance function scalability thanks to this library. - Source code migrations. METACALL can wrap large and legacy code-bases, and provide an agnostic way to work with the codebase into a new programming language. Eventually the code can be migrated by parts, without need of creating a new project or stopping the production environment. Incremental changes can be done, solving the migration easily and with less time and effort. - Porting low level libraries to high level languages transparently. With METACALL you can get rid of extension APIs like Python C API or NodeJS N-API. You can call directly low level libraries from your high level languages without making a wrapper in C or C++ for it. This is amazing.
tyingq 7y ago
This seems like a good space to fill. Like an updated and expanded version of Swig (http://www.swig.org/ http://www.swig.org/)
rwmj 7y ago
How does it differ from libffi or Swig?
- HerrMonnezza 7y ago
  From a cursory reading of the README, I would say that Metacall allows any of the supported languages to call any other one, whereas Swig only allows calling C or C++ code. (Swig takes a `.h` file as input and then generates the bindings for the desired target language.)
thekhatribharat 7y ago
The README says: For example, the bad design of NodeJS does not allow to manage the thread pool from outside, so it cannot be preserved after a fork. ;)
- forwhatisworth 7y ago
  I'm sorry but I couldn't help not commenting on this. That comment on the README is disingenuous at best, truly a shame as it now casts for me a different image of what I initially thought to be a cool project worth supporting. node.js was not (of course!) planned to play nice with 'metacall' so I do not see why they were expecting otherwise. I have spent thousands of hours working with and contributing to libuv, V8 and node itself and I can tell you from experience that they are examples of extremely good software engineering and practice. I suggest the authors of this lib (if they´re reading this) to actually spend some time studying the code infrastructure that makes node.js possible instead of just bashing out at it out of mere ignorance. You would be surprised.
  - pcr910303 7y ago
    Well, (I’m not the project maintainer but) I don’t think the mention of ‘bad design’ in the README is ignorant; It is not what I would call a good design at best to one that tries to embed nodejs inside an app. Everyone has different views on what is ‘good’ and what is ‘bad’; the internals can be (and is) beautiful but the external APIs for interacting with nodejs has grown organically(not really designed). There are discussions for a better N-API for embedding in the nodejs issue tracker[1]. The author looks like he has studied enough internals to implement nodejs inside the library; he even (helpfully) explained how metacall has embedded nodejs successfully and improvements available in the nodejs part. [2][3][4] I wouldn’t call that bashing out at it out of mere ignorance. [0]: https://github.com/nodejs/node/issues/23265#issuecomment-427069095 https://github.com/nodejs/node/issues/23265#issuecomment-427... [1]: https://github.com/nodejs/node/issues/23265 https://github.com/nodejs/node/issues/23265 [2]: https://github.com/nodejs/node/issues/23265#issuecomment-452690239 https://github.com/nodejs/node/issues/23265#issuecomment-452... [3]: https://github.com/nodejs/node/issues/23265#issuecomment-496878712 https://github.com/nodejs/node/issues/23265#issuecomment-496... [4]: https://github.com/nodejs/node/issues/23265#issuecomment-496918901 https://github.com/nodejs/node/issues/23265#issuecomment-496...

74 points by pcr910303 7y ago

I encountered this library while trying to embed node.js in a C program, but this is useful in all kind of contexts. As mentioned in the README: - Interconnect different technologies in the same project. It allows to have heterogeneous teams of developers working over same project in an isolated way and using different programming languages at the same time. - Embedding programming languages to existing softwares. Game Engines, 3D Editors like [Blender](https://www.blender.org/ https://www.blender.org/), among others can take benefit of METACALL and extend the core functionality with higher level programming languages (aka scripting). - Function as a Service. METACALL can be used to implement efficient FaaS architectures. We are using it to implement our own FaaS (Function as a Service) [https://metacall.io](https://metacall.io/)** https://metacall.io](https://metacall.io/)** based on [Function Mesh](https://medium.com/@metacall/function-mesh-architecture-c0304ba4bad0)** https://medium.com/@metacall/function-mesh-architecture-c030... pattern and high performance function scalability thanks to this library. - Source code migrations. METACALL can wrap large and legacy code-bases, and provide an agnostic way to work with the codebase into a new programming language. Eventually the code can be migrated by parts, without need of creating a new project or stopping the production environment. Incremental changes can be done, solving the migration easily and with less time and effort. - Porting low level libraries to high level languages transparently. With METACALL you can get rid of extension APIs like Python C API or NodeJS N-API. You can call directly low level libraries from your high level languages without making a wrapper in C or C++ for it. This is amazing.

tyingq 7y ago

This seems like a good space to fill. Like an updated and expanded version of Swig (http://www.swig.org/ http://www.swig.org/)

rwmj 7y ago

How does it differ from libffi or Swig?

HerrMonnezza 7y ago
From a cursory reading of the README, I would say that Metacall allows any of the supported languages to call any other one, whereas Swig only allows calling C or C++ code. (Swig takes a `.h` file as input and then generates the bindings for the desired target language.)

thekhatribharat 7y ago

The README says: For example, the bad design of NodeJS does not allow to manage the thread pool from outside, so it cannot be preserved after a fork. ;)

forwhatisworth 7y ago
I'm sorry but I couldn't help not commenting on this. That comment on the README is disingenuous at best, truly a shame as it now casts for me a different image of what I initially thought to be a cool project worth supporting. node.js was not (of course!) planned to play nice with 'metacall' so I do not see why they were expecting otherwise. I have spent thousands of hours working with and contributing to libuv, V8 and node itself and I can tell you from experience that they are examples of extremely good software engineering and practice. I suggest the authors of this lib (if they´re reading this) to actually spend some time studying the code infrastructure that makes node.js possible instead of just bashing out at it out of mere ignorance. You would be surprised.
- pcr910303 7y ago
  Well, (I’m not the project maintainer but) I don’t think the mention of ‘bad design’ in the README is ignorant; It is not what I would call a good design at best to one that tries to embed nodejs inside an app. Everyone has different views on what is ‘good’ and what is ‘bad’; the internals can be (and is) beautiful but the external APIs for interacting with nodejs has grown organically(not really designed). There are discussions for a better N-API for embedding in the nodejs issue tracker[1]. The author looks like he has studied enough internals to implement nodejs inside the library; he even (helpfully) explained how metacall has embedded nodejs successfully and improvements available in the nodejs part. [2][3][4] I wouldn’t call that bashing out at it out of mere ignorance. [0]: https://github.com/nodejs/node/issues/23265#issuecomment-427069095 https://github.com/nodejs/node/issues/23265#issuecomment-427... [1]: https://github.com/nodejs/node/issues/23265 https://github.com/nodejs/node/issues/23265 [2]: https://github.com/nodejs/node/issues/23265#issuecomment-452690239 https://github.com/nodejs/node/issues/23265#issuecomment-452... [3]: https://github.com/nodejs/node/issues/23265#issuecomment-496878712 https://github.com/nodejs/node/issues/23265#issuecomment-496... [4]: https://github.com/nodejs/node/issues/23265#issuecomment-496918901 https://github.com/nodejs/node/issues/23265#issuecomment-496...