terra

Many of us would love a TypeScript analogy for Lua. There have been some attempts: Luau (5.2k, last week, https://luau.org/, https://github.com/edubart/nelua-lang) Nelua (2.3k, 8 months ago, https://nelua.io/, https://github.com/luau-lang/luau) Terra (2.9k, 3 days ago, https://terralang.org/, https://github.com/terralang/terra) Teal (2.7k, 2 days ago, https://teal-language.org/, https://github.com/teal-language/tl) The Luau author is always on the official Lua mailing list, and it has twice as many stars, so it seems likely to win the long term popularity contest.

Please note: The entire "windows" portion of that article has largely been resolved at this point, because I fixed it myself. Some of the more egregious documentation problems have been fixed, but others remain unresolved. Unfortunately, we have since discovered even more insane behavior: https://github.com/terralang/terra/issues/460

Also runs in GPU via CUDA. That's it's well known claim to fame. Appears to be going 1.0[1]! [1] https://github.com/terralang/terra/commit/1ea278278c104580a0...

Another commenter already mentioned Gambit Scheme. That provides for inline C and therefore very easy interop with external libraries. It still has a runtime and GC though - those might pose a problem depending on your platform and task. Ferret (https://github.com/nakkaya/ferret) and Carp (https://github.com/carp-lang/Carp) are both Lisp-like low level languages. Both seem to be fairly experimental in nature though. > anything but C Taking you literally, Rust and D can both compile for bare metal. D in particular has a "Better C" subset. (https://dlang.org/spec/betterc.html) In the same vein, Terra is a C like language (manual memory management) that you metaprogram with Lua. (https://github.com/terralang/terra) Taking you very literally, Forth is also an option.

It's been pretty dead for a while (https://github.com/zdevito/terra/graphs/contributors). These are all deep and well investigated criticisms that seem out of place when levied against a language abandoned by it's original author and apparently maintained by a single person, with a website that doesn't even have functioning HTTPS. I'm not sure what the author was expecting.

To maximize reach, have you explored what would take for a first-class Redis wasm [1] implementation, maybe pairing it with Terra [2] for Lua scripting. [1] http://webassembly.github.io/spec/core/exec/index.html [2] https://github.com/zdevito/terra

For something similar, take a look at Terra [1], the "low-level counterpart to Lua". It's based on Lua, but has "low-level" functions that are JIT-compiled to machine code using LLVM. It supports calling Lua macros from low-level functions, or you can use Lua code to write complex high-level frameworks (e.g. Go-like object system [2], Java-like object system [3]). It's still in development, so there are parts of the system that don't work very well (e.g. global variables in compiled executables cannot be statically initialized), but it's a very interesting project. [1] http://terralang.org/ [2] https://github.com/zdevito/terra/blob/master/tests/lib/golik... [3] https://github.com/zdevito/terra/blob/master/tests/lib/javal...

Have you heard of Terra[1]? I think it was pretty much designed for what you're saying. :-) The cool thing is that the project looks really active too.[2] [1] - http://terralang.org [2] - https://github.com/zdevito/terra/commits/master

One of our design goals was to make sure terra could execute independently of Lua. So everything that you describe is possible. For instance our simple hello world program (https://github.com/zdevito/terra/blob/master/tests/hello.t) compiles a standalone executable with the "terralib.saveobj" function. You can also write out object (.o) files that are ABI compatible with C. For instance, gemm.t (https://github.com/zdevito/terra/blob/master/tests/gemm.t) our matrix-matrix multiply autotuner writes out a .o file my_dgemm.o which we then call from a test harness in a separate C program (https://github.com/zdevito/terra/blob/master/tests/reference...). Once you have the .o files, you can use Lua to call the system linker to generate a dynamic library.

Yes! One of the benefits of making sure that Terra code can execute independly of Lua is that you can use multi-threading libraries pretty much out-of-the box. For instance, we have an example that launches some threads using pthreads (https://github.com/zdevito/terra/blob/master/tests/pthreads....). There are still some limitations. You'd still have to manage thread synchronization manually, and I think LuaJIT only allows one thread of Lua execution to run at a time, so if your threads call back into Lua they may serialize on that bottleneck.

Author here. You're right that we designed Terra primarily to be an enviornment for generate low-level code. In particular, we want to be able to easily design and prototype DSLs and auto-tuners for high-performance programming applications. We explain this use-case in more detail in our upcoming PLDI paper (http://terralang.org/pldi071-devito.pdf). Since we are primarily using it for dynamic code generation, I haven't done much benchmarking against LuaJIT directly. Instead, we have compared it C by implementing a few of the language benchmarks (nbody and fannkuchredux, performance is normally within 5% of C), and comparing it against ATLAS, which implements BLAS routines by autotuning x86 assembly. In the case of ATLAS, we're 20% slower, but we are comparing auto-tuned Terra and auto-tuned x86 assembly. Small note, the BF description on