Alternatively, while it would be nice to have a Lua engine entirely in Rust, Rust goes to great lengths to make calling into C have no runtime cost, so you generally just see people writing Rust wrappers over the C API, which tend to impose varying degrees of additional safety on top (Lua internally does a ton of setjmp/longjmp, among other things, so it's not easy). A good example of "wrap and add safety" is Chucklefish's wrapper, being used for their game Witchbrook: https://github.com/kyren/rlua
I'm a Helm maintainer so I'm familiar with the history of how this came to be.
As Helm so far could operate with a simple template language , and now suddenly jumps to a Turing-complete configuration language - this seems quite large step... What is the justification?
Lua provides the ability to have the language embedded easily (it was designed for that) for use in cross platform situations (Windows included).
Does that help?
> We also wanted clean and idiomatic Go APIs
If you want to use this as a scripting/plugin language for Go programs (say, for those distributed computing programs you mentioned), it's pretty defensible to make it integrate with Go better by... building it in Go.
Probably because they wanted to use it from Go?
That's quick and dirty. Dirty, because the way Go's GC is optimized is likely to be very unsuitable for Lua.
I can imagine how exposing a Rust API to a non-Rust program could be as problematic as a C++ API: your common denominator is a C API, which adds cumbersomeness and removes (some of) the safety.
If you already have projects in go then a rust project will not be of any use, and vice versa...
Then don't.
If you are going to say GC, it all comes down to how one designs the respective data structures.
Having done some compiler related work back when we had Caml Light, OCaml was still called Objective Caml and Mirada was being turned into Haskell, I don't see what I would gain from having to deal with the borrow checker.
It's the ADTs that are killer compared to Go.
If we're veering off into hypotheticals that don't have anything to do with the question at hand, I personally write compilers and interpreters in Rust rarher than another ML because my use cases tend to be worst case latency sensitive enough that a GC is a non starter.
I think go and rust serve two somewhat different use cases- go being for distributed computing in a nutshell, and rust for fast running programs. And I think Rust would have been a better choice
Edit: looks like everybody and their dog has a Lua engine now- maybe I'll create one in rust