
MetaCall: Inter-language foreign function interface calls - pcr910303
https://github.com/metacall/core
======
pcr910303
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-c030...](https://medium.com/@metacall/function-mesh-
architecture-c0304ba4bad0\)**) 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
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
How does it differ from libffi or Swig?

~~~
HerrMonnezza
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
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
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
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-427...](https://github.com/nodejs/node/issues/23265#issuecomment-427069095)
[1]:
[https://github.com/nodejs/node/issues/23265](https://github.com/nodejs/node/issues/23265)
[2]:
[https://github.com/nodejs/node/issues/23265#issuecomment-452...](https://github.com/nodejs/node/issues/23265#issuecomment-452690239)
[3]:
[https://github.com/nodejs/node/issues/23265#issuecomment-496...](https://github.com/nodejs/node/issues/23265#issuecomment-496878712)
[4]:
[https://github.com/nodejs/node/issues/23265#issuecomment-496...](https://github.com/nodejs/node/issues/23265#issuecomment-496918901)

~~~
forwhatisworth
I am sorry but you do not understand what we are talking about. Do not worry,
we have all been there at some point and it is on my best interest to explain
to you what's going on :)

The sentence "the bad design of node.js does not allow to manage the thread
pool from outside" implies two things initially, 1. that there is a thread
pool, which is part of the architecture of node.js and 2. that this thread
pool cannot be managed by an external program. On the same sentence, they then
try to use these concepts combined as an argument to "the bad design of
node.js".

What I wanted to convey is that this statement -> "the bad design of node.js"
is a huge hyperbole and it is blatantly wrong, since it is actually a very
good "real-world" example of good software design and practices. Anyone that
has spent at least a couple days interacting with the developer community
behind node.js and sister project can attest their level of knowledge, talent
and commitment.

Also, just bashing on a project that you're building on top of is an extremely
tasteless display of vulgarity ...

