Hacker News Reader

Hacker News

Comment by IshKebab | Hacker News Reader

Parent Full thread

IshKebab

1. This is much easier to embed in Rust projects than Lua.

2. Doesn't make the mistake of 1-based indexing.

3. Generally much more modern and nicer language than Lua.

The reasons I've found not to use it:

1. Very slow - even slower than Python! Of course often this won't matter but it would be nice if it was fast.

2. No support for type annotations.

I've used it before for a config file, and it worked well there. I think if I wanted anything much more complex though I would just embed V8. Then you get a language that everyone already knows and very good type annotations.

I don't think "ecosystem" really matters much for embeddable languages like this. You app is the ecosystem.

View on HN

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

> 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)

"suffer" 1-indexing vs no LSP, no books, no test-of-time, no ecosystem, no type annotations, slower.

I don't mean to be overly harsh, but this is just not a valid/serious answer. The other reasons are fine. This is pure bike-shedding.

It's absolutely a valid and serious answer? You asked for reasons, omitting two options, and they gave you a list of points for and against not including those two options. That's a good response, you don't need to agree with it, but I don't see how you can call it not serious?

The answer as a whole is serious, I said as much, read again. A singled out this one point, because it is not. It is akin to any other knee-jerk dismissive attitude to anything different. Casting away a far more proven language, used for over a decade in thousands of serious, commercial projects with wide editor (and LSP) support etc over indexing conventions, is not serious.

Lua is my first 1-indexed language, i have yet to have a single bug over this. It's a irrational fear.

> A singled out this one point, because it is not.

It absolutely is. I gave you concrete reasons. (Edit: actually in a sibling comment)

> i have yet to have a single bug over this.

I never said anything about bugs.

Nitpick: you haven’t found any bugs. That doesn’t mean they don’t exist.

Yes. So there may be a price to pay, one day.

But a vague, unsubstantiated feeling that one day, you might introduce a one-off indexing bug should not justify discarding Lua, and all its substantial benefits over project.

Arguing the pro's of Rust data-structure interop in case of a Rust project - that makes sense. This, this is basically nonsense.

> But a vague, unsubstantiated feeling that one day, you might introduce a one-off indexing bug should not justify discarding Lua, and all its substantial benefits over project.

Nobody said anything like that. There's no vague feeling of indexing bugs; there's a concrete degradation of code quality.

And yes it's only one factor, not a deal-breaker. Nobody here said it was.

An interesting thing about bikesheds is that sometimes they become bikefortresses: if 99% of the world (including the surrounding userbase, in the case of Rust) expects 0-based indexing, then the choice of something that uses 1-based indexing is harder to justify.

This doesn't make one better than the other, but precedent/familiarity does matter and represents a valid decision weight.

Sure it is a valid weight. But the weight is a millionth of the weight of the cons that come with using a new unused language for embedding.

I don't particularly disagree. Although it's worth noting that people don't typically pick embedded languages because they're familiar with the embedded language per se, but instead because they (1) are easy to integrate, and (2) resemble the syntax/semantics of the embedding language. Rhai appears to satisfy both, so I can understand why someone would pick it.

(I don't have a dog in this fight; I'm not a user of either Lua or Rhai.)

Not in this case.

No one can convince me thst 0-based indexing is worth more than widespread editor syntax -highlighting support, working LSPs, lots of blog posts, books and more vs a new niche language whose marquee feature seems to be it is easier to embed in rust.

Again, I don't want to put down the authors, making languages and tooling is fun and awesome, but I wouldn't pretend this is a rstional replacement for Lua.

I never said 0-based indexing was sufficient to choose it over Lua on its own. Just that it is an advantage over Lua, which it is.

Also I don't think Lua's LSP/type annotations are anything to boast about. They exist, but they aren't good. If you care about that there are way better choices - Typescript, or maybe Dart (not sure how embeddable that is though).

> Doesn't make the mistake of 1-based indexing.

A lot of people would call this a feature, not a mistake. 0-based indexing came from programming languages typically calculating addresses in the memory layout of an array. Whereas in mathematics (the background of the Lua inventor) sequence positions typically start at 1. Also, humans generally start counting from 1. This is intuitive in languages like SQL which also use 1-based indexing.

It could be argued that 0-based indexing was the mistake since it actually conflates two concepts, the memory layout in the machine, and the actual sequence you want to index.

I agree that it's wrong to label Lua's choice a mistake—when it was created in 1993 there wasn't as overwhelming a consensus in favor of zero-based indexing as there is now. But now the consensus is there, so whether it's a mistake or not it's not worth fighting against. Programmers today learn zero-based indexing and trying to get someone who's used to that to adapt to one-based indexing is not trivial.

Those people are wrong. Maths is wrong too but it doesn't matter so much for maths because you can hand wave syntax to do whatever you want. Guess what style of indexing formal mathematical proof systems use...

Fundamentally either work, but 1-based indexing is a mistake mainly because it leads to much less elegant code.

A simple example is accessing rows in a flattened matrix (or 2D array).

With 0-based intervals and right-open intervals it is

  array[stride*y .. stride*y + width]

With 1-based it is

  array[stride*(y-1)+1 .. stride*(y-1)+1+width]

Ouch. Code dealing with intervals is simpler with 0-based indexing & right-open intervals 99.9% of the time.

Take a look at the example code here:

https://www.lua.org/pil/11.2.html

What index does the flattened `mt` start at?

I think you're still conflating two different concepts, but this is mostly natural at this point since I assume you program in languages that use 0-based indexing. 1-based indexing focuses on the conceptual sequence rather than the underlying implementation details. Even your matrix flattening example is conflating concepts, although that's "normal" at this point. 0-based indexing certainly lends itself nicely to interval arithmetic, I agree.

> What index does the flattened `mt` start at?

I'm not sure if I missed a point you were getting at with this? Lua array table indexes start at 1.

My first boss who started in the late 60's said 1 based indexing exists because the early programmers with mathematics training thought ordinary people are too stupid to get zero based indexing.

Yeah I think that's the only plausible reason. Quite patronising but I think it probably came from an honest "make programming more accessible to non-programmers" place. They just forgot that the rest of programming exists...

You see that in books and papers and tutorials a lot. They'll explain some basic concepts nicely and then realise that they can't really explain ELI5 calculus and skip straight into Laplace transforms.

I once read a highly technical manual for a SystemVerilog simulator that began by explaining what double-clicking was. No joke. That's basically 1-based indexing.

> I'm not sure if I missed a point you were getting at with this? Lua array table indexes start at 1.

The code example is

    mt = {}          -- create the matrix
    for i=1,N do
      for j=1,M do
        mt[i*M + j] = 0
      end
    end

What index do I use to access the first element in mt? It isn't 1!

If this was written using 0-based indices then the answer would be zero.

>It could be argued that 0-based indexing was the mistake since it actually conflates two concepts, the memory layout in the machine, and the actual sequence you want to index.

This could be argued to be a feature. That it isn't conflating the concepts but communicating both.

Have you read EWD 831? https://www.cs.utexas.edu/~EWD/ewd08xx/EWD831.PDF

> 2. Doesn't make the mistake of 1-based indexing.

Why is this a mistake? I've used 0-based languages primarily, but ergonomically, 1-based languages like Awk and Smalltalk are fine too, making some code slightly harder to write and other code slightly easier. Overall, I've found it to be a wash. If anything, in a pointer-less language, pedagogically, 1-based is more intuitive for novices.

P.S. Classic VB and VBA had an odd feature where one could choose the base for themselves, using the Option Base feature.

It's interesting that merely asking someone to explain their justifications for something, without even outright criticizing it or Rust itself, is enough to net downvotes in Rust threads.

Reply on news.ycombinator.com