Comment by eggy | Hacker News Reader

Comment by eggy | Hacker News Reader

Parent Full thread

I had submitted this to HN because I was trying to evaluate using Terra instead of Zig [1] as my C replacement language. I had already become familiar with a particular dual-language environment called Extempore, [2] for livecoding that has a scheme language, and a c-like, s-expression-based language called xtlang that is compiled. You can mix the two in the same programming session, and it really works for me. And then I came upon Pallene.

I like the idea of having a scripting language like Lua, but the clarity of a typed, compiled, non-GC language instead of C or the templates of C++. Terra ticks those boxes. The mix of Lua and Terra seems to be very flexible too from my early explorations. Is Pallene within an order of magnitude of the speed of Terra given no special tricks are needed to pull off a task. Are there any "bad" things Terra does that Pallene keeps within the better side of Lua. I guess I am asking if Pallene is a better fit for a dual-language system based on Lua than Terra other than maximum numerical computing performance. Thanks!

  [1] ziglang.org
  [2] https://extemporelang.github.io/

I talk a bit about this in a sibling comment. Maybe that helps answer your question?

Pallene uses garbage collection, and shares the Lua garbage collector. The idea is to make as easy as possible to call Pallene from Lua and Lua from Pallene. Meanwhile, Terra only uses Lua at compilation time for metaprogramming and template building. At runtime, if you want to call Lua from Terra (or vice versa) you need to use the C API, just like you would do with C.

I wouldn't really try to compare the performance of Pallene with Terra. They are two very different languages, doing different things.

I would just note, for anyone else coming on this, that in Terra you can also call back into Lua. From an implementation perspective, sure it goes through the C API, but as far as users are concerned, it looks pretty much like a normal function call (except as of the 2016 release you have to cast the Lua function to a specific type, but I don't think this is a terribly big deal).

The bigger issue is that as soon as you call from Terra back to Lua you've made a circular dependency, and so you can't then dump an object file and have it be entirely free of the Lua VM. This for me happens to be one of the big selling points of Terra, because I know that I can write as much code as I want and (usually) can still come out with clean object files to link into any old project on the other side.

I definitely get the appeal of a system which is intended to integrate with the same VM. If it weren't for some of the constraints of my current project, I'd definitely be thinking about it, so I'm glad that people are putting effort into exploring both approaches.

Thank you for explaining it more to me.

If I were just interested in numeric computing (arrays as well), I am assuming without benchmarking Terra and Pallene that Terra would win by an order of magnitude, no? Thanks again!

If you were writing naive code, it probably wouldn't be that much. Maybe a 2to 3 times difference. But the thing with Terra is that you can be even faster than naively-written C if you know what you are doing.

I am trying to explore Terra more for this reason, but Pallene has piqued my interest. My guess from the responses and what the authors of Pallene have stated is that Terra is probably better to stick with for numerical work.

Reply on news.ycombinator.com