Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The FAQ doesn't cover "how does this differ from lua", but overview contains the disclaimer:

> not all Lua features are implemented yet. Most of the dynamic parts, such as tables and handling dynamic types at runtime

It has coroutines to some extent

> At the moment Nelua does not support variable arguments in yield and resume (unlikely Lua).

It also extends lua primitives - lots of control flow things, arrays and records which look like tables but are passed by value, not by reference.

So it's an ahead of time statically typed language which looks somewhat like lua. Compiled to C, no interpreter. It says it's meta-programmable using lua which I assume is really confusing given the two languages look similar and behave differently.



One under-advertised feature of the language is that it supports WASM: https://github.com/edubart/nelua-lang/discussions/11

It’s been used successfully to make games for virtual game consoles like wasm4 and GamerCade.


>"Compiled to C"

Must be fun to debug generated C code.


It's very easy with the "#line" macro. Works perfectly with gdb too, at least in Nim-land debugging embedded firmware via JTAG.


C compiles to assembly, Chez Scheme compiles to C, Idris2 compiles to Chez Scheme. They are fine languages to work with.


To each their own. If I can't step through original code when debugging I am not interested. I've had my share of debugging machine codes. Do not want anything resembling it.


#line directive gives you exactly that, you step through original code, it's similar to source maps in JavaScript. #line directive has two arguments the file name and the line of the source in your language i.e. nim, nelua, koka whatever. Debuggers support it for decades. Having said that, printing variables and making debugger aware of the type system of the original language is another story maybe someone can comment on that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: