MetaCall: Inter-language foreign function interface calls | Hacker News Reader

MetaCall: Inter-language foreign function interface calls

github.com

74 pointspcr9103038 comments

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/), 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/)** based on [Function Mesh](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.

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

How does it differ from libffi or Swig?

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.)

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. ;)

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.

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... [1]: https://github.com/nodejs/node/issues/23265 [2]: https://github.com/nodejs/node/issues/23265#issuecomment-452... [3]: https://github.com/nodejs/node/issues/23265#issuecomment-496... [4]: https://github.com/nodejs/node/issues/23265#issuecomment-496...

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 ...

Reply on news.ycombinator.com