Why did you develop NELUA ?

[k1attila1]

We have RUST. Fast, safe,no GC, big community, support...... RUST solves almost any problem.

I don't understand why people develop V, Odin, Nim, Beef etc.....

[StateOfGrace1984]

To quote the readme in the repository:

• We love to script in Lua.
• We love C performance.
• We want best of both worlds in a single language and with a unified syntax.
• We want to reuse or mix existing C/C++/Lua code.
• We want type safety and optimizations.
• We want to have efficient code while maintaining readability and safety.
• We want the language features and manual to be minimal and fit our brain.
• We want to deploy anywhere C runs.
• We want to extended the language features by meta programming or modding the compiler.
• We want to code with or without garbage collection depending on our use case.
• We want to abuse of static dispatch instead of dynamic dispatch to gain performance and correctness."

[edubart]

We have Rust. Fast, safe,no GC, big community, support...... RUST solves almost any problem.

Although Nelua and Rust share some similarities, both languages have different goals and style. If you like Rust and feel that fit your needs and your projects, then stick with it.

Nelua is my lone research on a language that feels like a scripting language (full dynamic typing) yet is a very efficient system language (full static typing, optional GC, efficient as C), and still simple. This is the end goal, although it is not there yet I don't see any reason to avoid creating such language, because if I can, why not? Why people create and use different cars, clothes, software?

Lua is a very simple scripting language that many new programmers (even non programmers) can learn in a day and be productive fast, if Nelua can run most Lua code it will feel the same for newcomers, yet its static typing and extra meta programming features will let experiment programmers push out most performance and efficiency from it. Rust is not like this, it doesn't feel like "scripting" because is not in their goals.

Rust made great progress on safety for a system programming language, Nelua is trying to progress in other areas, as well others like Odin, Nim, Beef, in different areas, each one has something unique and interesting, and I am also inspired by them, and I also hope they grow.

[k1attila1]

Thank you edubart.

A question about optional GC :

What about if a library use GC ?

[edubart]

If a library coded in Nelua uses the GC, then the user using it is responsible for also leaving the GC enabled, otherwise the memory will leak. That said, a library made with GC usage in mind, can later be improved to support applications that want to disable the GC by adding deallocation methods for its allocated primitives.

[k1attila1]

if yout goal is to develop a good and fast alternative for LUA developer then a i think NELUA is a very good direction but for system programming language i think not.
It has similar problem like D (libs may depend on GC) GC, Even if it can be turned off.

Otherwise nice work.

[edubart]

It is for both, GC is not mandatory, but it's handy for quick prototype. People used to develop in Lua world would hate to prototype simple scripts with either manual memory management or alternative like ownership (like in Rust), so the GC is there. On the other hand people who make high efficient game engines would hate to code with GC enabled, so option to disable the GC is there.

If a library uses the GC and someone would like to not use, the problem is in the library or bad pick of what library to use, not in the language. The language does not enforce only one way to manage the memory, and its internal libraries are always made with optional GC in mind. Also the language does not enforce much "good" practices, this is not a language that tries to "teach" people only one way to do something by blocking unsafe things from its users. When the GC is off it's meant for C users who knows what is doing and how to manage memory.

[k1attila1]

" its internal libraries are always made with optional GC in mind."

if that's true, it's good.

thank you

[k1attila1]

Is it possible later inline assembly ?

[edubart]

Nelua has no plans to support inline assembly officially, but it supports inlining C code, and C compilers like GCC/Clang have inline assembly extension. What means is that you can inline assembly via C code, example:

-- Returns processor time stamp counter (x86_64 only)
local function rdtsc(): int64 <inline>
  local lo: cuint <noinit>, hi: cuint <noinit>
  ## if ccinfo.is_gcc and ccinfo.is_x86_64 then
    ## cemit[[__asm__ __volatile__ ("rdtsc" : "=a" (lo), "=d" (hi));]]
  ## else
    ## static_error 'C compiler or architecture not unsupported'
  ## end
  return ((@int64)(hi) << 32) | lo
end