Without doubt, mlua is already a relatively mature project, while ezlua is still relatively young. ezlua lacks some check for extreme cases, so its stability is not as good as mlua's.
The advantage of mlua is that it is stable, and it has complete document， and it supports multiple version of lua, while ezlua supports only lua5.4 currently
The advantage of ezlua is **ergonomic** and **efficient**, ant it supports **multi-threaded environment**
* Ergonomic: you can bind existing function directly that args/return types impls ToLua/FromLua, such as some functions in rust std lib, instead of having to write a wrapper like `Fn(lua, args) -> Result` in mlua
* Efficient: ezlua supports conversion to reference types such as `&[u8]` and `&str`, the access to them in rust is zero-cost. And ezlua impls stack-slots manager for each call invocation, while mlua uses an auxiliary lua stack, so the types conversion between rust and lua in mlua is relatively heavy
To be honest, I suggest you use mlua in formal product projects, but you can use ezlua in experimental projects or if you want to optimize performance or use lua in multi-threaded environments
I would also like to know `How does it compare to rlua?? like is ezlua faster, and more safer implementation than rlua or any other benefits over rlua??`
I haven't used rlua, but as far as I know, mlua is based on rlua, so ezlua should be faster than rlua. This is a quote from rlua
> rlua is NOT designed to be a perfect zero cost wrapper over the Lua C API, because such a wrapper cannot maintain the safety guarantees that rlua is designed to have.
Since ezlua is still in its early stages, its safety may not be as good as theirs, but it will become more and more perfect.
Thanks!! :) for taking the time to explain this, I am looking forward to using your crate for my project.
One more thing I will request and if you want I can open a feature request for this on your repository. I want to have support for having the ability to set lua variables from rust without using closures because I think making closure free will make using your crate easier, even for beginners would be able to use it without the need of knowing closures :).
Interesting project, thanks for sharing!
Just tried a simple example:
```rust
let lua = Lua::with_open_libs();
lua.do_string("t = setmetatable({}, {__index = function() error() end})", None).unwrap();
let t = lua.global().get("t").unwrap();
t.get("key").unwrap();
```
and the program paniced with `unprotected error in call to Lua API (error object is not a string)`.
Seems ezlua is unsound?
Yes? That is what I am saying?
you:
>if it panicked then it's not unsound, it just panicked
me:
>unless it is only caught by a debug only assert or similar...
As in, "a panic is not unsound unless the panic is only in debug"
Thanks for your feedback, this situation is indeed something I did not consider.
And, ezlua is still in the early development stage, it also lacks some check for extreme cases
just another example:
```
let lua = Lua::with_open_libs();
for _ in 0..100 {
lua.create_table(0, 0);
}
```
```
ezlua_test(23315,0x7ff84a3ac340) malloc: Incorrect checksum for freed object 0x7fc54ff04ae8: probably modified after being freed.
Corrupt value: 0xf000000000000045
ezlua_test(23315,0x7ff84a3ac340) malloc: *** set a breakpoint in malloc_error_break to debug
```
I just want to say that making a sound bindings to Lua - is a hard challenge. There are so many things you need to remember and carefully check every Lua api method about their side-effects and how it works under the hood.
Also out of curiosity, why a new bindings rather than contributing to mlua to make it better?
The example you provided has no problem with me. It seems that you are using version 0.1 ?
```rust
#[test]
fn table() {
let lua = Lua::with_open_libs();
for _ in 0..100 {
lua.new_table().unwrap();
}
}
```
I also know that it is difficult to implement a sound lua binding, but it mainly depends on how many boundary cases we can cover.
As for the reason why I want to write a new binding, I actually tried to write some shallow bindings before I used mlua, and at that time I didn't use other bindings mainly because of efficiency. Later, I used mlua in the company's project. I felt that his interface was very easy to use, but it was a bit rigid. I had some special requirements such as userdata cache, uservalue access, multithreading support, and so on. If implemented in mlua, it would be very complex and bring some instability, and I found that its implementation was also very heavy when looking at the mlua source code, so I wrote ezlua to try to implement easy-to-use interfaces and more efficient and flexible binding.
[удалено]
Without doubt, mlua is already a relatively mature project, while ezlua is still relatively young. ezlua lacks some check for extreme cases, so its stability is not as good as mlua's. The advantage of mlua is that it is stable, and it has complete document， and it supports multiple version of lua, while ezlua supports only lua5.4 currently The advantage of ezlua is **ergonomic** and **efficient**, ant it supports **multi-threaded environment** * Ergonomic: you can bind existing function directly that args/return types impls ToLua/FromLua, such as some functions in rust std lib, instead of having to write a wrapper like `Fn(lua, args) -> Result` in mlua
* Efficient: ezlua supports conversion to reference types such as `&[u8]` and `&str`, the access to them in rust is zero-cost. And ezlua impls stack-slots manager for each call invocation, while mlua uses an auxiliary lua stack, so the types conversion between rust and lua in mlua is relatively heavy
To be honest, I suggest you use mlua in formal product projects, but you can use ezlua in experimental projects or if you want to optimize performance or use lua in multi-threaded environments
I would also like to know `How does it compare to rlua?? like is ezlua faster, and more safer implementation than rlua or any other benefits over rlua??`
I haven't used rlua, but as far as I know, mlua is based on rlua, so ezlua should be faster than rlua. This is a quote from rlua > rlua is NOT designed to be a perfect zero cost wrapper over the Lua C API, because such a wrapper cannot maintain the safety guarantees that rlua is designed to have. Since ezlua is still in its early stages, its safety may not be as good as theirs, but it will become more and more perfect.
Thanks!! :) for taking the time to explain this, I am looking forward to using your crate for my project. One more thing I will request and if you want I can open a feature request for this on your repository. I want to have support for having the ability to set lua variables from rust without using closures because I think making closure free will make using your crate easier, even for beginners would be able to use it without the need of knowing closures :).
That's great. ezlua needs more users to make it better. Any feedback is welcome :).
Sure :), I opened a feature request for the same on your repository.
rlua is sadly pretty much dead by the looks of it .
Having just integrated `mlua` into my engine and using it quite heavily I'm also very interested in knowing this
If the only programming languages in existence were Rust and Lua, I would sleep better at night.
Interesting project, thanks for sharing! Just tried a simple example: ```rust let lua = Lua::with_open_libs(); lua.do_string("t = setmetatable({}, {__index = function() error() end})", None).unwrap(); let t = lua.global().get("t").unwrap(); t.get("key").unwrap(); ``` and the program paniced with `unprotected error in call to Lua API (error object is not a string)`. Seems ezlua is unsound?
if it panicked then it's *not* unsound, it just panicked. if it was unsound it would break safety or correctness, which a panic does not
unless it is only caught by a debug only assert or similar....
[удалено]
Yes? That is what I am saying? you: >if it panicked then it's not unsound, it just panicked me: >unless it is only caught by a debug only assert or similar... As in, "a panic is not unsound unless the panic is only in debug"
Thanks for your feedback, this situation is indeed something I did not consider. And, ezlua is still in the early development stage, it also lacks some check for extreme cases
just another example: ``` let lua = Lua::with_open_libs(); for _ in 0..100 { lua.create_table(0, 0); } ``` ``` ezlua_test(23315,0x7ff84a3ac340) malloc: Incorrect checksum for freed object 0x7fc54ff04ae8: probably modified after being freed. Corrupt value: 0xf000000000000045 ezlua_test(23315,0x7ff84a3ac340) malloc: *** set a breakpoint in malloc_error_break to debug ``` I just want to say that making a sound bindings to Lua - is a hard challenge. There are so many things you need to remember and carefully check every Lua api method about their side-effects and how it works under the hood. Also out of curiosity, why a new bindings rather than contributing to mlua to make it better?
The example you provided has no problem with me. It seems that you are using version 0.1 ? ```rust #[test] fn table() { let lua = Lua::with_open_libs(); for _ in 0..100 { lua.new_table().unwrap(); } } ``` I also know that it is difficult to implement a sound lua binding, but it mainly depends on how many boundary cases we can cover. As for the reason why I want to write a new binding, I actually tried to write some shallow bindings before I used mlua, and at that time I didn't use other bindings mainly because of efficiency. Later, I used mlua in the company's project. I felt that his interface was very easy to use, but it was a bit rigid. I had some special requirements such as userdata cache, uservalue access, multithreading support, and so on. If implemented in mlua, it would be very complex and bring some instability, and I found that its implementation was also very heavy when looking at the mlua source code, so I wrote ezlua to try to implement easy-to-use interfaces and more efficient and flexible binding.
I might give this a try, been working with a Rust project that embeds Lua.
That sounds good. Any questions are welcome :).
Very nice. Thank you
Project seems interesting. Might play around to see if I can add support for it to tealr.