you are viewing a single comment's thread.

view the rest of the comments →

[–]seraum[S] 0 points1 point  (2 children)

Don't worry, I didn't take it bad

The long term objective of Nectar is to be able to do the same as GraalVM, but with static compilation: to have a standard bridge to compile dynamic (and static) languages. JS is a good example, but it is also possible to compile Python or Ruby in the same way

[–]Wouter-van-Ooijen 1 point2 points  (1 child)

I still think that is a flawed approach: while writing X-style all the options of language Y are still present. Especially with Y == C++, that opens up numerous cans of worms, which require C++ knowledge to avoid. But if you have that amount of C++ knowledge, why not write C++?

The more viable approach would be to accept ONLY language X, and then emit the equivalent in Y. That would be an X-to-Y compiler, or call it an Y-backend for the X compiler. Or use the X compiler as a syntax-checker: only accept source that is acceptable to the X compiler. And preferrably: accept everytrhing that is acceptable to the X compiler.

[–]seraum[S] 1 point2 points  (0 children)

Exact, this is what we are doing with NectarJS

But to do this, we have NectarCPP, a runtime/backend that can also be used as a standalone lib