Hacker News Reader

Comment by Andoryuuta | Hacker News Reader

Is there something in specific that makes this easier to use in Rust projects compared to the Lua wrappers/bindings like mlua[0]? Or is it just an overall ergonomics thing?

Genuine question, as I don't have any prior experience embedding any scripting language into a Rust project.

[0]: https://github.com/mlua-rs/mlua

View on HN

> By default mlua uses pkg-config tool to find lua includes and libraries for the chosen Lua version. In most cases it works as desired, although sometimes could be more preferable to use a custom lua library.

The fact that Rhai builds with just 'cargo build' shouldn't be underestimated - a Rust project with all pure-Rust dependencies is much easier to maintain / support / distribute across a wide variety of hosts!

This is just behind a feature flag like:

    $ cargo add mlua --features lua54,vendored

Then mlua will statically build with the Lua sources it bundles itself and no need to link the system Lua or do anything other than "cargo build" like normal.

Still not as easy as pure Rust, e.g. for cross-compiling. It's similar to how pure Go projects are much easier to cross-compile than ones using cgo.

`cargo cross` exists, which can help but it's really a kludge.

This is a cargo deficiency then.

Zig has no problem using Lua (via the Ziglua wrapper) and cross-compilation is a single command away.

Rather than developing and increasingly insular (navel-gazing?) ecosystem, it might be better to work on the root problem.

Zig is first and foremost a C compiler with cross-compilation being first class citizen so you can't really compare the two.

> Rather than developing and increasingly insular (navel-gazing?) ecosystem, it might be better to work on the root problem.

Every language has its own development budget and must focus on what makes more sense. Zig has great cross-compiling story and C is first class, Rust has a stable language, a compiler that doesn't crash and emits readable error messages, one has to set its priorities.

The good thing with zig is that you can use the zig compiler within Rust project to cross-compile C code (cargo-zigbuild IIRC) so you can have a cake and eat it too.

This is a very uninformed take. It's not a Cargo or Go problem, it's a C problem. It only works well with Zig because Zig goes to insane lengths to hide the problem.

In fact it's so much of a C problem that lots of people even cross-compile their pure C code with Zig, because Zig handles all of the C mess!

You can educate yourself here: https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...

That is a very condescending tone.

Perhaps instead the more constructive path would have been to try and defend why one (cargo, rust) cannot do what another (zig) can.

So far, all I can infer is an acceptance of how compiling C code is hard and rather messy. I am no more uninformed on this than this literally being a daily fact of my paid life, but do go on, tell me how I've missed the point.

The condescending tone started with you calling projects "deficient" for not handling problems well they don't want to handle. Yes, a C compiler is good at C things. It's not "deficient" if that C compiler sucks at integrating BASIC code.

Yes, it is designed for Rust, so the actual interop with Rust is very good. You can pass Rust types in and out with very little work, and they are represented in Rhai in a logical way.

Even something like a `Vec<u64>` is likely to be a right pain with Lua.

My frame: I would say that embedding in rust is hard, unless you are already thinking in rust. Mostly ownership things, which I see distinct from safety.

If you are thinking in rust already, why would you go to an FFI c solution?

(Source: have been prototyping DSLs in rust with most of my life force for about a year)

Reply on news.ycombinator.com